JBAS-5895; Processing too many classes

[alesj]

https://jira.jboss.org/jira/browse/JBAS-5895

This looks like a problem of EARStructure
not explicitly excluding ear's lib directory?

I cannot find library-directory element as part of EarMetaData:
- http://anonsvn.jboss.org/repos/jbossas/projects/metadata/trunk/src/main/java/org/jboss/metadata/ear/spec/EarMetaData.java
So this might be a reason why it wasn't excluded - you put the element in spec file.
But on the other hand I see this in EARStructure:

 // Add the ear lib contents to the classpath
 String libDir = appMetaData.getLibraryDirectory() == null ? "lib" : appMetaData.getLibraryDirectory();

Hence if emtpy library-directory is parsed as null,
then we would always get lib as default.

[emuckenhuber]

"alesj" wrote:

I cannot find library-directory element as part of EarMetaData:
- http://anonsvn.jboss.org/repos/jbossas/projects/metadata/trunk/src/main/java/org/jboss/metadata/ear/spec/EarMetaData.java
So this might be a reason why it wasn't excluded - you put the element in spec file.

Well it's in the Ear5xMetaData:
http://anonsvn.jboss.org/repos/jbossas/projects/metadata/trunk/src/main/java/org/jboss/metadata/ear/spec/Ear5xMetaData.java

"alesj" wrote:

Hence if emtpy library-directory is parsed as null,
then we would always get lib as default.

From what i've seen it should be parsed to an empty String. So libDir in this case would be "". If that helps you a bit :)

[alesj]

"emuckenhuber" wrote:

From what i've seen it should be parsed to an empty String. So libDir in this case would be "". If that helps you a bit :)

How does this play with ear's lib?
Afaik in this case it would pick up every jar that's in ear's root?
Which is definitely wrong. ;-)

[starksm64]

Right, I believe this is what is happening. Classes end up not being found from the lib directory because the package name is wrong, but there should not be any root content in the classpath of the ear if the lib dir is empty as opposed to null. We need to check for an empty lib and skip it.

[alesj]

OK, this is the actual cause of the problem.

In EARStructure we have by default includeEarRootInClasspath = true.
Hence the root is added to classpath.
Skipping lib in classpath doesn't help here.

It's the VFSDeploymentClassLoaderPolicyModule::visit that picks up
classes in EAR-ROOT/lib/shared.jar since root is in the classpath.
While visiting root as part of classpath it finds com.sun.ts.tests.ejb30.assembly.librarydirectory.disable.AssemblyBean as a resource: lib.shared.jar.com.sun.ts.tests.ejb30.assembly.librarydirectory.disable.AssemblyBean
But I use javassist to give me classname, hence the name is real classname, not full resource name (including prefix lib.shared.jar).
So, when it tries to load the class, it cannot find it - as it should be - since lib/shared.jar is not part of the classpath.

What should be a proper/good fix for this?

We have bunch of filters we could use.
We need to allow only visibility of plain resource files from ear's root,
e.g. some old .properties or legacy .xml,
but definitely not directories.

[alesj]

"alesj" wrote:

We have bunch of filters we could use.
We need to allow only visibility of plain resource files from ear's root,
e.g. some old .properties or legacy .xml,
but definitely not directories.

This should be applied to ear's Module somehow.

[starksm64]

"alesj" wrote:

What should be a proper/good fix for this?

We have bunch of filters we could use.
We need to allow only visibility of plain resource files from ear's root,
e.g. some old .properties or legacy .xml,
but definitely not directories.

The only reasonable filter is to exclude the "lib" child contents as that is the default ear lib directory name. If someone has a custom ear libx child, but excludes the directory via metadata, then would also have to disable the include root option as well.

[alesj]

If someone has a custom ear libx child, but excludes the directory via metadata, then would also have to disable the include root option as well.

Why?
Or why is this different from if (s)he has plain lib child?

e.g. you don't want lib to be part of classpath,
but you still want to find xyz.properties file in ear's root as part of classpath

The problem I see for me is that in the deployers that are Module aware
don't know if underlying deployment unit is top ear deployment unit,
since it's only structure deployers that understand ear (war, jar, ...),
but they don't have a clue about Module.

[alesj]

"alesj" wrote:

The problem I see for me is that in the deployers that are Module aware
don't know if underlying deployment unit is top ear deployment unit,
since it's only structure deployers that understand ear (war, jar, ...),
but they don't have a clue about Module.

What about if I add a predetermined attachment to ear's top
deployment context and then grab it out in one of the deployers
that's just in between from Module-creating-deployer and AnnotationScanningDeployer?
e.g. if the attachment is there, then it means this deployment unit
is ear top deployment unit, hence apply root Module filter
Or too much of a hack? :-)

[starksm64]

"alesj" wrote:

If someone has a custom ear libx child, but excludes the directory via metadata, then would also have to disable the include root option as well.

Why?
Or why is this different from if (s)he has plain lib child?

Because there is no basis to identify libx as a lib directory that was excluded. In the metadata you either specify the lib directory or an empty name to indicate there is no lib directory. If there is no directory name, its assumed to be "lib". There is no way to say exclude libx as a lib directory other than reverting to jboss structure metadata.

"alesj" wrote:

The problem I see for me is that in the deployers that are Module aware
don't know if underlying deployment unit is top ear deployment unit,
since it's only structure deployers that understand ear (war, jar, ...),
but they don't have a clue about Module.

What about if I add a predetermined attachment to ear's top
deployment context and then grab it out in one of the deployers
that's just in between from Module-creating-deployer and AnnotationScanningDeployer?
e.g. if the attachment is there, then it means this deployment unit
is ear top deployment unit, hence apply root Module filter
Or too much of a hack? :-)

This is too much of a hack, and what I'm saying is that if someone wants an ear to include the root, but exclude non-standard lib directory, they have to use jboss specific metadata to do so. The only child location we can exclude when an empty library-directory is specific is "lib".

[alesj]

The only child location we can exclude when an empty library-directory is specific is "lib".

Makes sense.
But, like I said, we have parts of info in different places,
empty-dir lib in EarStructure and Module filter in some real deployer.
The only thing that I can think of, that binds them, is my hack. :-)

[starksm64]

I'll have to look into why that is. I thought there was an excluded notion added to the classpath so you have have a number of roots, and exclusions to further restrict what gets added. What we need out of the structure phase are the classpath roots + inclusion/exclusion filters.

[adrian.brock]

I'm not understanding this issue.

The VFSResourceVisitor should already exclude other roots
if they are nested within another root.

See VFSResourceVisitor.accepts()

 // This is our current root
 if (file.equals(root))
 return true;

 // Some other root, it will be handled later
 for (VirtualFile other : roots)
 {
 if (file.equals(other))
 return false;
 }

[alesj]

The VFSResourceVisitor should already exclude other roots
if they are nested within another root.

It does.

It's an issue when lib is not part of classpath / roots,
e.g. explicitly excluded with library-directory application.xml element.

Then VRVisitor still visits lib directory, picking up annotated classes,
although when we declared ear's root as classpath entry,
we probably only wanted to do that to pick some .properties / .xml resources,
not excluded lib's jars.

[adrian.brock]

Ok. so the solutions seems obvious to me.
I don't see the point of trying to fix a hack with another hack.

The original problem comes about because the old UCL added the root of
the ear to the classpath. This was a mistake, and was only done for debugging
purposes, i.e. to print the ear url in the toString() of the classloader.

We still do it for backwards compatiblity purposes, but now it is causing problems
for the annotation scanning.

So why don't we just turn it off?

If somebody really wants the old behaviour they can enable it.
But since it is not portable behaviour, it would be better for them to fix the packaging
anyway.