Bugzilla (bugzilla.redhat.com) will be under maintenance for infrastructure upgrades and will not be available on July 31st between 12:30 AM - 05:30 AM UTC. We appreciate your understanding and patience. You can follow status.redhat.com for details.
Bug 970235 - SNOWDROP-52: Classpath scanning cannot access contexts from jars in dependecies
Summary: SNOWDROP-52: Classpath scanning cannot access contexts from jars in dependecies
Alias: None
Product: JBoss Enterprise WFK Platform 2
Classification: Retired
Component: Spring
Version: 2.2.0
Hardware: Unspecified
OS: Unspecified
Target Milestone: CR1
: 2.3.0
Assignee: Marek Novotny
QA Contact: Tomas Repel
Depends On:
Blocks: 975435
TreeView+ depends on / blocked
Reported: 2013-06-03 19:06 UTC by Ricardo Martinelli de Oliveira
Modified: 2013-07-16 11:07 UTC (History)
10 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Snowdrop VFS had a problem when installed with custom spring module in Enterprise Application Platform. Scanning of class path could not access contexts from jar(s) in its dependencies. As a consequence, Snowdrop VFS generated 'java.lang.IllegalArgumentException: Null path at org.jboss.vfs.VFS.getChild(VFS.java:187)' exception. This has been fixed by not using VFS for such dependency loading.
Clone Of:
: 975435 (view as bug list)
Last Closed: 2013-07-16 11:07:20 UTC
Type: Bug

Attachments (Terms of Use)

Description Ricardo Martinelli de Oliveira 2013-06-03 19:06:13 UTC
Description of problem:

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:

Actual results:

Expected results:

Additional info:

Comment 1 Ricardo Martinelli de Oliveira 2013-06-03 19:09:12 UTC
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.

Comment 4 Mustafa Musaji 2013-06-04 08:35:00 UTC
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.


Comment 5 Tejas Mehta 2013-06-04 21:11:07 UTC
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.

Comment 6 Marek Novotny 2013-06-05 07:44:33 UTC

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.

Comment 7 Tejas Mehta 2013-06-05 12:40:58 UTC
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.

Comment 8 Marek Schmidt 2013-06-05 13:57:53 UTC
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?

Comment 9 Ricardo Martinelli de Oliveira 2013-06-05 14:08:06 UTC
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.

Comment 10 Marek Schmidt 2013-06-05 14:22:01 UTC
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?

Comment 13 Tejas Mehta 2013-06-19 13:37:03 UTC
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.

Comment 14 Marek Novotny 2013-06-20 13:59:47 UTC
I will pick up the following commit https://github.com/snowdrop/snowdrop/commit/31bd771a4f057e954e3aad1e9abf99e45c3b5a9e

into Snowdrop prod branch

Comment 17 Tomas Repel 2013-06-26 10:02:30 UTC
Verified in WFK 2.3.0.CR1, EAP 6.1.0.

Comment 18 Sneha 2013-07-03 11:10:48 UTC
Updated doc text.

Note: This bug was not a known issue in wfk 2.2 RN.

Note You need to log in before you can comment on or make changes to this bug.