[jira] [Commented] (DELTASPIKE-648) @ConfigProperty in Wildfly 8.1 not working correctly
[ https://issues.apache.org/jira/browse/DELTASPIKE-648?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14350276#comment-14350276 ] Mark Struberg commented on DELTASPIKE-648: -- weird, checking the history gerhard clearly did set the fixed version to 1.3.0 4 days ago. Changed it back to 1.3.0 now - txs! @ConfigProperty in Wildfly 8.1 not working correctly Key: DELTASPIKE-648 URL: https://issues.apache.org/jira/browse/DELTASPIKE-648 Project: DeltaSpike Issue Type: Bug Components: Configuration Affects Versions: 1.0.0 Environment: Mac OS X 10.9, Java 1.7.45, Wildfly 8.1 Reporter: Sven Panko Assignee: Mark Struberg Priority: Minor Fix For: 1.3.0 Attachments: DELTASPIKE-648.patch I am not quite sure if my problem is related to the (already closed) DELTASPIKE-451, but it is quite similar in behavior: * I have an EAR file that packages a few EJB jars (these are NOT contained in the lib directory of the EAR) * the application.xml uses the default isolation mechanism, which means that all libs in /lib have access to all classes (although I don't think this is relevant in my case since my EJB jars are not located in /lib) * inside one of the EJB jars I put a property file that should be used ONLY by beans inside this jar file * I created an implementation of PropertyFileConfig and provided the path to this property file * during startup I can see that the property file is correctly detected and stored in the hashmap using the EAR classloader * I have a bean (@Singleton, @Startup) inside the aforementioned EJB jar that expects a property to be injected via @Inject @ConfigProperty - which does not work I debugged the startup process and detected that the property injection into the bean fails because the lookup into the hashmap will not be done with the EAR classloader, but with the jar's classloader, which is totally understandable. What I do not understand, however, is, why the resolution process which kicks in afterwards does no longer find my PropertyFileConfig implementation, which worked in the EAR classloader case. My temporary solution now is to put a META-INF/services/org.apache.deltaspike.core.spi.config.ConfigSourceProvider file into the EJB jar and reference a custom ConfigSourceProvider. This file is always picked up correctly (interestingly in both cases, the EAR classloader and the jar classloader). Shouldn't the ConfigResolver pick up my PropertyFileConfig implementation in both cases as well? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DELTASPIKE-648) @ConfigProperty in Wildfly 8.1 not working correctly
[ https://issues.apache.org/jira/browse/DELTASPIKE-648?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14350265#comment-14350265 ] John D. Ament commented on DELTASPIKE-648: -- Any idea why this is fix for 1.3.1 instead of 1.3.0? Looks like its in the 1.3.0 code base. @ConfigProperty in Wildfly 8.1 not working correctly Key: DELTASPIKE-648 URL: https://issues.apache.org/jira/browse/DELTASPIKE-648 Project: DeltaSpike Issue Type: Bug Components: Configuration Affects Versions: 1.0.0 Environment: Mac OS X 10.9, Java 1.7.45, Wildfly 8.1 Reporter: Sven Panko Assignee: Mark Struberg Priority: Minor Fix For: 1.3.1 Attachments: DELTASPIKE-648.patch I am not quite sure if my problem is related to the (already closed) DELTASPIKE-451, but it is quite similar in behavior: * I have an EAR file that packages a few EJB jars (these are NOT contained in the lib directory of the EAR) * the application.xml uses the default isolation mechanism, which means that all libs in /lib have access to all classes (although I don't think this is relevant in my case since my EJB jars are not located in /lib) * inside one of the EJB jars I put a property file that should be used ONLY by beans inside this jar file * I created an implementation of PropertyFileConfig and provided the path to this property file * during startup I can see that the property file is correctly detected and stored in the hashmap using the EAR classloader * I have a bean (@Singleton, @Startup) inside the aforementioned EJB jar that expects a property to be injected via @Inject @ConfigProperty - which does not work I debugged the startup process and detected that the property injection into the bean fails because the lookup into the hashmap will not be done with the EAR classloader, but with the jar's classloader, which is totally understandable. What I do not understand, however, is, why the resolution process which kicks in afterwards does no longer find my PropertyFileConfig implementation, which worked in the EAR classloader case. My temporary solution now is to put a META-INF/services/org.apache.deltaspike.core.spi.config.ConfigSourceProvider file into the EJB jar and reference a custom ConfigSourceProvider. This file is always picked up correctly (interestingly in both cases, the EAR classloader and the jar classloader). Shouldn't the ConfigResolver pick up my PropertyFileConfig implementation in both cases as well? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DELTASPIKE-648) @ConfigProperty in Wildfly 8.1 not working correctly
[ https://issues.apache.org/jira/browse/DELTASPIKE-648?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14329112#comment-14329112 ] Bartosz Majsak commented on DELTASPIKE-648: --- Hi guys, this bug hurts us a lot at the moment. With latest build from develop it's obviously gone. Is there a plan for a 1.2.2 release anytime soon? @ConfigProperty in Wildfly 8.1 not working correctly Key: DELTASPIKE-648 URL: https://issues.apache.org/jira/browse/DELTASPIKE-648 Project: DeltaSpike Issue Type: Bug Components: Configuration Affects Versions: 1.0.0 Environment: Mac OS X 10.9, Java 1.7.45, Wildfly 8.1 Reporter: Sven Panko Assignee: Mark Struberg Priority: Minor Fix For: 1.0.1 Attachments: DELTASPIKE-648.patch I am not quite sure if my problem is related to the (already closed) DELTASPIKE-451, but it is quite similar in behavior: * I have an EAR file that packages a few EJB jars (these are NOT contained in the lib directory of the EAR) * the application.xml uses the default isolation mechanism, which means that all libs in /lib have access to all classes (although I don't think this is relevant in my case since my EJB jars are not located in /lib) * inside one of the EJB jars I put a property file that should be used ONLY by beans inside this jar file * I created an implementation of PropertyFileConfig and provided the path to this property file * during startup I can see that the property file is correctly detected and stored in the hashmap using the EAR classloader * I have a bean (@Singleton, @Startup) inside the aforementioned EJB jar that expects a property to be injected via @Inject @ConfigProperty - which does not work I debugged the startup process and detected that the property injection into the bean fails because the lookup into the hashmap will not be done with the EAR classloader, but with the jar's classloader, which is totally understandable. What I do not understand, however, is, why the resolution process which kicks in afterwards does no longer find my PropertyFileConfig implementation, which worked in the EAR classloader case. My temporary solution now is to put a META-INF/services/org.apache.deltaspike.core.spi.config.ConfigSourceProvider file into the EJB jar and reference a custom ConfigSourceProvider. This file is always picked up correctly (interestingly in both cases, the EAR classloader and the jar classloader). Shouldn't the ConfigResolver pick up my PropertyFileConfig implementation in both cases as well? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DELTASPIKE-648) @ConfigProperty in Wildfly 8.1 not working correctly
[ https://issues.apache.org/jira/browse/DELTASPIKE-648?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14329165#comment-14329165 ] Bartosz Majsak commented on DELTASPIKE-648: --- It's not about the fix nor support of WF 8.1, actual fix introduced the regression which Mark reverted and it is already pushed to master branch. @ConfigProperty in Wildfly 8.1 not working correctly Key: DELTASPIKE-648 URL: https://issues.apache.org/jira/browse/DELTASPIKE-648 Project: DeltaSpike Issue Type: Bug Components: Configuration Affects Versions: 1.0.0 Environment: Mac OS X 10.9, Java 1.7.45, Wildfly 8.1 Reporter: Sven Panko Assignee: Mark Struberg Priority: Minor Fix For: 1.0.1, 1.2.2 Attachments: DELTASPIKE-648.patch I am not quite sure if my problem is related to the (already closed) DELTASPIKE-451, but it is quite similar in behavior: * I have an EAR file that packages a few EJB jars (these are NOT contained in the lib directory of the EAR) * the application.xml uses the default isolation mechanism, which means that all libs in /lib have access to all classes (although I don't think this is relevant in my case since my EJB jars are not located in /lib) * inside one of the EJB jars I put a property file that should be used ONLY by beans inside this jar file * I created an implementation of PropertyFileConfig and provided the path to this property file * during startup I can see that the property file is correctly detected and stored in the hashmap using the EAR classloader * I have a bean (@Singleton, @Startup) inside the aforementioned EJB jar that expects a property to be injected via @Inject @ConfigProperty - which does not work I debugged the startup process and detected that the property injection into the bean fails because the lookup into the hashmap will not be done with the EAR classloader, but with the jar's classloader, which is totally understandable. What I do not understand, however, is, why the resolution process which kicks in afterwards does no longer find my PropertyFileConfig implementation, which worked in the EAR classloader case. My temporary solution now is to put a META-INF/services/org.apache.deltaspike.core.spi.config.ConfigSourceProvider file into the EJB jar and reference a custom ConfigSourceProvider. This file is always picked up correctly (interestingly in both cases, the EAR classloader and the jar classloader). Shouldn't the ConfigResolver pick up my PropertyFileConfig implementation in both cases as well? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DELTASPIKE-648) @ConfigProperty in Wildfly 8.1 not working correctly
[ https://issues.apache.org/jira/browse/DELTASPIKE-648?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14329189#comment-14329189 ] Mark Struberg commented on DELTASPIKE-648: -- [~majson] The problem is that the original 'fix' reduced DeltaSpike to run exactly with the very same single Configuration for the WHOLE SERVER. Of course this fixed the sample and probably your project (if you just use DS config in one app and no modules) but it broken tons of other projects/applications. @ConfigProperty in Wildfly 8.1 not working correctly Key: DELTASPIKE-648 URL: https://issues.apache.org/jira/browse/DELTASPIKE-648 Project: DeltaSpike Issue Type: Bug Components: Configuration Affects Versions: 1.0.0 Environment: Mac OS X 10.9, Java 1.7.45, Wildfly 8.1 Reporter: Sven Panko Assignee: Mark Struberg Priority: Minor Fix For: 1.0.1, 1.2.2 Attachments: DELTASPIKE-648.patch I am not quite sure if my problem is related to the (already closed) DELTASPIKE-451, but it is quite similar in behavior: * I have an EAR file that packages a few EJB jars (these are NOT contained in the lib directory of the EAR) * the application.xml uses the default isolation mechanism, which means that all libs in /lib have access to all classes (although I don't think this is relevant in my case since my EJB jars are not located in /lib) * inside one of the EJB jars I put a property file that should be used ONLY by beans inside this jar file * I created an implementation of PropertyFileConfig and provided the path to this property file * during startup I can see that the property file is correctly detected and stored in the hashmap using the EAR classloader * I have a bean (@Singleton, @Startup) inside the aforementioned EJB jar that expects a property to be injected via @Inject @ConfigProperty - which does not work I debugged the startup process and detected that the property injection into the bean fails because the lookup into the hashmap will not be done with the EAR classloader, but with the jar's classloader, which is totally understandable. What I do not understand, however, is, why the resolution process which kicks in afterwards does no longer find my PropertyFileConfig implementation, which worked in the EAR classloader case. My temporary solution now is to put a META-INF/services/org.apache.deltaspike.core.spi.config.ConfigSourceProvider file into the EJB jar and reference a custom ConfigSourceProvider. This file is always picked up correctly (interestingly in both cases, the EAR classloader and the jar classloader). Shouldn't the ConfigResolver pick up my PropertyFileConfig implementation in both cases as well? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DELTASPIKE-648) @ConfigProperty in Wildfly 8.1 not working correctly
[ https://issues.apache.org/jira/browse/DELTASPIKE-648?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14329146#comment-14329146 ] John D. Ament commented on DELTASPIKE-648: -- do you think we really need to support wildfly 8.0 at this point? what about AS7, or it'll be an issue w/ the EAP builds? @ConfigProperty in Wildfly 8.1 not working correctly Key: DELTASPIKE-648 URL: https://issues.apache.org/jira/browse/DELTASPIKE-648 Project: DeltaSpike Issue Type: Bug Components: Configuration Affects Versions: 1.0.0 Environment: Mac OS X 10.9, Java 1.7.45, Wildfly 8.1 Reporter: Sven Panko Assignee: Mark Struberg Priority: Minor Fix For: 1.0.1, 1.2.2 Attachments: DELTASPIKE-648.patch I am not quite sure if my problem is related to the (already closed) DELTASPIKE-451, but it is quite similar in behavior: * I have an EAR file that packages a few EJB jars (these are NOT contained in the lib directory of the EAR) * the application.xml uses the default isolation mechanism, which means that all libs in /lib have access to all classes (although I don't think this is relevant in my case since my EJB jars are not located in /lib) * inside one of the EJB jars I put a property file that should be used ONLY by beans inside this jar file * I created an implementation of PropertyFileConfig and provided the path to this property file * during startup I can see that the property file is correctly detected and stored in the hashmap using the EAR classloader * I have a bean (@Singleton, @Startup) inside the aforementioned EJB jar that expects a property to be injected via @Inject @ConfigProperty - which does not work I debugged the startup process and detected that the property injection into the bean fails because the lookup into the hashmap will not be done with the EAR classloader, but with the jar's classloader, which is totally understandable. What I do not understand, however, is, why the resolution process which kicks in afterwards does no longer find my PropertyFileConfig implementation, which worked in the EAR classloader case. My temporary solution now is to put a META-INF/services/org.apache.deltaspike.core.spi.config.ConfigSourceProvider file into the EJB jar and reference a custom ConfigSourceProvider. This file is always picked up correctly (interestingly in both cases, the EAR classloader and the jar classloader). Shouldn't the ConfigResolver pick up my PropertyFileConfig implementation in both cases as well? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DELTASPIKE-648) @ConfigProperty in Wildfly 8.1 not working correctly
[ https://issues.apache.org/jira/browse/DELTASPIKE-648?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14329167#comment-14329167 ] Mark Struberg commented on DELTASPIKE-648: -- [~johndament]] I fear all JBoss containers are broken with EARs. This problem is actually not a fault of DeltaSpike to be honest. But I think we still need to support it. [~majson] I was working like mad on this for the last week or so. You might probably already have read the blog I wrote about the various containers and how they work https://struberg.wordpress.com/2015/02/18/cdi-in-ears/ I also wrote a smallish EAR which just logs out a bit of information about ClassLoaders, TCCL, scanned beans, etc https://github.com/struberg/cdi-ear-test If you let this run on WildFly or JBossAS then you will quickly see the issue. The Extension from WAR1 will also get fed with the classes from WAR2 and the other way around. If you have an Extension only in the EAR-lib it will automatically pick up the classes from ALL WARs as well. Thus our SetClass? extends ConfigSourceProvider might contain classes which you actually MUST NOT SEE. I'm still trying to get my head around it and I have the gut feeling that I might have found a pretty generic solution for this issue. But I still need to test this out on various servers. @ConfigProperty in Wildfly 8.1 not working correctly Key: DELTASPIKE-648 URL: https://issues.apache.org/jira/browse/DELTASPIKE-648 Project: DeltaSpike Issue Type: Bug Components: Configuration Affects Versions: 1.0.0 Environment: Mac OS X 10.9, Java 1.7.45, Wildfly 8.1 Reporter: Sven Panko Assignee: Mark Struberg Priority: Minor Fix For: 1.0.1, 1.2.2 Attachments: DELTASPIKE-648.patch I am not quite sure if my problem is related to the (already closed) DELTASPIKE-451, but it is quite similar in behavior: * I have an EAR file that packages a few EJB jars (these are NOT contained in the lib directory of the EAR) * the application.xml uses the default isolation mechanism, which means that all libs in /lib have access to all classes (although I don't think this is relevant in my case since my EJB jars are not located in /lib) * inside one of the EJB jars I put a property file that should be used ONLY by beans inside this jar file * I created an implementation of PropertyFileConfig and provided the path to this property file * during startup I can see that the property file is correctly detected and stored in the hashmap using the EAR classloader * I have a bean (@Singleton, @Startup) inside the aforementioned EJB jar that expects a property to be injected via @Inject @ConfigProperty - which does not work I debugged the startup process and detected that the property injection into the bean fails because the lookup into the hashmap will not be done with the EAR classloader, but with the jar's classloader, which is totally understandable. What I do not understand, however, is, why the resolution process which kicks in afterwards does no longer find my PropertyFileConfig implementation, which worked in the EAR classloader case. My temporary solution now is to put a META-INF/services/org.apache.deltaspike.core.spi.config.ConfigSourceProvider file into the EJB jar and reference a custom ConfigSourceProvider. This file is always picked up correctly (interestingly in both cases, the EAR classloader and the jar classloader). Shouldn't the ConfigResolver pick up my PropertyFileConfig implementation in both cases as well? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DELTASPIKE-648) @ConfigProperty in Wildfly 8.1 not working correctly
[ https://issues.apache.org/jira/browse/DELTASPIKE-648?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14329232#comment-14329232 ] Mark Struberg commented on DELTASPIKE-648: -- Can you do me a favor and run the cdi-ear-test sample on JBossEAP6 and copy to result to pastie or gist? That would help us to get more info about Extensions are handled in EARs in this container - txs! @ConfigProperty in Wildfly 8.1 not working correctly Key: DELTASPIKE-648 URL: https://issues.apache.org/jira/browse/DELTASPIKE-648 Project: DeltaSpike Issue Type: Bug Components: Configuration Affects Versions: 1.0.0 Environment: Mac OS X 10.9, Java 1.7.45, Wildfly 8.1 Reporter: Sven Panko Assignee: Mark Struberg Priority: Minor Fix For: 1.0.1, 1.2.2 Attachments: DELTASPIKE-648.patch I am not quite sure if my problem is related to the (already closed) DELTASPIKE-451, but it is quite similar in behavior: * I have an EAR file that packages a few EJB jars (these are NOT contained in the lib directory of the EAR) * the application.xml uses the default isolation mechanism, which means that all libs in /lib have access to all classes (although I don't think this is relevant in my case since my EJB jars are not located in /lib) * inside one of the EJB jars I put a property file that should be used ONLY by beans inside this jar file * I created an implementation of PropertyFileConfig and provided the path to this property file * during startup I can see that the property file is correctly detected and stored in the hashmap using the EAR classloader * I have a bean (@Singleton, @Startup) inside the aforementioned EJB jar that expects a property to be injected via @Inject @ConfigProperty - which does not work I debugged the startup process and detected that the property injection into the bean fails because the lookup into the hashmap will not be done with the EAR classloader, but with the jar's classloader, which is totally understandable. What I do not understand, however, is, why the resolution process which kicks in afterwards does no longer find my PropertyFileConfig implementation, which worked in the EAR classloader case. My temporary solution now is to put a META-INF/services/org.apache.deltaspike.core.spi.config.ConfigSourceProvider file into the EJB jar and reference a custom ConfigSourceProvider. This file is always picked up correctly (interestingly in both cases, the EAR classloader and the jar classloader). Shouldn't the ConfigResolver pick up my PropertyFileConfig implementation in both cases as well? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DELTASPIKE-648) @ConfigProperty in Wildfly 8.1 not working correctly
[ https://issues.apache.org/jira/browse/DELTASPIKE-648?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14329423#comment-14329423 ] Bartosz Majsak commented on DELTASPIKE-648: --- There you go https://gist.github.com/bartoszmajsak/fe173fc2e3a652e6bd1d If you need other versions of EAP I can also provide you logs from these environments. And now to the original question :) When do you plan to release 1.2.2? @ConfigProperty in Wildfly 8.1 not working correctly Key: DELTASPIKE-648 URL: https://issues.apache.org/jira/browse/DELTASPIKE-648 Project: DeltaSpike Issue Type: Bug Components: Configuration Affects Versions: 1.0.0 Environment: Mac OS X 10.9, Java 1.7.45, Wildfly 8.1 Reporter: Sven Panko Assignee: Mark Struberg Priority: Minor Fix For: 1.0.1, 1.2.2 Attachments: DELTASPIKE-648.patch I am not quite sure if my problem is related to the (already closed) DELTASPIKE-451, but it is quite similar in behavior: * I have an EAR file that packages a few EJB jars (these are NOT contained in the lib directory of the EAR) * the application.xml uses the default isolation mechanism, which means that all libs in /lib have access to all classes (although I don't think this is relevant in my case since my EJB jars are not located in /lib) * inside one of the EJB jars I put a property file that should be used ONLY by beans inside this jar file * I created an implementation of PropertyFileConfig and provided the path to this property file * during startup I can see that the property file is correctly detected and stored in the hashmap using the EAR classloader * I have a bean (@Singleton, @Startup) inside the aforementioned EJB jar that expects a property to be injected via @Inject @ConfigProperty - which does not work I debugged the startup process and detected that the property injection into the bean fails because the lookup into the hashmap will not be done with the EAR classloader, but with the jar's classloader, which is totally understandable. What I do not understand, however, is, why the resolution process which kicks in afterwards does no longer find my PropertyFileConfig implementation, which worked in the EAR classloader case. My temporary solution now is to put a META-INF/services/org.apache.deltaspike.core.spi.config.ConfigSourceProvider file into the EJB jar and reference a custom ConfigSourceProvider. This file is always picked up correctly (interestingly in both cases, the EAR classloader and the jar classloader). Shouldn't the ConfigResolver pick up my PropertyFileConfig implementation in both cases as well? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DELTASPIKE-648) @ConfigProperty in Wildfly 8.1 not working correctly
[ https://issues.apache.org/jira/browse/DELTASPIKE-648?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14302960#comment-14302960 ] Gerhard Petracek commented on DELTASPIKE-648: - @mark: i don't doubt what you wrote, however, we need a test for it. after your revert ConfigPropertyEARTest#testInjectConfig is failing with as7/wf8. - please create a test-ear with 2 web-apps which use different configs otherwise we depend on manual tests for it. in general: since classloading can be changed in some ee-servers, we will never get an approach which works in any case (without optional config). - we have to think about a ClassLoaderStrategy used e.g. by ClassUtils. @ConfigProperty in Wildfly 8.1 not working correctly Key: DELTASPIKE-648 URL: https://issues.apache.org/jira/browse/DELTASPIKE-648 Project: DeltaSpike Issue Type: Bug Components: Configuration Affects Versions: 1.0.0 Environment: Mac OS X 10.9, Java 1.7.45, Wildfly 8.1 Reporter: Sven Panko Assignee: Mark Struberg Priority: Minor Fix For: 1.0.1 Attachments: DELTASPIKE-648.patch I am not quite sure if my problem is related to the (already closed) DELTASPIKE-451, but it is quite similar in behavior: * I have an EAR file that packages a few EJB jars (these are NOT contained in the lib directory of the EAR) * the application.xml uses the default isolation mechanism, which means that all libs in /lib have access to all classes (although I don't think this is relevant in my case since my EJB jars are not located in /lib) * inside one of the EJB jars I put a property file that should be used ONLY by beans inside this jar file * I created an implementation of PropertyFileConfig and provided the path to this property file * during startup I can see that the property file is correctly detected and stored in the hashmap using the EAR classloader * I have a bean (@Singleton, @Startup) inside the aforementioned EJB jar that expects a property to be injected via @Inject @ConfigProperty - which does not work I debugged the startup process and detected that the property injection into the bean fails because the lookup into the hashmap will not be done with the EAR classloader, but with the jar's classloader, which is totally understandable. What I do not understand, however, is, why the resolution process which kicks in afterwards does no longer find my PropertyFileConfig implementation, which worked in the EAR classloader case. My temporary solution now is to put a META-INF/services/org.apache.deltaspike.core.spi.config.ConfigSourceProvider file into the EJB jar and reference a custom ConfigSourceProvider. This file is always picked up correctly (interestingly in both cases, the EAR classloader and the jar classloader). Shouldn't the ConfigResolver pick up my PropertyFileConfig implementation in both cases as well? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DELTASPIKE-648) @ConfigProperty in Wildfly 8.1 not working correctly
[ https://issues.apache.org/jira/browse/DELTASPIKE-648?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14302571#comment-14302571 ] Rafael Benevides commented on DELTASPIKE-648: - I tried the revert and obviously it broke the WildFly implementation. I'm not sure how we should deal with it or just leave it (as it only happens for EARs and they aren't fully supported anyway). @ConfigProperty in Wildfly 8.1 not working correctly Key: DELTASPIKE-648 URL: https://issues.apache.org/jira/browse/DELTASPIKE-648 Project: DeltaSpike Issue Type: Bug Components: Configuration Affects Versions: 1.0.0 Environment: Mac OS X 10.9, Java 1.7.45, Wildfly 8.1 Reporter: Sven Panko Assignee: Mark Struberg Priority: Minor Fix For: 1.0.1 Attachments: DELTASPIKE-648.patch I am not quite sure if my problem is related to the (already closed) DELTASPIKE-451, but it is quite similar in behavior: * I have an EAR file that packages a few EJB jars (these are NOT contained in the lib directory of the EAR) * the application.xml uses the default isolation mechanism, which means that all libs in /lib have access to all classes (although I don't think this is relevant in my case since my EJB jars are not located in /lib) * inside one of the EJB jars I put a property file that should be used ONLY by beans inside this jar file * I created an implementation of PropertyFileConfig and provided the path to this property file * during startup I can see that the property file is correctly detected and stored in the hashmap using the EAR classloader * I have a bean (@Singleton, @Startup) inside the aforementioned EJB jar that expects a property to be injected via @Inject @ConfigProperty - which does not work I debugged the startup process and detected that the property injection into the bean fails because the lookup into the hashmap will not be done with the EAR classloader, but with the jar's classloader, which is totally understandable. What I do not understand, however, is, why the resolution process which kicks in afterwards does no longer find my PropertyFileConfig implementation, which worked in the EAR classloader case. My temporary solution now is to put a META-INF/services/org.apache.deltaspike.core.spi.config.ConfigSourceProvider file into the EJB jar and reference a custom ConfigSourceProvider. This file is always picked up correctly (interestingly in both cases, the EAR classloader and the jar classloader). Shouldn't the ConfigResolver pick up my PropertyFileConfig implementation in both cases as well? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DELTASPIKE-648) @ConfigProperty in Wildfly 8.1 not working correctly
[ https://issues.apache.org/jira/browse/DELTASPIKE-648?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14301209#comment-14301209 ] Mark Struberg commented on DELTASPIKE-648: -- Raphael, I like to understand what the real issues have been. With using ConfigResolver.class.getClassLoader() we basically ditch the whole MapClassLoader,.. Thus you end up having exactly one config per server. Which is a bit narrow ;) @ConfigProperty in Wildfly 8.1 not working correctly Key: DELTASPIKE-648 URL: https://issues.apache.org/jira/browse/DELTASPIKE-648 Project: DeltaSpike Issue Type: Bug Components: Configuration Affects Versions: 1.0.0 Environment: Mac OS X 10.9, Java 1.7.45, Wildfly 8.1 Reporter: Sven Panko Assignee: Mark Struberg Priority: Minor Fix For: 1.0.1 Attachments: DELTASPIKE-648.patch I am not quite sure if my problem is related to the (already closed) DELTASPIKE-451, but it is quite similar in behavior: * I have an EAR file that packages a few EJB jars (these are NOT contained in the lib directory of the EAR) * the application.xml uses the default isolation mechanism, which means that all libs in /lib have access to all classes (although I don't think this is relevant in my case since my EJB jars are not located in /lib) * inside one of the EJB jars I put a property file that should be used ONLY by beans inside this jar file * I created an implementation of PropertyFileConfig and provided the path to this property file * during startup I can see that the property file is correctly detected and stored in the hashmap using the EAR classloader * I have a bean (@Singleton, @Startup) inside the aforementioned EJB jar that expects a property to be injected via @Inject @ConfigProperty - which does not work I debugged the startup process and detected that the property injection into the bean fails because the lookup into the hashmap will not be done with the EAR classloader, but with the jar's classloader, which is totally understandable. What I do not understand, however, is, why the resolution process which kicks in afterwards does no longer find my PropertyFileConfig implementation, which worked in the EAR classloader case. My temporary solution now is to put a META-INF/services/org.apache.deltaspike.core.spi.config.ConfigSourceProvider file into the EJB jar and reference a custom ConfigSourceProvider. This file is always picked up correctly (interestingly in both cases, the EAR classloader and the jar classloader). Shouldn't the ConfigResolver pick up my PropertyFileConfig implementation in both cases as well? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DELTASPIKE-648) @ConfigProperty in Wildfly 8.1 not working correctly
[ https://issues.apache.org/jira/browse/DELTASPIKE-648?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14054904#comment-14054904 ] Rafael Benevides commented on DELTASPIKE-648: - It needs more tests because it seems that the build tests fails with this approach. @ConfigProperty in Wildfly 8.1 not working correctly Key: DELTASPIKE-648 URL: https://issues.apache.org/jira/browse/DELTASPIKE-648 Project: DeltaSpike Issue Type: Bug Components: Configuration Affects Versions: 1.0.0 Environment: Mac OS X 10.9, Java 1.7.45, Wildfly 8.1 Reporter: Sven Panko Assignee: Rafael Benevides Priority: Minor Attachments: DELTASPIKE-648.patch I am not quite sure if my problem is related to the (already closed) DELTASPIKE-451, but it is quite similar in behavior: * I have an EAR file that packages a few EJB jars (these are NOT contained in the lib directory of the EAR) * the application.xml uses the default isolation mechanism, which means that all libs in /lib have access to all classes (although I don't think this is relevant in my case since my EJB jars are not located in /lib) * inside one of the EJB jars I put a property file that should be used ONLY by beans inside this jar file * I created an implementation of PropertyFileConfig and provided the path to this property file * during startup I can see that the property file is correctly detected and stored in the hashmap using the EAR classloader * I have a bean (@Singleton, @Startup) inside the aforementioned EJB jar that expects a property to be injected via @Inject @ConfigProperty - which does not work I debugged the startup process and detected that the property injection into the bean fails because the lookup into the hashmap will not be done with the EAR classloader, but with the jar's classloader, which is totally understandable. What I do not understand, however, is, why the resolution process which kicks in afterwards does no longer find my PropertyFileConfig implementation, which worked in the EAR classloader case. My temporary solution now is to put a META-INF/services/org.apache.deltaspike.core.spi.config.ConfigSourceProvider file into the EJB jar and reference a custom ConfigSourceProvider. This file is always picked up correctly (interestingly in both cases, the EAR classloader and the jar classloader). Shouldn't the ConfigResolver pick up my PropertyFileConfig implementation in both cases as well? -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (DELTASPIKE-648) @ConfigProperty in Wildfly 8.1 not working correctly
[ https://issues.apache.org/jira/browse/DELTASPIKE-648?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14055327#comment-14055327 ] Rafael Benevides commented on DELTASPIKE-648: - Tests added to check WAR and EAR utilisation... @ConfigProperty in Wildfly 8.1 not working correctly Key: DELTASPIKE-648 URL: https://issues.apache.org/jira/browse/DELTASPIKE-648 Project: DeltaSpike Issue Type: Bug Components: Configuration Affects Versions: 1.0.0 Environment: Mac OS X 10.9, Java 1.7.45, Wildfly 8.1 Reporter: Sven Panko Assignee: Rafael Benevides Priority: Minor Attachments: DELTASPIKE-648.patch I am not quite sure if my problem is related to the (already closed) DELTASPIKE-451, but it is quite similar in behavior: * I have an EAR file that packages a few EJB jars (these are NOT contained in the lib directory of the EAR) * the application.xml uses the default isolation mechanism, which means that all libs in /lib have access to all classes (although I don't think this is relevant in my case since my EJB jars are not located in /lib) * inside one of the EJB jars I put a property file that should be used ONLY by beans inside this jar file * I created an implementation of PropertyFileConfig and provided the path to this property file * during startup I can see that the property file is correctly detected and stored in the hashmap using the EAR classloader * I have a bean (@Singleton, @Startup) inside the aforementioned EJB jar that expects a property to be injected via @Inject @ConfigProperty - which does not work I debugged the startup process and detected that the property injection into the bean fails because the lookup into the hashmap will not be done with the EAR classloader, but with the jar's classloader, which is totally understandable. What I do not understand, however, is, why the resolution process which kicks in afterwards does no longer find my PropertyFileConfig implementation, which worked in the EAR classloader case. My temporary solution now is to put a META-INF/services/org.apache.deltaspike.core.spi.config.ConfigSourceProvider file into the EJB jar and reference a custom ConfigSourceProvider. This file is always picked up correctly (interestingly in both cases, the EAR classloader and the jar classloader). Shouldn't the ConfigResolver pick up my PropertyFileConfig implementation in both cases as well? -- This message was sent by Atlassian JIRA (v6.2#6252)
