date:20170509

Re: [weld-dev] Thread deadlock with osgi refresh

2017-05-09 Thread Martin Kouba

Well, when looking at Niclas's answer - it is true that Weld's 
ClassFileUtils holds 0xfd03aa50 and also waiting in another 
thread to release this lock. But the weld-worker-1 thread (which holds 
the lock) is in state WAITING (on object monitor) due to 
org.apache.felix.framework.Felix.acquireGlobalLock(Felix.java:5332) 
which calls m_bundleLock.wait().

Martin

Dne 9.5.2017 v 11:45 Alex Sviridov napsal(a):
> Hi Martin
>
> Thank you very much for your answer. Yes, I asked them. Please see
> https://groups.google.com/forum/#!topic/ops4j/msmgHq0B1l8
>
>
> Вторник, 9 мая 2017, 12:22 +03:00 от Martin Kouba :
>
> Hi Alex,
>
> I don't know much about Felix and OSGi but it seems the
> org.apache.felix.framework.Felix.acquireGlobalLock() is waiting to wake
> up and the thread holds lock on
> org.jboss.weld.util.bytecode.ClassFileUtils. Have you tried PAX CDI
> guys
> already?
>
> Martin
>
> Dne 9.5.2017 v 09:04 Alex Sviridov napsal(a):
> > Hi all
> >
> > 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
> >
> > |Bundle systemBundle = bundleContext.getBundle(0);
> > FrameworkWiring frameworkWiring =
> > systemBundle.adapt(FrameworkWiring.class);
> > frameworkWiring.refreshBundles(null);
> >
> > What I see in log of bundle B.
> >
> > |2017-05-08 12:31:42,831 | DEBUG | xFrameworkWiring | ? |
> BundleEvent STOPPING - com.bundleB
> > 2017-05-08 12:31:42,832 | DEBUG | xFrameworkWiring | ? |
> ServiceEvent UNREGISTERING - [java.lang.Object] - com.bundleB
> > 2017-05-08 12:31:42,832 | DEBUG | xFrameworkWiring | ? |
> BundleEvent STOPPED - com.bundleB
> > 2017-05-08 12:31:42,845 | DEBUG | xFrameworkWiring | ? |
> BundleEvent UNRESOLVED - com.bundleB
> > 2017-05-08 12:31:42,885 | DEBUG | xFrameworkWiring | ? |
> BundleEvent RESOLVED - com.bundleB
> > 2017-05-08 12:31:42,886 | DEBUG | xFrameworkWiring | ? |
> BundleEvent STARTING - com.bundleB
> > 2017-05-08 12:31:43,164 | DEBUG | xFrameworkWiring | ? |
> ServiceEvent REGISTERED - [java.lang.Object] - com.bundleB
> > |
> > Please,note that bundleB didn't change state to STARTED. When I don't
> > use in bundleB CDI
> > beans and CDI container is not created for bundleB then everything
> is ok
> > - after bundleA
> > update and osgi refresh bundleB reaches STARTED state.
> >
> > Is this a bug of weld or something else? This is some thread dump:
> >
> > "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(ThreadPoolExecutor.java:617)
> > at java.lang.Thread.run(Thread.java:745)
> >
> > "weld-worker-1" #144 daemon prio=5 os_prio=0 tid=0x7f3e08042800
> > nid=0x1dc6 in Object.wait() [0x7f3dd967e000]
> > java.lang.Thread.State: WAITING (on object monitor)
> > at java.lang.Object.wait(Native Method)
> > at java.lang.Object.wait(Object.java:502)
> > at org.apache.felix.framework.Felix.acquireGlobalLock(Felix.java:5332)
> > - locked <0xed6de970> (a [Ljava.lang.Object;)
> > at

Re: [weld-dev] Thread deadlock with osgi refresh

2017-05-09 Thread Alex Sviridov

Hi Martin

Thank you very much for your answer. Yes, I asked them. Please see 
https://groups.google.com/forum/#!topic/ops4j/msmgHq0B1l8


>Вторник,  9 мая 2017, 12:22 +03:00 от Martin Kouba :
>
>Hi Alex,
>
>I don't know much about Felix and OSGi but it seems the 
>org.apache.felix.framework.Felix.acquireGlobalLock() is waiting to wake 
>up and the thread holds lock on 
>org.jboss.weld.util.bytecode.ClassFileUtils. Have you tried PAX CDI guys 
>already?
>
>Martin
>
>Dne 9.5.2017 v 09:04 Alex Sviridov napsal(a):
>> Hi all
>>
>> 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
>>
>> |Bundle systemBundle = bundleContext.getBundle(0);
>> FrameworkWiring frameworkWiring =
>> systemBundle.adapt(FrameworkWiring.class);
>> frameworkWiring.refreshBundles(null);
>>
>> What I see in log of bundle B.
>>
>> |2017-05-08 12:31:42,831 | DEBUG | xFrameworkWiring | ? | BundleEvent 
>> STOPPING - com.bundleB
>> 2017-05-08 12:31:42,832 | DEBUG | xFrameworkWiring | ? | ServiceEvent 
>> UNREGISTERING - [java.lang.Object] - com.bundleB
>> 2017-05-08 12:31:42,832 | DEBUG | xFrameworkWiring | ? | BundleEvent STOPPED 
>> - com.bundleB
>> 2017-05-08 12:31:42,845 | DEBUG | xFrameworkWiring | ? | BundleEvent 
>> UNRESOLVED - com.bundleB
>> 2017-05-08 12:31:42,885 | DEBUG | xFrameworkWiring | ? | BundleEvent 
>> RESOLVED - com.bundleB
>> 2017-05-08 12:31:42,886 | DEBUG | xFrameworkWiring | ? | BundleEvent 
>> STARTING - com.bundleB
>> 2017-05-08 12:31:43,164 | DEBUG | xFrameworkWiring | ? | ServiceEvent 
>> REGISTERED - [java.lang.Object] - com.bundleB
>> |
>> Please,note that bundleB didn't change state to STARTED. When I don't
>> use in bundleB CDI
>> beans and CDI container is not created for bundleB then everything is ok
>> - after bundleA
>> update and osgi refresh bundleB reaches STARTED state.
>>
>> Is this a bug of weld or something else? This is some thread dump:
>>
>> "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(ThreadPoolExecutor.java:617)
>> at java.lang.Thread.run(Thread.java:745)
>>
>> "weld-worker-1" #144 daemon prio=5 os_prio=0 tid=0x7f3e08042800
>> nid=0x1dc6 in Object.wait() [0x7f3dd967e000]
>> java.lang.Thread.State: WAITING (on object monitor)
>> at java.lang.Object.wait(Native Method)
>> at java.lang.Object.wait(Object.java:502)
>> at org.apache.felix.framework.Felix.acquireGlobalLock(Felix.java:5332)
>> - locked <0xed6de970> (a [Ljava.lang.Object;)
>> at
>> org.apache.felix.framework.StatefulResolver.resolve(StatefulResolver.java:481)
>> at
>> org.apache.felix.framework.BundleWiringImpl.searchDynamicImports(BundleWiringImpl.java:1652)
>> at
>> org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1552)
>> at
>> org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:79)
>> at
>> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:2018)
>> at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
>> at org.apache.felix.framework.Felix.loadBundleClass(Felix.java:1925)
>> at org.apache.felix.framework.BundleImpl.loadClass(BundleImpl.java:978)
>> at
>> org.apache.xbean.osgi.bundle.util.DelegatingBundle.loadClass(DelegatingBundle.java:170)
>> at
>> org.apache.xbean.osgi.bundle.util.BundleClassLoader.loadClass(BundleClassLoader.java:75)
>> at

Re: [weld-dev] Thread deadlock with osgi refresh

2017-05-09 Thread Martin Kouba

Hi Alex,

I don't know much about Felix and OSGi but it seems the 
org.apache.felix.framework.Felix.acquireGlobalLock() is waiting to wake 
up and the thread holds lock on 
org.jboss.weld.util.bytecode.ClassFileUtils. Have you tried PAX CDI guys 
already?

Martin

Dne 9.5.2017 v 09:04 Alex Sviridov napsal(a):
> Hi all
>
> 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
>
> |Bundle systemBundle = bundleContext.getBundle(0);
> FrameworkWiring frameworkWiring =
> systemBundle.adapt(FrameworkWiring.class);
> frameworkWiring.refreshBundles(null);
>
> What I see in log of bundle B.
>
> |2017-05-08 12:31:42,831 | DEBUG | xFrameworkWiring | ? | BundleEvent 
> STOPPING - com.bundleB
> 2017-05-08 12:31:42,832 | DEBUG | xFrameworkWiring | ? | ServiceEvent 
> UNREGISTERING - [java.lang.Object] - com.bundleB
> 2017-05-08 12:31:42,832 | DEBUG | xFrameworkWiring | ? | BundleEvent STOPPED 
> - com.bundleB
> 2017-05-08 12:31:42,845 | DEBUG | xFrameworkWiring | ? | BundleEvent 
> UNRESOLVED - com.bundleB
> 2017-05-08 12:31:42,885 | DEBUG | xFrameworkWiring | ? | BundleEvent RESOLVED 
> - com.bundleB
> 2017-05-08 12:31:42,886 | DEBUG | xFrameworkWiring | ? | BundleEvent STARTING 
> - com.bundleB
> 2017-05-08 12:31:43,164 | DEBUG | xFrameworkWiring | ? | ServiceEvent 
> REGISTERED - [java.lang.Object] - com.bundleB
> |
> Please,note that bundleB didn't change state to STARTED. When I don't
> use in bundleB CDI
> beans and CDI container is not created for bundleB then everything is ok
> - after bundleA
> update and osgi refresh bundleB reaches STARTED state.
>
> Is this a bug of weld or something else? This is some thread dump:
>
> "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(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
>
> "weld-worker-1" #144 daemon prio=5 os_prio=0 tid=0x7f3e08042800
> nid=0x1dc6 in Object.wait() [0x7f3dd967e000]
> java.lang.Thread.State: WAITING (on object monitor)
> at java.lang.Object.wait(Native Method)
> at java.lang.Object.wait(Object.java:502)
> at org.apache.felix.framework.Felix.acquireGlobalLock(Felix.java:5332)
> - locked <0xed6de970> (a [Ljava.lang.Object;)
> at
> org.apache.felix.framework.StatefulResolver.resolve(StatefulResolver.java:481)
> at
> org.apache.felix.framework.BundleWiringImpl.searchDynamicImports(BundleWiringImpl.java:1652)
> at
> org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1552)
> at
> org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:79)
> at
> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:2018)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
> at org.apache.felix.framework.Felix.loadBundleClass(Felix.java:1925)
> at org.apache.felix.framework.BundleImpl.loadClass(BundleImpl.java:978)
> at
> org.apache.xbean.osgi.bundle.util.DelegatingBundle.loadClass(DelegatingBundle.java:170)
> at
> org.apache.xbean.osgi.bundle.util.BundleClassLoader.loadClass(BundleClassLoader.java:75)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:411)
> - locked <0xfb14e428> (a
> org.ops4j.pax.cdi.weld.impl.util.BundleClassLoader)
> at
> org.ops4j.pax.cdi.weld.impl.util.BundleClassLoader.loadClass(BundleClassLoader.java:193)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
> at java.lang.ClassLoader.defineClass1(Native Method)
> at

[weld-dev] Thread deadlock with osgi refresh

2017-05-09 Thread Alex Sviridov

Hi all

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
Bundle systemBundle = bundleContext.getBundle(0);
FrameworkWiring frameworkWiring = systemBundle.adapt(FrameworkWiring.class); 
frameworkWiring.refreshBundles(null);

What I see in log of bundle B.

2017-05-08 12:31:42,831 | DEBUG | xFrameworkWiring | ? | BundleEvent STOPPING - 
com.bundleB
2017-05-08 12:31:42,832 | DEBUG | xFrameworkWiring | ? | ServiceEvent 
UNREGISTERING - [java.lang.Object] - com.bundleB
2017-05-08 12:31:42,832 | DEBUG | xFrameworkWiring | ? | BundleEvent STOPPED - 
com.bundleB
2017-05-08 12:31:42,845 | DEBUG | xFrameworkWiring | ? | BundleEvent UNRESOLVED 
- com.bundleB
2017-05-08 12:31:42,885 | DEBUG | xFrameworkWiring | ? | BundleEvent RESOLVED - 
com.bundleB
2017-05-08 12:31:42,886 | DEBUG | xFrameworkWiring | ? | BundleEvent STARTING - 
com.bundleB
2017-05-08 12:31:43,164 | DEBUG | xFrameworkWiring | ? | ServiceEvent 
REGISTERED - [java.lang.Object] - com.bundleB

Please,note that bundleB didn't change state to STARTED. When I don't use in 
bundleB CDI
beans and CDI container is not created for bundleB then everything is ok - 
after bundleA
update and osgi refresh bundleB reaches STARTED state.

Is this a bug of weld or something else? This is some thread dump:

"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(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)

"weld-worker-1" #144 daemon prio=5 os_prio=0 tid=0x7f3e08042800 nid=0x1dc6 
in Object.wait() [0x7f3dd967e000]
   java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
at java.lang.Object.wait(Object.java:502)
at org.apache.felix.framework.Felix.acquireGlobalLock(Felix.java:5332)
- locked <0xed6de970> (a [Ljava.lang.Object;)
at 
org.apache.felix.framework.StatefulResolver.resolve(StatefulResolver.java:481)
at 
org.apache.felix.framework.BundleWiringImpl.searchDynamicImports(BundleWiringImpl.java:1652)
at 
org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1552)
at 
org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:79)
at 
org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:2018)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
at org.apache.felix.framework.Felix.loadBundleClass(Felix.java:1925)
at org.apache.felix.framework.BundleImpl.loadClass(BundleImpl.java:978)
at 
org.apache.xbean.osgi.bundle.util.DelegatingBundle.loadClass(DelegatingBundle.java:170)
at 
org.apache.xbean.osgi.bundle.util.BundleClassLoader.loadClass(BundleClassLoader.java:75)
at java.lang.ClassLoader.loadClass(ClassLoader.java:411)
- locked <0xfb14e428> (a 
org.ops4j.pax.cdi.weld.impl.util.BundleClassLoader)
at 
org.ops4j.pax.cdi.weld.impl.util.BundleClassLoader.loadClass(BundleClassLoader.java:193)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:760)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at

Re: [weld-dev] Thread deadlock with osgi refresh

Re: [weld-dev] Thread deadlock with osgi refresh

Re: [weld-dev] Thread deadlock with osgi refresh

[weld-dev] Thread deadlock with osgi refresh

4 matches

Site Navigation

Mail list logo

Footer information