<div dir="ltr">Hi,<br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Sep 13, 2016 at 4:37 PM, Antoine Sabot-Durand <span dir="ltr"><<a href="mailto:antoine@sabot-durand.net" target="_blank">antoine@sabot-durand.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small">I'd be more than happy to convince our friends of the Servlet spec to re-open this ticket. I'll talk with Ed next week.<br></div><div style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small">All the input you can give me to answer their objection are welcome.</div></div></blockquote><div><br></div><div>The most problematic objection IMHO was this one:</div><div><br></div><div><div>GW> More over,</div><div>GW> I'm concerned that by making CDI to servlet mapping a responsibility</div><div>GW> of the servlet container, then we are going to have to do a</div><div>GW> container to CDI adaptation for every CDI implementation out there.</div></div><div><br></div><div>Ed called among others this one an "excellent point".</div><div><br></div><div>But it's simply not true. In no version of what's being asked is there any "container to CDI adaptation for every CDI implementation out there". Extensions are portable in CDI, as you of course know.</div><div><br></div><div>"CDI to servlet mapping" also makes me wonder if it's fully understood what was being asked, which is essentially a portable extension that registers a Bean<T>.</div><div><br></div><div>Perhaps helping in taking any further objections away is the fact that one of the oldest, lowest level and arguably most conservative specs out there (JTA), did something quite similar. Implementations provide a small extension that registers an interceptor and a scope. The existence of this extension does not hurt nor influence JTA is situations where CDI is not used.</div><div><br></div><div>Backwards compatibility (in non EE environments) should be taken into account as Stuart mentioned. I.e. if an application that bundles CDI 1.x is run on a Servlet 4 container. For Java EE environments it's not an issue.</div><div><br></div><div>Kind regards,</div><div>Arjan Tijms</div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small"><br></div><div style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small">Antoine</div></div><br><div class="gmail_quote"><div><div class="gmail-h5"><div dir="ltr">Le mar. 13 sept. 2016 à 15:40, Martin Kouba <<a href="mailto:mkouba@redhat.com" target="_blank">mkouba@redhat.com</a>> a écrit :<br></div></div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div><div class="gmail-h5">Dne 13.9.2016 v 09:46 arjan tijms napsal(a):<br>
> p.s.<br>
><br>
> On Thu, Sep 8, 2016 at 2:40 PM, Martin Kouba <<a href="mailto:mkouba@redhat.com" target="_blank">mkouba@redhat.com</a><br>
> <mailto:<a href="mailto:mkouba@redhat.com" target="_blank">mkouba@redhat.com</a>>> wrote:<br>
><br>
> Stuart has a good point about backward compatibility. Servlet impl<br>
> would have to detect CDI version and skip registration if not 2.0+.<br>
> I think SERVLET_SPEC-116 should be reopened and the discussion<br>
> restarted.<br>
><br>
><br>
> Would you like to re-open that discussion on the Servlet list? Would be<br>
> good to have someone from the CDI EG explaining the case I think.<br>
<br>
Yes, that would be good. Antoine, you could meet some Servlet EG members<br>
on J1 and discuss the topic over a beer ;-)<br>
<br>
><br>
> Kind regards,<br>
> Arjan Tijms<br>
><br>
><br>
><br>
><br>
><br>
> Kind regards,<br>
> Arjan Tijms<br>
><br>
><br>
><br>
><br>
><br>
><br>
> But it's more complicated then it sounds. For example,<br>
> HttpServletRequest attibutes might be used as backing<br>
> storage of the<br>
> request context. So that it cannot simply change...<br>
><br>
> Anyway, I think this problem deserves some attention from<br>
> both the<br>
> CDI and the Servlet EG.<br>
><br>
> Martin<br>
><br>
> Dne 8.9.2016 v 13:31 arjan tijms napsal(a):<br>
><br>
> Hi,<br>
><br>
> On Thu, Sep 8, 2016 at 1:09 PM, Romain Manni-Bucau<br>
> <<a href="mailto:rmannibucau@gmail.com" target="_blank">rmannibucau@gmail.com</a> <mailto:<a href="mailto:rmannibucau@gmail.com" target="_blank">rmannibucau@gmail.com</a>><br>
> <mailto:<a href="mailto:rmannibucau@gmail.com" target="_blank">rmannibucau@gmail.com</a> <mailto:<a href="mailto:rmannibucau@gmail.com" target="_blank">rmannibucau@gmail.com</a>><wbr>><br>
> <mailto:<a href="mailto:rmannibucau@gmail.com" target="_blank">rmannibucau@gmail.com</a><br>
> <mailto:<a href="mailto:rmannibucau@gmail.com" target="_blank">rmannibucau@gmail.com</a><wbr>> <mailto:<a href="mailto:rmannibucau@gmail.com" target="_blank">rmannibucau@gmail.com</a><br>
> <mailto:<a href="mailto:rmannibucau@gmail.com" target="_blank">rmannibucau@gmail.com</a><wbr>>>>><br>
><br>
> wrote:<br>
><br>
> Hit that issue as well several times.<br>
><br>
> It is more vicious than it looks like IMO cause CDI will<br>
> *never* get<br>
> *the* right request for everybody, it is as simple<br>
> as that.<br>
> Any part<br>
> of the app can rely on the wrapper level N (of<br>
> course N being<br>
> different for each mentionned parts of the app).<br>
><br>
><br>
> What I was thinking, but maybe I'm wrong, is that the<br>
> application never<br>
> "just" wraps the request and uses it for itself. It always<br>
> passes it to<br>
> the container, which then passes it on to the next Filter,<br>
> Servlet, or<br>
> whatever. So at that point the container code has the<br>
> opportunity to<br>
> store the request as being the "current" one.<br>
><br>
> E.g. if you do:<br>
><br>
> RequestDispatcher dispatcher =<br>
> servletContext().<wbr>getRequestDispatcher(...);<br>
> dispatcher.forward(wrap(<wbr>request), response);<br>
><br>
> Then the RequestDispatcher, which is a container class,<br>
> receives the<br>
> wrapped request and can make it available.<br>
><br>
> The other way around, eventually every AuthModule, Filter or<br>
> Servlet has<br>
> to be called by the container at some point. E.g. the<br>
> "protected<br>
> void<br>
> service(HttpServletRequest req, HttpServletResponse<br>
> resp)" is<br>
> called by<br>
> the container.<br>
><br>
> So just before the container invokes the HttpServlet#service<br>
> method, the<br>
> container can store the request, and CDI (via an SPI)<br>
> can pick it up<br>
> from there.<br>
><br>
> That way in every context you can always have the *current*<br>
> request (the<br>
> request that's passed in to the last Servlet or Filter<br>
> call on<br>
> the stack).<br>
><br>
> Kind regards,<br>
> Arjan Tijms<br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
> Best CDI can do is to provide the request it has<br>
> (already<br>
> the case<br>
> and cost pretty much nothing) and enable the user to<br>
> produces very<br>
> easily its own request from its filter (or<br>
> equivalent) for<br>
> its usage<br>
> IMO - which is IMO already doable but maybe there is<br>
> another<br>
> shortcut we can introduce I didnt think about. If<br>
> you look<br>
> one step<br>
> further any web framework built on top of CDI does<br>
> it and<br>
> therefore<br>
> runs in a well known context.<br>
><br>
><br>
> Romain Manni-Bucau<br>
> @rmannibucau <<a href="https://twitter.com/rmannibucau" rel="noreferrer" target="_blank">https://twitter.com/<wbr>rmannibucau</a><br>
> <<a href="https://twitter.com/rmannibucau" rel="noreferrer" target="_blank">https://twitter.com/<wbr>rmannibucau</a>><br>
> <<a href="https://twitter.com/rmannibucau" rel="noreferrer" target="_blank">https://twitter.com/<wbr>rmannibucau</a><br>
> <<a href="https://twitter.com/rmannibucau" rel="noreferrer" target="_blank">https://twitter.com/<wbr>rmannibucau</a>>>> | Blog<br>
> <<a href="https://blog-rmannibucau.rhcloud.com" rel="noreferrer" target="_blank">https://blog-rmannibucau.<wbr>rhcloud.com</a><br>
> <<a href="https://blog-rmannibucau.rhcloud.com" rel="noreferrer" target="_blank">https://blog-rmannibucau.<wbr>rhcloud.com</a>><br>
> <<a href="https://blog-rmannibucau.rhcloud.com" rel="noreferrer" target="_blank">https://blog-rmannibucau.<wbr>rhcloud.com</a><br>
> <<a href="https://blog-rmannibucau.rhcloud.com" rel="noreferrer" target="_blank">https://blog-rmannibucau.<wbr>rhcloud.com</a>>>> | Old Wordpress Blog<br>
> <<a href="http://rmannibucau.wordpress.com" rel="noreferrer" target="_blank">http://rmannibucau.<wbr>wordpress.com</a><br>
> <<a href="http://rmannibucau.wordpress.com" rel="noreferrer" target="_blank">http://rmannibucau.<wbr>wordpress.com</a>><br>
> <<a href="http://rmannibucau.wordpress.com" rel="noreferrer" target="_blank">http://rmannibucau.<wbr>wordpress.com</a><br>
> <<a href="http://rmannibucau.wordpress.com" rel="noreferrer" target="_blank">http://rmannibucau.<wbr>wordpress.com</a>>>> | Github<br>
> <<a href="https://github.com/rmannibucau" rel="noreferrer" target="_blank">https://github.com/<wbr>rmannibucau</a><br>
> <<a href="https://github.com/rmannibucau" rel="noreferrer" target="_blank">https://github.com/<wbr>rmannibucau</a>><br>
> <<a href="https://github.com/rmannibucau" rel="noreferrer" target="_blank">https://github.com/<wbr>rmannibucau</a><br>
> <<a href="https://github.com/rmannibucau" rel="noreferrer" target="_blank">https://github.com/<wbr>rmannibucau</a>>>> | LinkedIn<br>
> <<a href="https://www.linkedin.com/in/rmannibucau" rel="noreferrer" target="_blank">https://www.linkedin.com/in/<wbr>rmannibucau</a><br>
> <<a href="https://www.linkedin.com/in/rmannibucau" rel="noreferrer" target="_blank">https://www.linkedin.com/in/<wbr>rmannibucau</a>><br>
> <<a href="https://www.linkedin.com/in/rmannibucau" rel="noreferrer" target="_blank">https://www.linkedin.com/in/<wbr>rmannibucau</a><br>
> <<a href="https://www.linkedin.com/in/rmannibucau" rel="noreferrer" target="_blank">https://www.linkedin.com/in/<wbr>rmannibucau</a>>>> | Tomitriber<br>
> <<a href="http://www.tomitribe.com" rel="noreferrer" target="_blank">http://www.tomitribe.com</a>> | JavaEE Factory<br>
> <<a href="https://javaeefactory-rmannibucau.rhcloud.com" rel="noreferrer" target="_blank">https://javaeefactory-<wbr>rmannibucau.rhcloud.com</a><br>
> <<a href="https://javaeefactory-rmannibucau.rhcloud.com" rel="noreferrer" target="_blank">https://javaeefactory-<wbr>rmannibucau.rhcloud.com</a>><br>
> <<a href="https://javaeefactory-rmannibucau.rhcloud.com" rel="noreferrer" target="_blank">https://javaeefactory-<wbr>rmannibucau.rhcloud.com</a><br>
> <<a href="https://javaeefactory-rmannibucau.rhcloud.com" rel="noreferrer" target="_blank">https://javaeefactory-<wbr>rmannibucau.rhcloud.com</a>>>><br>
><br>
> 2016-09-08 13:03 GMT+02:00 arjan tijms<br>
> <<a href="mailto:arjan.tijms@gmail.com" target="_blank">arjan.tijms@gmail.com</a> <mailto:<a href="mailto:arjan.tijms@gmail.com" target="_blank">arjan.tijms@gmail.com</a>><br>
> <mailto:<a href="mailto:arjan.tijms@gmail.com" target="_blank">arjan.tijms@gmail.com</a> <mailto:<a href="mailto:arjan.tijms@gmail.com" target="_blank">arjan.tijms@gmail.com</a>><wbr>><br>
> <mailto:<a href="mailto:arjan.tijms@gmail.com" target="_blank">arjan.tijms@gmail.com</a><br>
> <mailto:<a href="mailto:arjan.tijms@gmail.com" target="_blank">arjan.tijms@gmail.com</a><wbr>> <mailto:<a href="mailto:arjan.tijms@gmail.com" target="_blank">arjan.tijms@gmail.com</a><br>
> <mailto:<a href="mailto:arjan.tijms@gmail.com" target="_blank">arjan.tijms@gmail.com</a><wbr>>>>>:<br>
><br>
> Hi,<br>
><br>
> On Thu, Sep 8, 2016 at 12:40 PM, Martin Kouba<br>
> <<a href="mailto:mkouba@redhat.com" target="_blank">mkouba@redhat.com</a> <mailto:<a href="mailto:mkouba@redhat.com" target="_blank">mkouba@redhat.com</a>><br>
> <mailto:<a href="mailto:mkouba@redhat.com" target="_blank">mkouba@redhat.com</a> <mailto:<a href="mailto:mkouba@redhat.com" target="_blank">mkouba@redhat.com</a>>><br>
> <mailto:<a href="mailto:mkouba@redhat.com" target="_blank">mkouba@redhat.com</a><br>
> <mailto:<a href="mailto:mkouba@redhat.com" target="_blank">mkouba@redhat.com</a>> <mailto:<a href="mailto:mkouba@redhat.com" target="_blank">mkouba@redhat.com</a><br>
> <mailto:<a href="mailto:mkouba@redhat.com" target="_blank">mkouba@redhat.com</a>>>>><br>
><br>
> wrote:<br>
><br>
> that's a good question. In Weld, the request<br>
> object is<br>
> captured during request context activation,<br>
> i.e. during<br>
> ServletRequestListener.<wbr>requestInitialized()<br>
> notification and<br>
> before any filter or servlet is invoked. So<br>
> wrappers are<br>
> ignored and the original/first request is used.<br>
><br>
><br>
> Indeed, although do note that some servers<br>
> (Liberty and<br>
> WebLogic<br>
> I think) send the<br>
> ServletRequestListener.<wbr>requestInitialized()<br>
> notification rather late, and do that after the<br>
> application<br>
> already has seen the request and has had a chance to<br>
> wrap it.<br>
> This by itself is a separate problem. So on these<br>
> servers, Weld<br>
> would receive an early request but not<br>
> necessarily the<br>
> earliest.<br>
><br>
><br>
> But TBH I don't think we can fix this easily<br>
> as I'm not<br>
> aware of any portable way to listen for<br>
> "wrapping<br>
> actions".<br>
><br>
><br>
> This would have to happen with Server specific<br>
> code I guess,<br>
> just as Weld now requires an SPI to obtain the<br>
> current<br>
> principal<br>
> for injection.<br>
><br>
> You could say that the Servlet container could<br>
> store the<br>
> request<br>
> "somewhere" on a stack structure, just before it<br>
> invokes the<br>
> ServerAuthModule, Filter, Servlet and anything<br>
> else I<br>
> may have<br>
> forgotten, and then when control flows back to<br>
> each Servlet,<br>
> Filter, etc unwind that stack.<br>
><br>
> At the very least the spec for now should perhaps<br>
> clarify this?<br>
><br>
> Kind regards,<br>
> Arjan Tijms<br>
><br>
><br>
><br>
><br>
><br>
> Martin<br>
><br>
> Dne 8.9.2016 v 11:02 arjan tijms napsal(a):<br>
><br>
> Hi,<br>
><br>
> The CDI spec defines a built-in bean for<br>
> the type<br>
> HttpServletRequest. In<br>
> 3.8 it says:<br>
><br>
> "A servlet container must provide the<br>
> following<br>
> built-in<br>
> beans, all of<br>
> which have qualifier @Default:<br>
><br>
> a bean with bean type<br>
> javax.servlet.http.<wbr>HttpServletRequest,<br>
> allowing<br>
> injection of a reference to the<br>
> HttpServletRequest"<br>
><br>
> An HttpServletRequest however can be wrapped<br>
> multiple<br>
> times and by<br>
> multiple artefacts. I.e. by a<br>
> ServerAuthModule,<br>
> Filter and a<br>
> RequestDispatcher.<br>
><br>
> The question now is; which version of the<br>
> HttpServletRequest is supposed<br>
> to be injected?<br>
><br>
> * The first one in the chain?<br>
> * The last one in the chain?<br>
> * The current one at a given point in<br>
> the chain?<br>
><br>
> A little bit of experimenting seems to<br>
> indicate<br>
> it's now<br>
> often "one of<br>
> the first ones", e.g. the one that<br>
> happened to be<br>
> current when e.g. a<br>
> ServletRequestListener that initialises a<br>
> specific CDI<br>
> implementation is<br>
> called.<br>
><br>
> I think this is a little confusing, as<br>
> working<br>
> with an<br>
> injected request<br>
> can now totally ignore the request<br>
> wrapping that has<br>
> been done and break<br>
> an application badly.<br>
><br>
> Thoughts?<br>
><br>
> Kind regards,<br>
> Arjan Tijms<br>
><br>
><br>
><br>
><br>
> _____________________________<wbr>__________________<br>
> cdi-dev mailing list<br>
> <a href="mailto:cdi-dev@lists.jboss.org" target="_blank">cdi-dev@lists.jboss.org</a><br>
> <mailto:<a href="mailto:cdi-dev@lists.jboss.org" target="_blank">cdi-dev@lists.jboss.<wbr>org</a>><br>
> <mailto:<a href="mailto:cdi-dev@lists.jboss.org" target="_blank">cdi-dev@lists.jboss.<wbr>org</a><br>
> <mailto:<a href="mailto:cdi-dev@lists.jboss.org" target="_blank">cdi-dev@lists.jboss.<wbr>org</a>>><br>
> <mailto:<a href="mailto:cdi-dev@lists.jboss.org" target="_blank">cdi-dev@lists.jboss.<wbr>org</a> <mailto:<a href="mailto:cdi-dev@lists.jboss.org" target="_blank">cdi-dev@lists.jboss.<wbr>org</a>><br>
> <mailto:<a href="mailto:cdi-dev@lists.jboss.org" target="_blank">cdi-dev@lists.jboss.<wbr>org</a><br>
> <mailto:<a href="mailto:cdi-dev@lists.jboss.org" target="_blank">cdi-dev@lists.jboss.<wbr>org</a>>>><br>
><br>
> <a href="https://lists.jboss.org/mailman/listinfo/cdi-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/<wbr>mailman/listinfo/cdi-dev</a><br>
> <<a href="https://lists.jboss.org/mailman/listinfo/cdi-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/<wbr>mailman/listinfo/cdi-dev</a>><br>
> <<a href="https://lists.jboss.org/mailman/listinfo/cdi-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/<wbr>mailman/listinfo/cdi-dev</a><br>
> <<a href="https://lists.jboss.org/mailman/listinfo/cdi-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/<wbr>mailman/listinfo/cdi-dev</a>>><br>
><br>
> <<a href="https://lists.jboss.org/mailman/listinfo/cdi-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/<wbr>mailman/listinfo/cdi-dev</a><br>
> <<a href="https://lists.jboss.org/mailman/listinfo/cdi-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/<wbr>mailman/listinfo/cdi-dev</a>><br>
> <<a href="https://lists.jboss.org/mailman/listinfo/cdi-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/<wbr>mailman/listinfo/cdi-dev</a><br>
> <<a href="https://lists.jboss.org/mailman/listinfo/cdi-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/<wbr>mailman/listinfo/cdi-dev</a>>>><br>
><br>
> Note that for all code provided on this<br>
> list, the<br>
> provider licenses the code under the<br>
> Apache License,<br>
> Version 2<br>
><br>
> (<a href="http://www.apache.org/licenses/LICENSE-2.0.html" rel="noreferrer" target="_blank">http://www.apache.org/<wbr>licenses/LICENSE-2.0.html</a><br>
> <<a href="http://www.apache.org/licenses/LICENSE-2.0.html" rel="noreferrer" target="_blank">http://www.apache.org/<wbr>licenses/LICENSE-2.0.html</a>><br>
> <<a href="http://www.apache.org/licenses/LICENSE-2.0.html" rel="noreferrer" target="_blank">http://www.apache.org/<wbr>licenses/LICENSE-2.0.html</a><br>
> <<a href="http://www.apache.org/licenses/LICENSE-2.0.html" rel="noreferrer" target="_blank">http://www.apache.org/<wbr>licenses/LICENSE-2.0.html</a>>><br>
><br>
> <<a href="http://www.apache.org/licenses/LICENSE-2.0.html" rel="noreferrer" target="_blank">http://www.apache.org/<wbr>licenses/LICENSE-2.0.html</a><br>
> <<a href="http://www.apache.org/licenses/LICENSE-2.0.html" rel="noreferrer" target="_blank">http://www.apache.org/<wbr>licenses/LICENSE-2.0.html</a>><br>
> <<a href="http://www.apache.org/licenses/LICENSE-2.0.html" rel="noreferrer" target="_blank">http://www.apache.org/<wbr>licenses/LICENSE-2.0.html</a><br>
> <<a href="http://www.apache.org/licenses/LICENSE-2.0.html" rel="noreferrer" target="_blank">http://www.apache.org/<wbr>licenses/LICENSE-2.0.html</a>>>>). For<br>
> all other ideas provided on this list,<br>
> the provider<br>
> waives all patent and other intellectual<br>
> property rights<br>
> inherent in such information.<br>
><br>
><br>
> --<br>
> Martin Kouba<br>
> Software Engineer<br>
> Red Hat, Czech Republic<br>
><br>
><br>
><br>
> _____________________________<wbr>__________________<br>
> cdi-dev mailing list<br>
> <a href="mailto:cdi-dev@lists.jboss.org" target="_blank">cdi-dev@lists.jboss.org</a><br>
> <mailto:<a href="mailto:cdi-dev@lists.jboss.org" target="_blank">cdi-dev@lists.jboss.<wbr>org</a>> <mailto:<a href="mailto:cdi-dev@lists.jboss.org" target="_blank">cdi-dev@lists.jboss.<wbr>org</a><br>
> <mailto:<a href="mailto:cdi-dev@lists.jboss.org" target="_blank">cdi-dev@lists.jboss.<wbr>org</a>>><br>
> <mailto:<a href="mailto:cdi-dev@lists.jboss.org" target="_blank">cdi-dev@lists.jboss.<wbr>org</a><br>
> <mailto:<a href="mailto:cdi-dev@lists.jboss.org" target="_blank">cdi-dev@lists.jboss.<wbr>org</a>> <mailto:<a href="mailto:cdi-dev@lists.jboss.org" target="_blank">cdi-dev@lists.jboss.<wbr>org</a><br>
> <mailto:<a href="mailto:cdi-dev@lists.jboss.org" target="_blank">cdi-dev@lists.jboss.<wbr>org</a>>>><br>
> <a href="https://lists.jboss.org/mailman/listinfo/cdi-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/<wbr>mailman/listinfo/cdi-dev</a><br>
> <<a href="https://lists.jboss.org/mailman/listinfo/cdi-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/<wbr>mailman/listinfo/cdi-dev</a>><br>
> <<a href="https://lists.jboss.org/mailman/listinfo/cdi-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/<wbr>mailman/listinfo/cdi-dev</a><br>
> <<a href="https://lists.jboss.org/mailman/listinfo/cdi-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/<wbr>mailman/listinfo/cdi-dev</a>>><br>
><br>
> <<a href="https://lists.jboss.org/mailman/listinfo/cdi-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/<wbr>mailman/listinfo/cdi-dev</a><br>
> <<a href="https://lists.jboss.org/mailman/listinfo/cdi-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/<wbr>mailman/listinfo/cdi-dev</a>><br>
> <<a href="https://lists.jboss.org/mailman/listinfo/cdi-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/<wbr>mailman/listinfo/cdi-dev</a><br>
> <<a href="https://lists.jboss.org/mailman/listinfo/cdi-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/<wbr>mailman/listinfo/cdi-dev</a>>>><br>
><br>
> Note that for all code provided on this list,<br>
> the provider<br>
> licenses the code under the Apache License,<br>
> Version 2<br>
> (<a href="http://www.apache.org/licenses/LICENSE-2.0.html" rel="noreferrer" target="_blank">http://www.apache.org/<wbr>licenses/LICENSE-2.0.html</a><br>
> <<a href="http://www.apache.org/licenses/LICENSE-2.0.html" rel="noreferrer" target="_blank">http://www.apache.org/<wbr>licenses/LICENSE-2.0.html</a>><br>
> <<a href="http://www.apache.org/licenses/LICENSE-2.0.html" rel="noreferrer" target="_blank">http://www.apache.org/<wbr>licenses/LICENSE-2.0.html</a><br>
> <<a href="http://www.apache.org/licenses/LICENSE-2.0.html" rel="noreferrer" target="_blank">http://www.apache.org/<wbr>licenses/LICENSE-2.0.html</a>>><br>
> <<a href="http://www.apache.org/licenses/LICENSE-2.0.html" rel="noreferrer" target="_blank">http://www.apache.org/<wbr>licenses/LICENSE-2.0.html</a><br>
> <<a href="http://www.apache.org/licenses/LICENSE-2.0.html" rel="noreferrer" target="_blank">http://www.apache.org/<wbr>licenses/LICENSE-2.0.html</a>><br>
> <<a href="http://www.apache.org/licenses/LICENSE-2.0.html" rel="noreferrer" target="_blank">http://www.apache.org/<wbr>licenses/LICENSE-2.0.html</a><br>
> <<a href="http://www.apache.org/licenses/LICENSE-2.0.html" rel="noreferrer" target="_blank">http://www.apache.org/<wbr>licenses/LICENSE-2.0.html</a>>>>). For all<br>
> other ideas provided on this list, the provider<br>
> waives all<br>
> patent and other intellectual property rights<br>
> inherent<br>
> in such<br>
> information.<br>
><br>
><br>
><br>
><br>
><br>
> --<br>
> Martin Kouba<br>
> Software Engineer<br>
> Red Hat, Czech Republic<br>
><br>
><br>
<br>
--<br>
Martin Kouba<br>
Software Engineer<br>
Red Hat, Czech Republic<br>
______________________________<wbr>_________________<br>
cdi-dev mailing list<br>
<a href="mailto:cdi-dev@lists.jboss.org" target="_blank">cdi-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/cdi-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/<wbr>mailman/listinfo/cdi-dev</a><br>
<br></div></div>
Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (<a href="http://www.apache.org/licenses/LICENSE-2.0.html" rel="noreferrer" target="_blank">http://www.apache.org/<wbr>licenses/LICENSE-2.0.html</a>). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.<br>
</blockquote></div>
</blockquote></div><br></div></div>