dev@glassfish.java.net

Re: CDI BeanManager.addBean() question

From: Lee Chuk Munn <chuk-munn.lee_at_oracle.com>
Date: Sat, 25 Jun 2011 09:53:38 +0800

Siva

just notice that I've not answered your question in my previous email.
The JARs in glassfish/modules are 'platform' classes, to be used by the
container.

Anyway as per my previous email, I've updated the Weld version and seems
to work now. I'll go check out the specs.

Regards
Chuk

On 24/06/11 23:56, Sivakumar Thyagarajan wrote:
> Hi Chuk
>
> On Wednesday 22 June 2011 02:42 PM, Lee Chuk Munn wrote:
>> Hi
>>
>> I have a class org.xmpp.packet.Message that is *NOT* bundled as part of
>> my deployment WAR. The Message class is installed on the platform viz.
>> the JAR that contains the class is in glassfish/modules directory.
>>
>> In my CDI portable extension, I'm creating a bean
>>
>> public class MessageBean implements Bean<Message> {
>>
>> and I'm registering this in the AfterBeanDiscovery phase. I can't seem
>> to register or enable this bean. There are no exceptions.
>>
>> I have another bean
>>
>> public class ThreadIDBean implements Bean<ThreadID> {
>>
>> and ThreadID is part of the deployment WAR. This bean is register and
>> enabled by the BeanManager.
>>
>> Is there a restriction on the registration of the beans?
>
> Is the packet.Message Bean visible to the Extension? Placing the library
> jar in glassfish/modules would not make it available to applications. Is
> there a reason why the library is placed in glassfish/modules directory
> rather than using bundled libraries (Section EE.8.2 of EE6 platform spec.)?
>
> Thanks
> --Siva.
>
>>
>> Any pointers appreciated.
>>
>> Thanks
>>
>> Regards
>> Chuk
>

-- 
The goal of computation is the emulation of our synthetic abilities, not
the understanding of our analytic ones.