[jboss-dev] Classloader changes from AS 4.2.2 to AS 4.2.3 affecting launch of Tool built Seam apps

[Max Rydahl Andersen]

Jaikiran, Thanks for you analysis - your explanation correlate with my 
suspicion; exploded vs archived deploy is different and exploded results 
in virtual duplication of .jar's even though there only is one!

This also explains other issue we had with Seam 2.1.x that also changed 
their logic in scanning and now sees duplication of jars even though 
there are none and afaics we can't even in Seam or any other framework
filter the url's in the classloader since they are unique even though 
they originate from the same place.
>
> 1) Should (EJB) *deployments* be listed in the MANIFEST.MF files of 
> other deployments. In this example the jboss-seam.jar which is a EJB 
> deployment (marked as a "module" in application.xml) is listed in 
> MANIFEST.MF of an xxx-ejb.jar deployment.
We list these in manifest.mf since that is the only way Eclipse can know 
what is on the classpath; application.xml afaik does not attribute to 
the classpath - at least I never seen an IDE does that (they might be 
wrong ;)
In any case, listing it in manifest.mf and in application.xml should not 
hurt anything since they should just resolve to the *same* jar.

> 2) Is the duplicate temp files for the same jar file (jboss-seam.jar) 
> intentional? It's created once during the MANIFEST.MF parsing of 
> xxx-ejb.jar deployment and once during deploying jboss-seam.jar 
> deployment (which is listed as a module in application.xml).
This is *the* bug I believe ? This will keep causing problems...

Any suggestion for a workaround that still allow me to use *standard* 
manifest.mf classpath entries ?

> --------------------
> Archived deployment :
> --------------------
> When the application is deployed as an archive, the deployment 
> framework creates a exploded temp of the EAR in the tmp folder. It 
> however does *not* create temps for the sub-deployments or the 
> libraries within the ear. So there is only one jboss-seam.jar in 
> tmp/sometmpName.ear-contents. Because of this the logic explained 
> above, registers the SeamPhaseListener only once and hence no issues.
Why the difference in behavior ? Legacy ? Intentional ?
>> Why does it matter which letters we use in the deployment, i.e. 
>> fseam.ear behaves different that seam.ear ? 
> Though the JIRA mentions this, i don't see a reason why the name 
> should matter. I did not see any other explanation in the JIRA as to 
> how this fixed the issue.  Is there some app which shows this behaviour?
The problem is that it only shows up sometimes - I have seen it several 
times with capital letters (another bug) and even went so far to add a 
warning in the ui that using capital letters as the first character were 
not recommended.
I'll try and see if I can find a way to reproduce the situation with 
different letters.

/max