[weld-dev] Issue with weld 2.1.0.Final on OSGI

Charles Moulliard cmoulliard at redhat.com
Tue Nov 19 02:35:22 EST 2013


Hi Jason,

Many thanks for your help last Thursday at Devoxx. I have done Friday 
the modifications that we discussed together but I finally get another 
problem ( Weld-001333: BeanManager method getBeans is not available 
after shutdown). As the code of camel-cdi is complex and must be 
re-factored, I will take the time this week or next week (with help of 
Antoine) to develop a new CDI extension

Regards,

Charles



On 19/11/13 01:39, Jason Porter wrote:
> Any luck with this Charles?
>
> For others: We spent some time hacking and debugging this at Devoxx, but were not able to implement the solution before we had to part ways.
>
> ----- Original Message -----
>> From: "Jozef Hartinger" <jharting at redhat.com>
>> To: "Charles Moulliard" <cmoulliard at redhat.com>
>> Cc: weld-dev at lists.jboss.org, "Antoine Sabot-Durand" <asabotdu at redhat.com>, "Jason Porter" <jporter at redhat.com>,
>> "Peter Muir" <pmuir at redhat.com>
>> Sent: Monday, November 11, 2013 1:01:04 AM
>> Subject: Re: [weld-dev] Issue with weld 2.1.0.Final on OSGI
>>
>> Hi Charles,
>>
>> Weld uses Pax CDI provided BundleResourceLoader[1] to load classes in an
>> OSGi bundle. It loads only those that are discovered by BeanScanner[2].
>>
>> When you call getBeans() Weld does not load the parameter class anyhow
>> since you already provided a loaded class. Weld will try to match the
>> type you pass to getBeans() with the types of beans it had loaded.
>>
>> Jozef
>>
>> [1]
>> https://github.com/ops4j/org.ops4j.pax.cdi/blob/master/pax-cdi-weld/src/main/java/org/ops4j/pax/cdi/weld/impl/bda/BundleResourceLoader.java
>> [2]
>> https://github.com/ops4j/org.ops4j.pax.cdi/blob/master/pax-cdi-spi/src/main/java/org/ops4j/pax/cdi/spi/scan/BeanScanner.java
>>
>> On 11/08/2013 07:11 PM, Charles Moulliard wrote:
>>> Hi,
>>>
>>> The following code which is working fine and returns a bean when we run
>>> Junit Test with DeltaSpike does not work when Weld 2.1.0.Final is
>>> deployed on Karaf (OSGI v4.3) with Pax-CDI. Apparently the bean is not
>>> retrieved when we call "beanManager.getBeans("
>>>
>>>
>>>        protected CamelContext getCamelContext(String context, BeanManager
>>> beanManager) {
>>>            if (camelContextMap == null) {
>>>                Set<Bean<?>> beans =
>>> beanManager.getBeans(CamelContextMap.class, new AnyLiteral()); // return
>>> null
>>>                Bean<?> bean = beanManager.resolve(beans); // return null
>>>                CreationalContext<?> creationalContext =
>>> beanManager.createCreationalContext(bean);
>>>                camelContextMap = (CamelContextMap)
>>> beanManager.getReference(bean, bean.getBeanClass(), creationalContext);
>>>                ObjectHelper.notNull(camelContextMap, "Could not resolve
>>> CamelContextMap");
>>>            }
>>>            return camelContextMap.getCamelContext(context);
>>>        }
>>>
>>> Question : How does WeldContainer loads the class when we use getBeans
>>> as I suspect that we have a problem with the classloader used ?
>>>
>>> Regards,
>>>
>>> Charles
>>> _______________________________________________
>>> weld-dev mailing list
>>> weld-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/weld-dev
>>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/weld-dev/attachments/20131119/9ce566cc/attachment.html 


More information about the weld-dev mailing list