"dimitris(a)jboss.org" wrote : Regarding http://jira.jboss.com/jira/browse/JBAS-3047, I did some adjustments on top of Scott's changes, that I want them to be reviewed.
| They way I understand it is:
| a) To use the jboss web loader, either it has to be configured as the default setting for tomcat, OR a <loader-repository> entry in jboss-web.xml will activate it. In this case the parent/child first classloading behaviour is controlled by loader-repository java2ParentDelegation, and the java2ClassLoadingCompliance flag is ignored, e.g:
| | <class-loading java2ClassLoadingCompliance='false'>
| | <loader-repository>dot.com:loader=unique-archive-name
| | <loader-repository-config>java2ParentDelegaton=true
| | </loader-repository-config>
| | </loader-repository>
| | </class-loading>
| b) if the web loader is used, then jboss-web.xml can override the tomcat configured default java2ClassLoadingCompliance setting, e.g:
| | <class-loading java2ClassLoadingCompliance='true'>
| Is this correct?
Yes, currently, but you should be able to use either the config you show, or something like:
| <class-loading java2ClassLoadingCompliance='true'>
to create a UCL that is not scoped. There is inconsistent handling of the UCL creation in the LoaderRepositoryFactory for this though. It defaults to a scoped ULR, and requires a ctor that does not exist in the unscoped ULR. The WebIntegrationUnitTestCase.testJava2ClassLoadingComplianceOverrideULR is failing because of this.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4041893#4041893
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4041893
"manik.surtani(a)jboss.com" wrote :
| Looking at JBCACHE-1023, and with reference to this, how would we deal with potentially injecting both a ChannelFactory as wel as a Channel?
| If the Channel is null, fall back to the ChannelFactory and use the CF to create a channel? And if the CF is null, create a new JChannel with cluster props (or default cluster props?)
+1. That's the intuitively understandable way.
anonymous wrote :
| A bit of a PITA that org.jgroups.jmx.JChannelFactoryMBean doesn't extend org.jgroups.ChannelFactory - as this would be the cleanest interface to use here.
I think the type in RuntimeConfig should be org.jgroups.ChannelFactory. I see now that AS 5 will have no problem instantiating a ChannelFactory, injecting it into a RuntimeConfig and also injecting it into an instance of org.jgroups.jmx.JChannelFactory. It can then register the org.jgroups.jmx.JChannelFactory in JMX in order to expose the management interfaces.
Key thing in the above is JMX is just a mechanism for exposing management interfaces. It doesn't and shouldn't play the service integration role it did in AS 4-style architectures. Service integration should be done by injecting pojos -- i.e. the plain org.jgroups.ChannelFactory.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4041871#4041871
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4041871