Description of problem: Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
I have snowdrop and spring 3.1.0.RELEASE installed as jboss modules and also a custom module com.mycomapny:main In a ServletContextListener I manually create an VFSClassPathXmlApplicationContext. It does classpath scanning for "classpath*:/META-INF/spring/platform/*-context.xml" and correctly finds a *-context.xml located in a jar that is part of com.mycomapny:main declared as a dependency. While initialising I get this: Caused by: java.lang.IllegalArgumentException: Null path at org.jboss.vfs.VFS.getChild(VFS.java:187) [jboss-vfs-3.1.0.Final.jar:3.1.0.Final] at org.jboss.vfs.VFS.getChild(VFS.java:173) [jboss-vfs-3.1.0.Final.jar:3.1.0.Final] at org.jboss.vfs.VFS.getChild(VFS.java:154) [jboss-vfs-3.1.0.Final.jar:3.1.0.Final] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.6.0_26] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [rt.jar:1.6.0_26] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [rt.jar:1.6.0_26] at java.lang.reflect.Method.invoke(Method.java:597) [rt.jar:1.6.0_26] at org.jboss.spring.vfs.VFSUtil.invokeMethodWithExpectedExceptionType(VFSUtil.java:157) [snowdrop-vfs.jar:2.0.2.Final] at org.jboss.spring.vfs.VFSResource.getChild(VFSResource.java:153) [snowdrop-vfs.jar:2.0.2.Final] This exception is caused by this URL "jar:file:/home/jvassev/projects/install-5.1/jboss7/modules/com/mycompany/main/utils-1.1.0-SNAPSHOT.jar!/META-INF/spring/platform/". When converted to an URI it has a null path.
This does have an upstream fix (https://issues.jboss.org/browse/SNOWDROP-52) but Ricardo can perhaps give some background because that fix isn't closed. So, two questions need answering: 1) Is it necessary for us to fix this upstream and get it in to the WFK 2.3 snowdrop? If so, we need a bugzilla/JIRA for this component upgrade or backport (depending on the version the fix has gone in upstream). SNOWDROP-52 is "coding in progress" but this one off is complete which is based of that, that confuses me a bit Ricardo? 2) Is the workaround on SNOWDROP-52 valid? If not why? (i.e. justification for one off and fix to be put in upstream) I'm setting the NeedInfo flag to the GSS engineer (Ricardo) who raised this to answer these. Thanks Mus
I may have answers to parts of those questions, since I worked on the fix: 1) I had set the status to "coding in progress", but since it is now fixed (based on what Ricardo told me) I should mark it closed? 2) The workaround is partially valid, in that it is required, but it didn't solve the issue that Ricardo brought to me. The additional fix has been added to the upstream here: https://github.com/snowdrop/snowdrop/commit/62d44cd673d4a7e8770c630fb03df33c73f5fe27. The problem was with JBoss VFS not treating jar paths separately. Here is another relevant JIRA: https://issues.jboss.org/browse/WFLY-856?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel. Hopefully that resolves some of the confusion.
@Tejas: ad 1) yes, you should mark it as resolved if it is fixed in snowdrop. ad 2) my question is if https://github.com/snowdrop/snowdrop/commit/62d44cd673d4a7e8770c630fb03df33c73f5fe27 is only one change on Snowdrop side to fix the problem? Next if not and a fix need to be in EAP/AS, then we need to coordinate also EAP 6.0.1 patching otherwise it won't be full fix, right? P.S. Wildfly fix/patch doesn't count as we need it in supported EAP 6.
1) Marked it Resolved. 2) https://github.com/snowdrop/snowdrop/commit/62d44cd673d4a7e8770c630fb03df33c73f5fe27 is the only change on the snowdrop side required to fix the problem for Spring applications that rely on Spring Deployer for deployment (i.e. *.spring deployments). There was no modification made to Wildfly/EAP. Though I do believe that if and when https://issues.jboss.org/browse/WFLY-856?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel is resolved and added to EAP some parts of the fix can be updated/removed.
That patch does look like a very strange hack. I am not sure if I understand the core issue correctly, but if the core of the problem is in the EAP VFS, shouldn't we try to fix that and make an EAP one-off instead?
The error that comes from VFS side is very generic and still not reproducible. I know Seam also have problems with that. If we'll rely on VFS team fix the issue, we can't wait for next EAP release because it is a blocking issue to the customer and we already offered the one-off patch to them. Also, the workaround was verified and works, but is not accepted by the customer.
We don't have to wait for an EAP release, we can do an EAP one-off, if we are able to do that and we should do that if the problem is in fact there. Have you talked with the VFS team about this issue? Did they not acknowledge the issue or just not wanted to fix it?
After advice from the eap support team, here is more elegant fix: https://github.com/snowdrop/snowdrop/commit/31bd771a4f057e954e3aad1e9abf99e45c3b5a9e. Instead of manually mounting the static module, this simply delegates to Spring if the resource is a non-vfs resource.
I will pick up the following commit https://github.com/snowdrop/snowdrop/commit/31bd771a4f057e954e3aad1e9abf99e45c3b5a9e into Snowdrop prod branch
committed as http://git.app.eng.bos.redhat.com/?p=snowdrop/snowdrop.git;a=commit;h=436a4ad9e367bd93364b84b0534a6a932dbdb77d
Verified in WFK 2.3.0.CR1, EAP 6.1.0.
Updated doc text. Note: This bug was not a known issue in wfk 2.2 RN.