PackageInformation retrieved from wrong jar

[ssilvert]

Perhaps we should discuss this here instead of in the jira?
https://jira.jboss.org/jira/browse/JBCL-43

Stan

[starksm64]

This is getting into the issue we are discussing here:
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4176244#4176244

where we are scanning too many files for classes, and picking up locations that should not be on the classpath. There is a standard lib location for libraries added to ears where these should be placed so that we are not recursively scanning too many locations.

For the two jars jboss-seam.jar, jboss-seam-booking.jar, they both have an org.jboss.seam package?

[ssilvert]

For the two jars jboss-seam.jar, jboss-seam-booking.jar, they both have an org.jboss.seam package?

No. They don't both have it. If they did then there would be no way to know which manifest to use.

But in this case, jboss-seam.jar has all the org.jboss.seam.MyClass.class files and jboss-seam-booking.jar has all the org.jboss.seam.booking.MyClass.class files.

Stan

[starksm64]

Let me look into why we are returning org.jboss.seam package info from the jboss-seam-booking.jar first then. Is this the same jboss-seam-booking.ear we are pulling into the jbossas testsuite?

[525][valkyrie: testsuite]$ jar -tf output/lib/seam/jboss-seam-booking.ear
META-INF/
META-INF/MANIFEST.MF
lib/
META-INF/application.xml
META-INF/jboss-app.xml
jboss-seam.jar
lib/commons-beanutils.jar
lib/commons-digester.jar
lib/jboss-el.jar
lib/richfaces-api.jar
jboss-seam-booking.jar
jboss-seam-booking.war

[alesj]

Is this the same jboss-seam-booking.ear we are pulling into the jbossas testsuite?

Yes.

Now I understand the cause behind why log info 'Seam version null'
sometimes popped up. :-)

[ssilvert]

"alesj" wrote:

Is this the same jboss-seam-booking.ear we are pulling into the jbossas testsuite?

Yes.

Now I understand the cause behind why log info 'Seam version null'
sometimes popped up. :-)

Right. That's the problem I've been working on.

The Seam numberguess example exhibits the same behavior. I've attached a version to the jira that has a special value for the implementation version in the jboss-seam-numberguess.jar. So you should now be able to see clearly how it is getting the manifest from the wrong jar.

Stan

[starksm64]

Why we are returning the wrong package is that the search for the matching file via the findVirtualFileInfo is not precisce enough to locate a package. We just find the first matching file:

 protected VirtualFileInfo findVirtualFileInfo(String path)
 {
 VirtualFileInfo result = vfsCache.get(path);
 if (result != null)
 return result;

 for (VirtualFile root : roots)
 {
 try
 {
 // Any jar with a class in the package or a subpackage will have a match
 VirtualFile file = root.getChild(path);

Stan's patch requires that the match either be a file that is a leaf, or a directory that contains at least one leaf. Since this method is only used to find class files or packages, this seems like an acceptable restriction.

[starksm64]

I added the following test to classloading-vfs which is currently failing:

Failed tests:
 testCorrectPackage(org.jboss.test.classloading.vfs.policy.test.PackageInfoUnitTestCase)

Tests run: 101, Failures: 1, Errors: 0, Skipped: 0

[ssilvert]

I committed the fix. The test now passes.

Stan

[adrian.brock]

This fix is not correct.

The real issue is that when we defineClass() it is using the package path
to decide which root to use when looking for the manifest.

The real fix is to pass the class name, so it can more accurately
determine the root.

Also, you committed the fix/test in the 2.2.x branch (trunk)
rather than Branch_2_0

[starksm64]

So your going to change getPackageInformation() to take a class rather than a package name?

[alesj]

So your going to change getPackageInformation() to take a class rather than a package name?

No, he added new method which takes classname and package name.
For back compatibility this method calls previous method,
only to be overridden in VFSClassLoaderPolicy.
There, instead of using package as path, we use class path.
- http://anonsvn.jboss.org/repos/jbossas/projects/jboss-cl/trunk/classloading-vfs/src/main/java/org/jboss/classloading/spi/vfs/policy/VFSClassLoaderPolicy.java