[weld-issues] [JBoss JIRA] (WELD-2381) Set web application classloader as TCCL when calling observers
Title: Message Title Emily Jiang commented on WELD-2381 Re: Set web application classloader as TCCL when calling observers Instead of arguing the unclear spec, let's focus on solving the real issue, using DeltaSpike config in the war module's extension. Mark, which method do you invoke the DeltaSpike method via passing the thread context classloader, hence the test app Martin is after. Shall we all work together to see whether we can come up with a workaround? Add Comment This message was sent by Atlassian JIRA (v7.2.3#72005-sha1:73be91d) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2383) Thread dead lock with osgi refresh
Title: Message Title Martin Kouba edited a comment on WELD-2383 Re: Thread dead lock with osgi refresh http://lists.jboss.org/pipermail/weld-dev/2017-May/003526.html https://groups.google.com/forum/#!topic/ops4j/msmgHq0B1l8 Add Comment This message was sent by Atlassian JIRA (v7.2.3#72005-sha1:73be91d) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2381) Set web application classloader as TCCL when calling observers
Title: Message Title Matej Novotny commented on WELD-2381 Re: Set web application classloader as TCCL when calling observers Mark Struberg so you refer to: (Quoting from spec) This specification requires that containers provide a per thread context class loader that can be used to load top level application classes as described above. I still fail to where how this supports your sentence that: The TCCL MUST be set up for all application method invocations! Add Comment This message was sent by Atlassian JIRA (v7.2.3#72005-sha1:73be91d) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2381) Set web application classloader as TCCL when calling observers
Title: Message Title Mark Struberg commented on WELD-2381 Re: Set web application classloader as TCCL when calling observers Matej Novotny EE.6.2.3.7 Context Class Loader Add Comment This message was sent by Atlassian JIRA (v7.2.3#72005-sha1:73be91d) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2381) Set web application classloader as TCCL when calling observers
Title: Message Title Mark Struberg commented on WELD-2381 Re: Set web application classloader as TCCL when calling observers Martin Kouba An application can rely (as per the EE umbrella spec) that a TCCL is set. But I agree with you that it's not in the CDI container responsibility to provide this setup. I don't know how the CDI could even do that because it does most likely not even have the necessary information. This setup has to be done by the EE container. Add Comment This message was sent by Atlassian JIRA (v7.2.3#72005-sha1:73be91d) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2383) Thread dead lock with osgi refresh
Title: Message Title Martin Kouba commented on WELD-2383 Re: Thread dead lock with osgi refresh http://lists.jboss.org/pipermail/weld-dev/2017-May/003526.html Add Comment This message was sent by Atlassian JIRA (v7.2.3#72005-sha1:73be91d) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2381) Set web application classloader as TCCL when calling observers
Title: Message Title Martin Kouba commented on WELD-2381 Re: Set web application classloader as TCCL when calling observers Mark Struberg I do not question that it must be set. But it should be only used to load the top level application classes. There is not a single word about its identity or any other characteristics (correct me if I'm wrong). Please read the relevant comments above. Add Comment This message was sent by Atlassian JIRA (v7.2.3#72005-sha1:73be91d) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2381) Set web application classloader as TCCL when calling observers
Title: Message Title Matej Novotny commented on WELD-2381 Re: Set web application classloader as TCCL when calling observers Martin, this is actutally PERFECTLY well defined in the EE spec. The TCCL MUST be set up for all application method invocations! Please support your claim by exact EE spec quotation. Add Comment This message was sent by Atlassian JIRA (v7.2.3#72005-sha1:73be91d) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2381) Set web application classloader as TCCL when calling observers
Title: Message Title Mark Struberg commented on WELD-2381 Re: Set web application classloader as TCCL when calling observers Martin, this is actutally PERFECTLY well defined in the EE spec. The TCCL MUST be set up for all application method invocations! It's just that it's not part of CDI but the EE umbrella spec. > Mark, I have no idea what you're talking about. Section B in https://struberg.wordpress.com/2015/02/18/cdi-in-ears/ This is how WebSphere8 and Tomee-1.x was set up and this works rather well for EARs. At least better than treating all the EAR as one big ball of mud... Add Comment This message was sent by Atlassian JIRA (v7.2.3#72005-sha1:73be91d) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2381) Set web application classloader as TCCL when calling observers
Title: Message Title Martin Kouba commented on WELD-2381 Re: Set web application classloader as TCCL when calling observers Benjamin Confino Emily Jiang We're not going to introduce a hack based on the proposed solution to support a DS feature which is NOT relying on a portable feature covered by the spec. If you think we're wrong, please cite the relevant passages of the EE spec. See also my comment above: https://issues.jboss.org/browse/WELD-2381?focusedCommentId=13398074&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13398074 Also we will not continue to work on this issue unless a reproducer EAR app showing the actual problem is delivered. You might probably need to swap out the Bean for @ApplicationScoped to properly support equals across different BeanManagers. Mark Struberg Mark, I have no idea what you're talking about. Add Comment This message was sent by Atlassian JIRA (v7.2.3#72005-sha1:73be91d) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2383) Thread dead lock with osgi refresh
Title: Message Title
Pasha Turok updated an issue
Weld / WELD-2383
Thread dead lock with osgi refresh
Change By:
Pasha Turok
I use pax-cdi 1.0.0.RC2 with weld-osgi-bundle 2.3.5. And I have two bundles: bundleA and bundleB.BundleB has CDI beans and CDI container is created for bundleB. Besides bundleB depends on bundleA.Now I update bundleA and do osgi refresh using this code{code:java}Bundle systemBundle = bundleContext.getBundle(0);FrameworkWiring frameworkWiring = systemBundle.adapt(FrameworkWiring.class); frameworkWiring.refreshBundles(null);{code}What I see in log of bundle B.{code:java}2017-05-08 12:31:42,831 | DEBUG | xFrameworkWiring | ? | BundleEvent STOPPING - com.bundleB2017-05-08 12:31:42,832 | DEBUG | xFrameworkWiring | ? | ServiceEvent UNREGISTERING - [java.lang.Object] - com.bundleB2017-05-08 12:31:42,832 | DEBUG | xFrameworkWiring | ? | BundleEvent STOPPED - com.bundleB2017-05-08 12:31:42,845 | DEBUG | xFrameworkWiring | ? | BundleEvent UNRESOLVED - com.bundleB2017-05-08 12:31:42,885 | DEBUG | xFrameworkWiring | ? | BundleEvent RESOLVED - com.bundleB2017-05-08 12:31:42,886 | DEBUG | xFrameworkWiring | ? | BundleEvent STARTING - com.bundleB2017-05-08 12:31:43,164 | DEBUG | xFrameworkWiring | ? | ServiceEvent REGISTERED - [java.lang.Object] - com.bundleB{code}Please,note that bundleB didn't change state to STARTED. When I don't use in bundleB CDIbeans and CDI container is not created for bundleB then everything is ok - after bundleAupdate and osgi refresh bundleB reaches STARTED state. Is this a bug or maybe I do something wrong or something else? This is some thread dump : , notice two locks of <0xfd03aa50> {code:java}"weld-worker-3" #146 daemon prio=5 os_prio=0 tid=0x7f3e08044000 nid=0x1dc8 waiting for monitor entry [0x7f3dd867a000] java.lang.Thread.State: BLOCKED (on object monitor) at org.jboss.weld.util.bytecode.ClassFileUtils.toClass2(ClassFileUtils.java:108) - waiting to lock <0xfd03aa50> (a java.lang.Class for org.jboss.weld.util.bytecode.ClassFileUtils) at org.jboss.weld.util.bytecode.ClassFileUtils.toClass(ClassFileUtils.java:97) at org.jboss.weld.bean.proxy.ProxyFactory.createProxyClass(ProxyFactory.java:491) at org.jboss.weld.bean.proxy.ProxyFactory.getProxyClass(ProxyFactory.java:364) at org.jboss.weld.bean.builtin.AbstractFacadeBean.initializeAfterBeanDiscovery(AbstractFacadeBean.java:61) at org.jboss.weld.bootstrap.ConcurrentBeanDeployer$AfterBeanDiscoveryInitializerFactory.doWork(ConcurrentBeanDeployer.java:136) at org.jboss.weld.bootstrap.ConcurrentBeanDeployer$AfterBeanDiscoveryInitializerFactory.doWork(ConcurrentBeanDeployer.java:127) at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:63) at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:56) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExec
