[alesj]

"alesj" wrote:

What do you have in your .sar? MBeans?

No, just web archive (incorporating WebService endpoints our deployers operate with)

Try with renaming first,
and/or do some investigation around jboss-classloading.xml,
on how you can declare dependency on module / jar:
- https://jira.jboss.org/jira/browse/JBCL-10

[ropalka]

After short investigation deployers (not deployment) is my real problem.
I noticed that .sar archives are deployed first (thus deployers operate on them first too). Deployers are executed first and then archives are scheduled for deployment.

My problem is that the .sar archive can incorporate nested EJB or Web deployments representing Web Service deployments. Thus our deployers operate on these nested archives present in .sar archives.

Our real problem is that our WebServices deployer depends on JBossWebMetaData ctx classloader which is null in time frame of executing the deployers chain for all .sar archives being processed by deployers.

[ropalka]

"alesj" wrote:

http://java.dzone.com/articles/a-look-inside-jboss-microconta

I'm reading it now ;)

[alesj]

"alesj" wrote:

http://java.dzone.com/articles/a-look-inside-jboss-microconta

I'm reading it now ;)

I doubt it will help with the problem above, but it cannot hurt. :-)

Perhaps you can use DeploymentUnit::getResourceClassLoader while the _real_ ClassLoader is not yet resolved?
But make sure this usage is legit, not actually a hack while doing deployers in a wrong way. ;-)

[adrian.brock]

I'm going to reset this conversation in the next post,
but first let me try to summarise the description of this problem
from this long thread and explain what I think is really happening
(and tell you how you would do exactly what you are asking for
although it is the wrong way to do it).

So you can tell me where I have misunderstood .... :-)

You have a sar that contains a war, e.g. like the web-console

[ejort@warjort management]$ ls -l console-mgr.sar/
total 1560
-rw-rw-r-- 1 ejort ejort 142692 Nov 3 20:59 console-mgr-classes.jar
-rw-rw-r-- 1 ejort ejort 307601 Nov 3 20:59 jcommon.jar
-rw-rw-r-- 1 ejort ejort 1098048 Nov 3 20:59 jfreechart.jar
drwxrwxr-x 2 ejort ejort 4096 Nov 3 20:59 META-INF
drwxrwxr-x 7 ejort ejort 4096 Nov 3 21:00 web-console.war

This **naively** means that the webapp in web-console.war needs to be
"deployed" after jbossweb.sar
But if you look at the logging you'll find this isn't what happens in the deployer layer.

This actually hasn't changed in this basic characteristic between jboss4 and jboss5
Since management/console-mgr.sar (the top level deployment name) is before
jbossweb.sar it will go through the deployers first (including all its subdeployments).

ASIDE: What has changed in JBoss5 is that the deployers are now done in stages
so you can be sure the classloader for jbossweb.sar is available in the REAL
stage for all other deployments in deploy.
This makes NoClassDefFoundErrors due to deployment ordering less likely in JBoss5
even when you don't use the new classloading dependencies.

So why isn't this an issue? The answer is that the deployers don't create
the webapp. What they do create is metadata on how to construct the
webapp and what its dependencies are.
i.e. the REAL webapp deployer creates some MBean metadata
that says it depends on the main jboss.web service (Tomcat)

This dependency makes sure that even though the metadata for web-console.war
was created first, the webapp is not constructed until after the webserver is running.

Now what I think is really happening for you and why I think you're seeing a problem
is that you have one of two problems:

1) The webapp (metadata) you are creating is missing a dependency
so the services are being constructed in the wrong order.

2) You are trying to create or access the service in the deployer processing which
you should not be doing.

Finally (and this is not recommended although Ales hinted at in a kind of hacky way)
you can actually make a (sub-)deployment depend on a service.
i.e. deployments can have dependencies even at the deployer stage
The reason this exists is to do classloading dependencies since the later
REAL deployers need to examine classes to create metadata and also
need to redeploy applications (reexamine classes) when dependent classes change.

So if you really want to (not recommended)
make your war subdeployment run after jbossweb
The only way to do this currently is programmatically, i.e. you
do DeploymentUnit.getDependencyInfo().addIDependOn(...)
where the DependencyItem would say that this deployment cannot move
to the REAL stage until the jboss.web MBean reaches the INSTALLED stage.

NOTE: Since deployments as processed as "all or nothing" through the stages
this would actually mean your whole sar doesn't reach the REAL stage
until jboss.web is INSTALLED

[adrian.brock]

So now for the reset. Which of the following mistakes is true? :-)

1) The webapp (metadata) you are creating is missing a dependency
so the services are being constructed in the wrong order.

2) You are trying to create or access the service in the deployer processing which
you should not be doing.

[ropalka]

So now for the reset. Which of the following mistakes is true? :-)

1) The webapp (metadata) you are creating is missing a dependency
so the services are being constructed in the wrong order.

2) You are trying to create or access the service in the deployer processing which
you should not be doing.

Welcome to the conversation Adrian ;)
The 2) is my problem.

[ropalka]

I introduced little classloader hack few minutes ago in our deployers layer.
However I'd like to do it properly. I'm working on our WS deployers at the moment trying to do better and proper integration with the JBossAS 5 deployers processing.
The problem of our deployers is it don't deal only with deployers metadata but also with services metadata that are e.g. configured when web app is deployed.
Thus I need to identify what we can do in the deployers chain, and what we will need to move to upper processing layers.

[ropalka]

The problem of our deployers is it don't deal only with deployers metadata but also with services metadata that are e.g. configured when web app is deployed.

To clarify my problem here's one example. We have two deployers registered for POJO webservices deployments which order in deployers chain is important:

WebServicesDeployerPreJSE < WarDeployer
WarDeployer < WebServicesDeployerPostJSE

The problem is when we have .sar deployment incorporating nested war deployment (web service POJO), the WebServicesDeployerPostJSE is called before the nested war is really deployed to the real. Thus we're getting null for JBossWebMetaData ctx loader which isn't true in case we're deploying such .sar archive using hot deploy feature (JBossAS is already running). The problem is on JBossAS bootstrap when we have such .sar archive in the deploy directory.

[adrian.brock]

Thus we're getting null for JBossWebMetaData ctx loader which isn't true in case we're deploying such .sar archive using hot deploy feature (JBossAS is already running). The problem is on JBossAS bootstrap when we have such .sar archive in the deploy directory.

I don't see a ctx loader on JBossWebMetaData?
That doesn't make any sense.

But it sounds like your real problem is that you just want the classloader for the webapp?
That's obtainable just by doing DeploymentUnit.getClassLoader()

From AbstractWarDeployment::start()
which obviously doesn't get invoked until the MBean has its dependencies satisfied
(i.e. jbossweb is running)

 ClassLoader warLoader = unit.getClassLoader();
 thread.setContextClassLoader(warLoader);

<snip/>

 webApp = new WebApplication(metaData);
 webApp.setClassLoader(warLoader);

[adrian.brock]

In general all your processing in the deployers should just be based on metadata
available to deployers or configuration on the deployers.

You shouldn't be looking at any services.

e.g. suppose the war had a dependency on an ejb from some other application
then its not going to be started until that ejb exists regardless of when jbossweb.sar
gets started.

[ropalka]

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);
 }

That's obtainable just by doing DeploymentUnit.getClassLoader()

Yes, this is exactly what my current hack is doing.

[ropalka]

In general all your processing in the deployers should just be based on metadata
available to deployers or configuration on the deployers.

You shouldn't be looking at any services.

e.g. suppose the war had a dependency on an ejb from some other application
then its not going to be started until that ejb exists regardless of when jbossweb.sar
gets started.

Exactly.

[ropalka]

Cross reference JIRA issue.

[adrian.brock]

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. ;-)