-
1. Re: JBAS-5895; Processing too many classes
emuckenhuber Sep 11, 2008 6:01 AM (in response to alesj)"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 :) -
2. Re: JBAS-5895; Processing too many classes
alesj Sep 11, 2008 9:24 AM (in response to 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. ;-) -
3. Re: JBAS-5895; Processing too many classes
starksm64 Sep 11, 2008 12:05 PM (in response to alesj)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.
-
4. Re: JBAS-5895; Processing too many classes
alesj Sep 12, 2008 5:57 AM (in response to 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. -
5. Re: JBAS-5895; Processing too many classes
alesj Sep 12, 2008 6:19 AM (in response to 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. -
6. Re: JBAS-5895; Processing too many classes
starksm64 Sep 12, 2008 12:50 PM (in response to alesj)"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. -
7. Re: JBAS-5895; Processing too many classes
alesj Sep 12, 2008 3:03 PM (in response to alesj)"scott.stark@jboss.org" 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?
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. -
8. Re: JBAS-5895; Processing too many classes
alesj Sep 12, 2008 3:09 PM (in response to 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? :-) -
9. Re: JBAS-5895; Processing too many classes
starksm64 Sep 12, 2008 4:27 PM (in response to alesj)"alesj" wrote:
"scott.stark@jboss.org" 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". -
10. Re: JBAS-5895; Processing too many classes
alesj Sep 13, 2008 6:19 AM (in response to alesj)"scott.stark@jboss.org" wrote:
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. :-) -
11. Re: JBAS-5895; Processing too many classes
starksm64 Sep 13, 2008 4:26 PM (in response to alesj)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.
-
12. Re: JBAS-5895; Processing too many classes
adrian.brock Sep 15, 2008 7:39 AM (in response to alesj)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; }
-
13. Re: JBAS-5895; Processing too many classes
alesj Sep 15, 2008 7:46 AM (in response to alesj)"adrian@jboss.org" wrote:
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. -
14. Re: JBAS-5895; Processing too many classes
adrian.brock Sep 15, 2008 9:36 AM (in response to alesj)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.