[ https://issues.jboss.org/browse/WELD-836?page=com.atlassian.jira.plugin.s... ] Krzysztof Maslak updated WELD-836: ---------------------------------- Description: 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. But it increases bootstrap so a concept of some filtering is required. was: 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. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/WELD-836?page=com.atlassian.jira.plugin.s... ] Krzysztof Maslak updated WELD-836: ---------------------------------- Summary: WELD should try to resolve injection points in webapp's jar files (was: WELD should try to resolve injection points in webapp's .jars) -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/WELD-836?page=com.atlassian.jira.plugin.s... ] Ales Justin commented on WELD-836: ---------------------------------- As Stuart said, this should already work. See WebAppBeanDeploymentArchive: URLScanner scanner = createScanner(servletContext); scanner.scanResources(new String[] { META_INF_BEANS_XML }, 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. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/WELD-836?page=com.atlassian.jira.plugin.s... ] Krzysztof Maslak commented on WELD-836: --------------------------------------- IMHO problem is that we are loosing access to vfs UrlStreamHandler as in 'handle' we have only path without vfs protocol. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/WELD-836?page=com.atlassian.jira.plugin.s... ] Ales Justin commented on WELD-836: ---------------------------------- So does 1.1: * https://github.com/weld/core/blob/1.1/environments/servlet/core/src/main/... Which is used here: * https://github.com/weld/core/blob/1.1/environments/servlet/core/src/main/... Which probably means it is part of 1.1.0.Final release. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/WELD-836?page=com.atlassian.jira.plugin.s... ] Ales Justin commented on WELD-836: ---------------------------------- 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. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira