[weld-issues] [JBoss JIRA] (WELD-1437) Weld can't coexist with another CDI container in a large multi-module project.
Jozef Hartinger updated WELD-1437 Weld cant coexist with another CDI container in a large multi-module project. Change By: Jozef Hartinger (22/Nov/13 9:08 AM) Status: PullRequestSent Resolved Resolution: Done This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-1437) Weld can't coexist with another CDI container in a large multi-module project.
Matus Abaffy updated WELD-1437 Weld cant coexist with another CDI container in a large multi-module project. Change By: Matus Abaffy (15/Nov/13 2:39 PM) Status: Open PullRequestSent Git Pull Request: https://github.com/weld/core/pull/411 This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-1437) Weld can't coexist with another CDI container in a large multi-module project.
Jozef Hartinger commented on WELD-1437 Weld cant coexist with another CDI container in a large multi-module project. The "weld-specific (portable) extension" bit is the problem here, as this notion effectively contradicts itself. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-1437) Weld can't coexist with another CDI container in a large multi-module project.
Martin Kouba commented on WELD-1437 Weld cant coexist with another CDI container in a large multi-module project. I don't say that extension is "portable". What I'm trying to express is that if you place impl-specific bits for the different CDI impls on the classpath you will face other similar problems (for instance if you place DeltaSpike Container Ctrl impls for Weld and OWB). This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-1437) Weld can't coexist with another CDI container in a large multi-module project.
Jozef Hartinger commented on WELD-1437 Weld cant coexist with another CDI container in a large multi-module project. Yes, what I was saying is that we should re-evaluate whether using extensions is the right way of registering Weld-specific beans, etc. Perhaps we could use a different way of achieving the same goal and fix this issue as a side-effect. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-1437) Weld can't coexist with another CDI container in a large multi-module project.
Matus Abaffy commented on WELD-1437 Weld cant coexist with another CDI container in a large multi-module project. I was able to reproduce this on weld-se. (However, using another CDI container within weld-se application does not make much sense to me.) 1) Does this problem occur even in the Java EE runtime environment? 2) And what is your module structure? This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-1437) Weld can't coexist with another CDI container in a large multi-module project.
Christian Schlichtherle commented on WELD-1437 Weld cant coexist with another CDI container in a large multi-module project. 1) I gave up after this test because it was a show-stopper. 2) About thirty different modules (https://truevfs.java.net ). Why does this matter? Well, modern day software should be composed of different modules/components/bean archives. In most cases, an application is a mix of components from different ISVs. Each of these ISVs may want to use a private CDI container to wire their components without any configuration required by the client which integrates all these components into the application. For example, I considered to use Weld in TrueVFS to make my life a bit simpler (I am currently doing DI manually). However, if Weld cannot peacefully coexist with other containers or even other instances of itself, e.g. when used by the client, then this scenario is prohibitive. As an implication, for now I will continue to do DI manually. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-1437) Weld can't coexist with another CDI container in a large multi-module project.
Martin Kouba commented on WELD-1437 Weld cant coexist with another CDI container in a large multi-module project. First CDI is a Java EE technology and relies on its module architecture. Also it does not define SE support at the moment (although both Weld and OWB do support SE in its own way) - this will be likely addressed in CDI 2, see also CDI-160. However even Java SE does not define any "module system" yet. In this scenario OWB finds org.jboss.weld.environment.se.WeldSEBeanRegistrant extension on the classpath and delivers AfterBeanDiscovery event. However this extension is weld-specific and expects Weld to be initialized (which is not). Weld could probably add some workaround for this specific issue but i don't think it would protect your system from the "classloading hell". Instead I would rely on some modular system for SE (JBoss Modules, OSGi, etc.) so that each module has its own isolated ClassLoader. Note that there's an effort to integrate CDI in OSGi environments - RFP 146, see also the reference implementation Pax CDI. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-1437) Weld can't coexist with another CDI container in a large multi-module project.
Martin Kouba commented on WELD-1437 Weld cant coexist with another CDI container in a large multi-module project. I don't think it's a completely separate concern. Again, in this scenario OWB registers/instantiates a Weld-specific CDI extension which expects Weld to be initialized (seems logical to me). Afterwards when OWB delivers AfterBeanDiscovery event the invocation of registerWeldSEContexts() method fails and this results in definition error per the spec. So Weld is not "listening" at all. There's just an extension component on the classpath and OWB picks it up (also seems logical to me). Unfortunately this component requires Weld container. So my assumption is: if a module with OWB has an isolated classloader, is wouldn't see Weld classes. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-1437) Weld can't coexist with another CDI container in a large multi-module project.
Christian Schlichtherle created WELD-1437 Weld cant coexist with another CDI container in a large multi-module project. Issue Type: Bug Affects Versions: 1.1.13.Final Assignee: Jozef Hartinger Created: 12/Jun/13 3:38 AM Description: Weld observes AfterBeanDiscovery events with @Default qualifier. However, if another CDI container is present, e.g. if another module is using OpenWebBeans to manage CDI solely for this component, then Weld will receive this event and throw an IllegalStateException: Exception in thread "main" java.lang.IllegalStateException: Singleton is not set at org.jboss.weld.bootstrap.api.helpers.IsolatedStaticSingletonProvider$IsolatedStaticSingleton.get(IsolatedStaticSingletonProvider.java:52) at org.jboss.weld.Container.instance(Container.java:54) at org.jboss.weld.context.AbstractContext.init(AbstractContext.java:67) at org.jboss.weld.context.AbstractManagedContext.init(AbstractManagedContext.java:11) at org.jboss.weld.context.AbstractUnboundContext.init(AbstractUnboundContext.java:31) at org.jboss.weld.environment.se.contexts.ThreadContext.init(ThreadContext.java:40) at org.jboss.weld.environment.se.WeldSEBeanRegistrant.registerWeldSEContexts(WeldSEBeanRegistrant.java:49) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.webbeans.event.ObserverMethodImpl.notify(ObserverMethodImpl.java:267) at org.apache.webbeans.event.NotificationManager.fireEvent(NotificationManager.java:474) at org.apache.webbeans.container.BeanManagerImpl.fireEvent(BeanManagerImpl.java:440) at org.apache.webbeans.container.BeanManagerImpl.fireEvent(BeanManagerImpl.java:430) at org.apache.webbeans.config.BeansDeployer.fireAfterBeanDiscoveryEvent(BeansDeployer.java:332) at org.apache.webbeans.config.BeansDeployer.deploy(BeansDeployer.java:192) at org.apache.webbeans.lifecycle.AbstractLifeCycle.startApplication(AbstractLifeCycle.java:129) at com.company.mavenproject1.boot.BootWebBeans.startApplication(BootWebBeans.java:41) at com.company.mavenproject1.boot.BootWebBeans.run(BootWebBeans.java:28) at com.company.mavenproject1.boot.BootWebBeans.main(BootWebBeans.java:23) I consider this being a major issue because it implies that it's impossible to develop components / modules / bean archives (whatever you call it) which use a private CDI container. As soon as Weld is present on the class path, e.g. to manage CDI for the client application, you will get this IllegalStateException. Project: Weld Priority: Major Reporter: Christian Schlichtherle This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
