"alesj" wrote : "scott.stark(a)jboss.org" wrote : Sounds fine.
| |
| I proposed different 'strategy'.
| I don't like the idea of equal MC modules being at different source levels.
| So I would keep the current osgi-int and add a new 'varia' module, where I would keep all external APIs:
|
Not varia. Varia is a bad idea in JBossAS and a bad idea here.
Call it jboss-osgi-services (or if it really is external why do we need a project anyway,
can't this just be integrated as a jar?)
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4041847#4041847
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4041847
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?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4041802#4041802
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4041802