<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Thu, Feb 16, 2017 at 10:08 PM Matej Novotny &lt;<a href="mailto:manovotn@redhat.com">manovotn@redhat.com</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">&gt; Concretely, I&#39;d like to do this:<br class="gmail_msg">
&gt;<br class="gmail_msg">
&gt; // In my portable extension<br class="gmail_msg">
&gt; private static final void doSomethingAtStartup(@Observes<br class="gmail_msg">
&gt; @Initialized(ApplicationScoped.class) final Object event, final Frobnicator<br class="gmail_msg">
&gt; someBean) {<br class="gmail_msg">
&gt; someBean.doSomething();<br class="gmail_msg">
&gt; }<br class="gmail_msg">
<br class="gmail_msg">
While you cannot do this, you can still get hold of BeanManager and use it to resolve your bean.<br class="gmail_msg"></blockquote><div><br></div><div>Right; that&#39;s what I&#39;m doing at the moment.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
But I would say this could create quite some confusion if in some observer you could inject certain beans and in others you couldn&#39;t.<br class="gmail_msg"></blockquote><div><br></div><div>Sure.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Even in your sample, you can only inject AppScoped beans, so imagine you do such observer for, say, SessionScoped, what can you inject there?<br class="gmail_msg">
SessionScoped for sure, how about Req? Conversation?<br class="gmail_msg"></blockquote><div><br></div><div>First, thanks to Martin, Antoine, yourself, etc. for looking at this.  The issue is not holding me up, and I can make headway, etc.  My remarks here are just because I&#39;m curious.  :-)</div><div><br></div><div>Forgetting about confusion, couldn&#39;t I inject any bean I want in a non-container-lifecycle-event-observing observer method in my extension?  I understand it&#39;s not supported right now, and I also understand Antoine&#39;s excellent point that observing a payload of type Object would, in a portable extension, be too &quot;broad&quot;.  Let&#39;s forget about that for a moment, and pretend that it&#39;s not an issue, and just focus on resolution issues.</div><div><br></div><div>Surely this:</div><div><br></div><div><span style="color:rgb(33,33,33);font-size:13px">void MyObserver(@Observes Object payload, SomeBean bean) { ... }</span></div><div><span style="color:rgb(33,33,33);font-size:13px"><br></span></div><div><span style="color:rgb(33,33,33);font-size:13px">...would work (again, forgetting about the fact that due to resolution rules this would also be called for lifecycle events; I&#39;m interested purely in resolution issues of that SomeBean parameter)?  </span></div><div><span style="color:rgb(33,33,33);font-size:13px"><br></span></div><div><span style="color:rgb(33,33,33);font-size:13px">My point is, a portable extension &quot;becomes&quot; a bean (in application scope, according to the specification), and so therefore is eligible to use other beans, no matter what scope they&#39;re in, some of whose Contexts might be active, and some of whose might not be active.  Obviously trying to use a bean before the container has gotten through AfterDeploymentValidation won&#39;t work, but after that point...?</span></div><div><span style="color:rgb(33,33,33);font-size:13px"><br></span></div><div><font color="#212121">Like I said, now I&#39;m just curious.  :-)</font></div><div><font color="#212121"><br></font></div><div><font color="#212121">Best,</font></div><div><font color="#212121">Laird</font></div></div></div>