I've been running in to this issue for a few weeks now and the prior claim was that this was a class loading issue; but this describes what I'm seeing better I think.  At least with what I'm seeing, you cannot guarantee anything about the objects found in the bean manager or even the bean manager itself in this state. 

I know at least for our (JMS) use case, we have to do our work in ABD since we need to create new ObserverMethod's that can handle the event firing receipt.  So I guess the limitation is that it can't be a bean?  I'm not sure how the computing hash map helps us in this case, or maybe its just a general idea?

John

On Mon, Feb 14, 2011 at 6:42 AM, Pete Muir <pmuir@redhat.com> wrote:
Right, there are no events in which beans are guaranteed to be available for lookup or instantiation, so doing it lazily is best.

On 13 Feb 2011, at 05:15, Stuart Douglas wrote:

>
> On 13/02/2011, at 2:57 PM, Jason Porter wrote:
>
>> On Saturday, February 12, 2011, Stuart Douglas
>> <stuart.w.douglas@gmail.com> wrote:
>>> The spec does not actually guarantee that the beans will be available in the AfterBeanDiscovery event.
>>
>> Wouldn't AfterValidation work?
>
> Possibly, however I don't think it is required to work by the spec, so it may not be portable.
>
> Stuart
>
>>
>>> As it is possible to add beans/interceptors/decorators in this event CDI is not fully initialised yet, so even if this does sort of work some times it is certainly not portable. Have you considered using a ComputingHashMap to create the map in a lazy manner?
>>> Stuart
>>>
>>>
>>> On 13/02/2011, at 6:44 AM, Jordan Ganoff wrote:
>>> All,
>>> I've run into an issue that I haven't been able to resolve. I am collecting producers during ProcessProducer and I'd like to be able to invoke them during AfterBeanDiscovery to operate on the produces objects. When I run the application with Arquillian the beans can be looked up successfully. When the application runs as a web app they are not.
>>>
>>>
>>>
>>> The sample app is producer-test on this branch of seam-jms: https://github.com/jganoff/jms/tree/producer-test/producer-test
>>>
>>> The relevant code is here: https://github.com/jganoff/jms/blob/producer-test/producer-test/src/main/java/org/jboss/seam/jms/producertest/TestExtension.java
>>>
>>>
>>>
>>> Anyone have any ideas?
>>> Follow up question: Is this a decent way for users to configure JMS routing information (send CDI event X to JMS destination Y, etc)? The original idea was to allow users to annotate methods with  @RoutingConfig and what they returned would be registered as a route. The producer idea seemed like a better fit though.
>>>
>>>
>>> --
>>> Jordan Ganoff
>>>
>>> _______________________________________________
>>> seam-dev mailing list
>>> seam-dev@lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/seam-dev
>>>
>>>
>>
>> --
>> Jason Porter
>> http://lightguard-jp.blogspot.com
>> http://twitter.com/lightguardjp
>>
>> Software Engineer
>> Open Source Advocate
>>
>> PGP key id: 926CCFF5
>> PGP key available at: keyserver.net, pgp.mit.edu
>
>
> _______________________________________________
> seam-dev mailing list
> seam-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/seam-dev


_______________________________________________
seam-dev mailing list
seam-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/seam-dev