"richard.opalka(a)jboss.com" wrote : "adrian(a)jboss.org" wrote :
| | I don't see a ctx loader on JBossWebMetaData?
| | That doesn't make any sense.
| Here's our code:
|
| | // JSE endpoints
| | else if (dep.getAttachment(JBossWebMetaData.class) != null)
| | {
| | JBossWebMetaData webMetaData =
dep.getAttachment(JBossWebMetaData.class);
| | ClassLoader classLoader = webMetaData.getContextLoader();
| | if (classLoader == null)
| | {
| | // [JBWS-2246] hack for .sar deployments incorporating web services
deployments
| | classLoader = dep.getInitialClassLoader();
| | }
| | dep.setRuntimeClassLoader(classLoader);
| | }
|
Ok I see it now (its called cxtloader :-), it is deprecated:
| /** The web context class loader, used to create the ws4ee service endpoint */
| @Deprecated
| private transient ClassLoader cxtLoader;
|
It clearly doesn't belong in the metadata description.
Given what it is being used for, it is not actually the same thing
as the (sub-)deployment classloader.
The cxtLoader is actually a wrapper for the deployment classloader
that identifies the ENC.
It doesn't get set until the start of the webapp in TomcatDeployment.
But there's an obvious workaround. Store the JBossWebMetaData in your "dep"
(whatever that is) instead of the classloader which is unknown at that point.
Then what your "dep" really creates can look it up during its start() if you
depend
upon the webapp.
This whole area needs rewriting to get rid of all these stupid hacks
and useless complexity. ;-)
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4186736#...
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...