JBAS-6061 or weird nested jar| JBoss.org Content Archive (Read Only)

15. Re: JBAS-6061 or weird nested jar

jaikiran Jan 20, 2009 7:43 AM (in response to alesj)

"alesj" wrote:

Perhaps it's not getting passed from root to more exact handler ...

That appears to be the case. Do you want me to open a new JIRA in JBVFS project to track this? I did not reopen the existing one since its already marked as resolved for a released version.

16. Re: JBAS-6061 or weird nested jar

alesj Jan 20, 2009 7:50 AM (in response to alesj)

"jaikiran" wrote:
"alesj" wrote:

Perhaps it's not getting passed from root to more exact handler ...

That appears to be the case. Do you want me to open a new JIRA in JBVFS project to track this? I did not reopen the existing one since its already marked as resolved for a released version.

Can you reproduce this?
A test case would be perfect ... :-)

17. Re: JBAS-6061 or weird nested jar

jaikiran Jan 20, 2009 7:58 AM (in response to alesj)

It's reproducible, so yes i can add a testcase :)

18. Re: JBAS-6061 or weird nested jar

alesj Jan 20, 2009 8:11 AM (in response to alesj)

"jaikiran" wrote:
It's reproducible, so yes i can add a testcase :)

I guess you have the appropriate rights to put it directly into VFS?
If not, post it here, and I'll make sure it gets in.
If yes, just ping me that you're done (I would see it, if cvs/svn ml actually worked ...)

19. Re: JBAS-6061 or weird nested jar

jaikiran Jan 20, 2009 10:03 AM (in response to alesj)

I added a new test to the existing testcase org.jboss.test.virtual.test.ExceptionHandlerTestCase. Does this look good enough?

Index: src/test/java/org/jboss/test/virtual/test/ExceptionHandlerTestCase.java
===================================================================
--- src/test/java/org/jboss/test/virtual/test/ExceptionHandlerTestCase.java (revision 83104)
+++ src/test/java/org/jboss/test/virtual/test/ExceptionHandlerTestCase.java (working copy)
@@ -25,10 +25,12 @@
 import java.util.List;



 import junit.framework.Test;

+

 import org.jboss.virtual.VFS;

 import org.jboss.virtual.VirtualFile;

 import org.jboss.virtual.plugins.context.helpers.NamesExceptionHandler;



+

 /**

 * ExceptionHandlerTestCase.

 *

@@ -57,4 +59,29 @@
 List<VirtualFile> children = child.getChildren();

 assertTrue(children.isEmpty());

 }

+

+ /**

+ * Cover the parent folder containing the jar with a {@link ExceptionHandler}

+ * and then try to load the jar (present in the parent folder) to test

+ * whether the exceptionhandler is applied to the child jar as well

+ *

+ * @throws Exception

+ */

+ public void testExceptionHandlerForJarFiles() throws Exception

+ {

+ // Set a exception handler on parent folder

+ URL parentFolderURL = getResource("/vfs/test");

+ VFS parentFolderVFS = VFS.getVFS(parentFolderURL);

+ // let's add the sqljdbc.jar to the list of names that the exception handler has to handle

+ parentFolderVFS.setExceptionHandler(new NamesExceptionHandler("sqljdbc.jar"));

+

+ // Now let's create a VFS for the child jar

+ URL jarFileURL = getResource("/vfs/test/zipeinit.jar");

+ VFS jarFileVFS = VFS.getVFS(jarFileURL);

+ VirtualFile root = jarFileVFS.getRoot();

+ // time to access the messed up jar file. The NamesExceptionHandler is expected to handle this.

+ VirtualFile child = root.findChild("sqljdbc.jar");

+ List<VirtualFile> children = child.getChildren();

+ assertTrue(children.isEmpty());

+ }

 }

This one reproduces the error:

-------------------------------------------------------------------------------
Test set: org.jboss.test.virtual.test.ExceptionHandlerTestCase
-------------------------------------------------------------------------------
Tests run: 2, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.132 sec <<< FAILURE!
testExceptionHandlerForJarFiles(org.jboss.test.virtual.test.ExceptionHandlerTestCase) Time elapsed: 0.016 sec <<< ERROR!
java.lang.RuntimeException: Failed to read zip file: org.jboss.virtual.plugins.context.zip.ZipFileWrapper@1c74f37 - /tmp/vfs-nested.tmp/65e546ff_sqljdbc.jar
 at org.jboss.virtual.plugins.context.zip.ZipEntryContext.ensureEntries(ZipEntryContext.java:570)
 at org.jboss.virtual.plugins.context.zip.ZipEntryContext.checkIfModified(ZipEntryContext.java:700)
 at org.jboss.virtual.plugins.context.zip.ZipEntryContext.getChildren(ZipEntryContext.java:772)
 at org.jboss.virtual.plugins.context.zip.ZipEntryHandler.getChildren(ZipEntryHandler.java:149)
 at org.jboss.virtual.plugins.context.DelegatingHandler.getChildren(DelegatingHandler.java:120)
 at org.jboss.virtual.plugins.context.AbstractVFSContext.getChildren(AbstractVFSContext.java:171)
 at org.jboss.virtual.plugins.context.AbstractVFSContext.visit(AbstractVFSContext.java:288)
 at org.jboss.virtual.plugins.context.AbstractVFSContext.visit(AbstractVFSContext.java:258)
 at org.jboss.virtual.VFS.visit(VFS.java:429)
 at org.jboss.virtual.VirtualFile.visit(VirtualFile.java:423)
 at org.jboss.virtual.VirtualFile.getChildren(VirtualFile.java:372)
 at org.jboss.virtual.VirtualFile.getChildren(VirtualFile.java:353)
 at org.jboss.test.virtual.test.ExceptionHandlerTestCase.testExceptionHandlerForJarFiles(ExceptionHandlerTestCase.java:84)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
 at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
 at java.lang.reflect.Method.invoke(Method.java:585)
 at junit.framework.TestCase.runTest(TestCase.java:154)
 at junit.framework.TestCase.runBare(TestCase.java:127)
 at junit.framework.TestResult$1.protect(TestResult.java:106)
 at junit.framework.TestResult.runProtected(TestResult.java:124)
 at junit.framework.TestResult.run(TestResult.java:109)
 at junit.framework.TestCase.run(TestCase.java:118)
 at junit.framework.TestSuite.runTest(TestSuite.java:208)
 at junit.framework.TestSuite.run(TestSuite.java:203)
 at org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:81)
 at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:62)
 at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:138)
 at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:163)
 at org.apache.maven.surefire.Surefire.run(Surefire.java:84)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
 at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
 at java.lang.reflect.Method.invoke(Method.java:585)
 at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:261)
 at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:875)
Caused by: java.util.zip.ZipException: error in opening zip file
 at java.util.zip.ZipFile.open(Native Method)
 at java.util.zip.ZipFile.<init>(ZipFile.java:203)
 at java.util.zip.ZipFile.<init>(ZipFile.java:234)
 at org.jboss.virtual.plugins.context.zip.ZipFileWrapper.ensureZipFile(ZipFileWrapper.java:175)
 at org.jboss.virtual.plugins.context.zip.ZipFileWrapper.acquire(ZipFileWrapper.java:245)
 at org.jboss.virtual.plugins.context.zip.ZipEntryContext.initEntries(ZipEntryContext.java:466)
 at org.jboss.virtual.plugins.context.zip.ZipEntryContext.ensureEntries(ZipEntryContext.java:561)
 ... 35 more

I haven't commited the test since i am not sure what's the policy on commiting (without a fix) failing/error testcases.

P.S: I think there is a typo in this existing testcase:

// Jaikiran: Is this a typo? Or is this intentional? The _sqljdbc.jar should be sqljdbc.jar isn't it?
vfs.setExceptionHandler(new NamesExceptionHandler("_sqljdbc.jar"));
 VirtualFile root = vfs.getRoot();
 VirtualFile zipeinit = root.findChild("zipeinit.jar");
 VirtualFile child = zipeinit.findChild("sqljdbc.jar");

20. Re: JBAS-6061 or weird nested jar

alesj Jan 20, 2009 10:21 AM (in response to alesj)

"jaikiran" wrote:
I added a new test to the existing testcase org.jboss.test.virtual.test.ExceptionHandlerTestCase. Does this look good enough?

Aha, I see where the problem is.
It's this lines:
(*)

URL jarFileURL = getResource("/vfs/test/zipeinit.jar");
VFS jarFileVFS = VFS.getVFS(jarFileURL);
VirtualFile root = jarFileVFS.getRoot();

as you're by-passing previous cached root.

VFS parentFolderVFS = VFS.getVFS(parentFolderURL); // <-- CACHED HERE

We need to fix the code (btw: where is this?) that does this,
to use the right VFS method, the one that uses cache.
(*) should be re-written to use this:

URL jarFileURL = getResource("/vfs/test/zipeinit.jar");
VirtualFile root = VFS.getCachedFile(jarFileURL);

"jaikiran" wrote:

P.S: I think there is a typo in this existing testcase:
// Jaikiran: Is this a typo? Or is this intentional? The _sqljdbc.jar should be sqljdbc.jar isn't it?

It doesn't matter actually.
With '_' it's just more precise on the fact that it matches only true temp names.

21. Re: JBAS-6061 or weird nested jar

dimitris Jan 20, 2009 1:42 PM (in response to alesj)

Obviously I'm totally ignorant but shouldn't caching be an internal implementation detail of the VFS api? I.e. why you need a VFS.getCachedFile(...)?

22. Re: JBAS-6061 or weird nested jar

jaikiran Jan 21, 2009 1:38 AM (in response to alesj)

"alesj" wrote:
We need to fix the code (btw: where is this?) that does this,
to use the right VFS method, the one that uses cache.

Finally, found some time to debug and figure out what and where the issue is. This is what is happening:

server/< serverName>/conf/jboss-service.xml is being picked up by org.jboss.system.deployers.SARDeployer which has this:

String codebase = path.getCodeBase();
 String archives = path.getArchives();

 log.debug("Processing classpath: " + unit.getName() + " codebase=" + codebase + " archives=" + archives);
 VirtualFile codebaseFile = unit.getRoot();
 if (".".equals(codebase) == false)
 {
 ServerConfig config = ServerConfigLocator.locate();
 URL codeBaseURL = new URL(config.getServerHomeURL(), codebase);
 codebaseFile = VFS.getVirtualFile(codeBaseURL, "");
 }

The 2 variants of VFS.getVirtualFile() have this:

public static VirtualFile getVirtualFile(URI rootURI, String name) throws IOException
 {
 VFS vfs = getVFS(rootURI);
 return vfs.findChild(name);
 }

The context associated with this returned VirtualFile does not have the exception handler associated with it. Based on your post about the caching API, i decided to change these 2 methods to:

public static VirtualFile getVirtualFile(URI rootURI, String name) throws IOException
 {
 VirtualFile vf = getCachedFile(rootURI);
 return vf.getChild(name);
 }

This change fixed the problem and i was able to boot JBossAS. I don't know much about VFS internals (and i don't know whether was i did can be termed as a fix :) ), but as Dimitris says:

"dimitris@jboss.org" wrote:
Obviously I'm totally ignorant but shouldn't caching be an internal implementation detail of the VFS api? I.e. why you need a VFS.getCachedFile(...)?

So, shouldn't the exception handler be associated with a context irrespective of whether it is cached or not?

23. Re: JBAS-6061 or weird nested jar

alesj Jan 21, 2009 10:14 AM (in response to alesj)

Moving this to dev forum:
- http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4203668#4203668