Pete,<br><br>So I've been working on the approach you discussed on IRC. The code changes do not work correctly when I look at the bean manager in ProcessObserverMethod - it looks like this event gets called prior to ABD, so my observer methods do not exist. However, it does look like it works correctly when I process the bean manager that comes in during AfterDeploymentValidation. I have to run a lot more testing, but it does appear to work when I lazily create the beans. So, thanks for tips.<br>
<br>John<br><br><div class="gmail_quote">On Fri, Feb 18, 2011 at 6:19 AM, Pete Muir <span dir="ltr"><<a href="mailto:pmuir@redhat.com" target="_blank">pmuir@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div><br>
On 18 Feb 2011, at 00:28, John Ament wrote:<br>
<br>
> For an overview of the original proposal, please review<br>
> <a href="https://issues.jboss.org/browse/SEAMJMS-3" target="_blank">https://issues.jboss.org/browse/SEAMJMS-3</a><br>
> <a href="https://issues.jboss.org/browse/SEAMJMS-4" target="_blank">https://issues.jboss.org/browse/SEAMJMS-4</a><br>
><br>
> Why are we doing this?<br>
><br>
> The issue raised recently on the list is that during AfterBeanDiscovery, there is no guarantee that beans are available. This conflicts with the Egress side of the feature where the full observer method must be created during ABD. As a result, we cannot guarantee that looking up beans will work (in fact, we can typically guarantee it won't work). Therefor, we can not support generic qualifiers on the destinations that are involved in the mapping, the extension needs to be able to resolve the destination manually.<br>
<br>
</div>John can you explain in more detail why you need to look up beans here?<br>
<br>
This restriction has generally not been a problem for implementing such extensions, so I'm curious why it is here.</blockquote></div><br>