-
Feature Request
-
Resolution: Won't Do
-
Major
-
None
-
None
-
None
-
None
Having following example scenario:
webapp.war
- /WEB-INF/lib/jar-with-some-nice-business-logic.jar - contains some injection points ( i.e. ICacheManager ) and using DefaultBean shipped with SeamSolder a default implementation ( as the injection points have to be satisfied )
- /WEB-INF/lib/caching-solution-provider.jar - provides CacheManagerImpl
Having this simple example I would like to have this injection point satisfied by this caching-solution-provider.jar. With such solution I would be able to change my caching-solution-provider.jar without any code modification just by changing dependency in pom.xml for another cache provider which would be able to satisfy my contract.
Then my development process would be similar to development in OSGi and blueprint as DI provider. I would care only about fulfilling the contracts by various artefacts.
[WELD-836] WELD should try to resolve injection points in webapp's jar files
Ah, OK, that explains it – JBossAS7 usage.
We have a full integration planned there (same as in JBossAS6),
hence no need for custom Scanner.
Perhaps have a look at current work on AS7+Weld integration:
- https://github.com/stuartwdouglas/jboss-as/tree/weldIntegration
And any patches (e.g. new Git branches / features) are always welcome.
The VFS scanner was added in order to make Weld play nicely in JBossAS5.
Perhaps you can just re-write that scanner to VFS3 and see if it works in AS7.
Krzysztof Maslak (Inactive)
added a comment - I run my example in JBoss AS7. The source of my confusion was that VFSURLScanner was not performing scanning of the given jars. AS7 is shipped with jboss-vfs-3.0.0.CR5. Current WELD implementation uses JBoss-vfs 2.1.3.SP1. There are number of cool improvements with this new vfs version but my issue is that, in the visit method ( that is triggered in VFSURLScanner ) inside VirtualFile there is a guard which check if the scanned file isDirectory ( it checks against filesystem ) whereas before there was isLeaf with check against provided handler. The scanning of those jars stops there, as they are not recognized as directories.
Krzysztof Maslak (Inactive)
added a comment - I run my example in JBoss AS7. The source of my confusion was that VFSURLScanner was not performing scanning of the given jars. AS7 is shipped with jboss-vfs-3.0.0.CR5. Current WELD implementation uses JBoss-vfs 2.1.3.SP1. There are number of cool improvements with this new vfs version but my issue is that, in the visit method ( that is triggered in VFSURLScanner ) inside VirtualFile there is a guard which check if the scanned file isDirectory ( it checks against filesystem ) whereas before there was isLeaf with check against provided handler. The scanning of those jars stops there, as they are not recognized as directories. So does 1.1:
- https://github.com/weld/core/blob/1.1/environments/servlet/core/src/main/java/org/jboss/weld/environment/servlet/deployment/VFSURLScanner.java
Which is used here: - https://github.com/weld/core/blob/1.1/environments/servlet/core/src/main/java/org/jboss/weld/environment/servlet/Listener.java
Which probably means it is part of 1.1.0.Final release.
In which environment are you running this?
Current Weld master already has a VFS based scanner: VFSURLScanner,
which should handle this issue.
Krzysztof Maslak (Inactive)
added a comment - IMHO problem is that we are loosing access to vfs UrlStreamHandler as in 'handle' we have only path without vfs protocol.
Krzysztof Maslak (Inactive)
added a comment - IMHO problem is that we are loosing access to vfs UrlStreamHandler as in 'handle' we have only path without vfs protocol. Krzysztof Maslak (Inactive)
added a comment - Yes, you are right, the existing logic should handle this situation 
.
I have beans.xml placed in my jars and they are being picked up, but the scanning does not occur.
What happens is that it returns me correctly URLs. Then 'handle' method tries to process file or directory, but the file with the given path doesn't exist.
I was not following jboss neither weld before, so I can be wrong.
I think that the problem might be that, those are virtual files and using getFile on them to get the path and then using this path with java.io.File creates this problem as those files are not there.
This method is used along the road
URL VFSUtils.getVirtualURL(VirtualFile file)
and this is part of javadoc for this method:
- Get the virtual URL for a virtual file. This URL can be used to access the virtual file; however, taking the file
- part of the URL and attempting to use it with the
{@link java.io.File}
class may fail if the file is not present
- on the physical filesystem, and in general should not be attempted.
Krzysztof Maslak (Inactive)
added a comment - Yes, you are right, the existing logic should handle this situation .
I have beans.xml placed in my jars and they are being picked up, but the scanning does not occur.
What happens is that it returns me correctly URLs. Then 'handle' method tries to process file or directory, but the file with the given path doesn't exist.
I was not following jboss neither weld before, so I can be wrong.
I think that the problem might be that, those are virtual files and using getFile on them to get the path and then using this path with java.io.File creates this problem as those files are not there.
This method is used along the road
URL VFSUtils.getVirtualURL(VirtualFile file)
and this is part of javadoc for this method:
Get the virtual URL for a virtual file. This URL can be used to access the virtual file; however, taking the file
part of the URL and attempting to use it with the
{@link java.io.File}
class may fail if the file is not present
on the physical filesystem, and in general should not be attempted.
As Stuart said, this should already work.
See WebAppBeanDeploymentArchive:
URLScanner scanner = createScanner(servletContext);
scanner.scanResources(new String[]
, classes, urls);
and
public void scanResources(String[] resources, Set<String> classes, Set<URL> urls)
{
Set<String> paths = new HashSet<String>();
for (String resourceName : resources)
{
try
{
Enumeration<URL> urlEnum = classLoader.getResources(resourceName); <--- HERE
At HERE your "impl" module should be picked-up, if it had beans.xml in jar' META-INF.
Weld Servlet should already do this. Are you sure that you have a bean.xml file in he jar you want scanned?
Krzysztof Maslak (Inactive)
added a comment - Prof of concept 
Closing as won't fix. The Weld Servlet support only targets JBoss AS 5 (EAP 5), Tomcat, Jetty and GAE.
As Ales mentions, we plan proper integration (actually Stuart has most of it done) for AS7 Beta1 (the next milestone) so far better to concentrate on helping out with that work than hacking the Servlet module to work!
Comment back if you want to help with that, Stuart can get you started.