<div dir="ltr">Hi,<br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Apr 1, 2015 at 10:25 PM, Romain Manni-Bucau <span dir="ltr"><<a href="mailto:rmannibucau@gmail.com" target="_blank">rmannibucau@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span><div>Hmm I dont think so. If I write <br></div></span><div>return new AsyncResult("Done in thread " + Thread.currentThread().getName()) ; // returns a Future<String></div><div><br></div><div>Then my code is not async at all, the get() call will just return my parameter, and no other thread will be used in that process. </div></div></div></div></blockquote><div><br></div></span><div>if the method has @Asynchronous it is, that is how the spec is defined. All other usages are not linked to asynchronism at all and es.submit(task) is not supposed to work before EJB 3.2.</div></div></div></div></blockquote><div><br></div><div>Indeed. If you have:</div><div><br></div><div>@Asynchronous</div><div>public Future<String> doAsync() { </div><div> return new AsyncResult("Done in thread " + Thread.currentThread().getName()) ; </div><div>} </div><div><br></div><div>And then from another location do:</div><div><br></div><div>String callerName = Thread.currentThread().getName();</div><div>String calleeName = bean.doAsync().get();</div><div><br></div><div>Then callerName is unequal to calleeName.</div><div><br></div><div>I've written an article a while back that uses AsyncResult as well in CDI code that tries to emulate how EJB works. I hope it somewhat more clearly demonstrates that AsyncResult is fully intended as a wrapper. See <a href="http://jdevelopment.nl/cdi-based-asynchronous-alternative">http://jdevelopment.nl/cdi-based-asynchronous-alternative</a></div><div><br></div><div>Kind regards,</div><div>Arjan Tijms</div><div><br></div><div><br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>BTW if you check the source code of the AsyncResult class (with a nice typo in it), its clearly written in it that it is not a real Future. <br></div><div><div><div><br></div></div></div></div></div></div></blockquote><div><br></div></span><div>Sure cause the container provides the async mecanism and this class is just here to make the impl trivial to do for user.</div><div><div class="h5"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><div><div></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div><span style="font-size:12.8000001907349px"></span></div><div><span style="font-size:12.8000001907349px">Because this is a synchronous call, that has to return a Future. But on the other hand this is purely tehcnical code, that cant be put in the framework, since one can call directly an EJB method. So the return type has to be the one of the EJB method. </span></div><div><span style="font-size:12.8000001907349px"><br></span></div><div><span style="font-size:12.8000001907349px">With events the situation is different. On the calling side, I write</span></div><div><span style="font-size:12.8000001907349px"><br></span></div><div><span style="font-size:12.8000001907349px">completableFuture = event.fireAsync(payload) ; // type is CompletionStage<probably void since there are many observers and an allOf call></span></div><div><span style="font-size:12.8000001907349px"><br></span></div><div><span style="font-size:12.8000001907349px">On the observing side I can write : </span></div><div><span style="font-size:12.8000001907349px"><br></span></div><div><span style="font-size:12.8000001907349px">public T observes(@Observes payload) { return t ; }</span></div><div><span style="font-size:12.8000001907349px"><br></span></div><div><span style="font-size:12.8000001907349px">And the framework will take care of wrapping this t in a CompletableFuture.allOf(...) with all the other observers to return it. So I dont have to deal myself with the technical aspects of calling ES myself. IMHO it leads to easier to write patterns. </span></div></div></blockquote><div><br></div></span><div>Why T then? And actually your explanation is my proposal but a on purpose typing.</div><div><div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><span><font color="#888888"><div><span style="font-size:12.8000001907349px"><br></span></div><div><span style="font-size:12.8000001907349px">José</span></div><div><span style="font-size:12.8000001907349px"><br></span></div><div><span style="font-size:12.8000001907349px"><br></span></div></font></span></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">2015-04-01 19:54 GMT+02:00 Romain Manni-Bucau <span dir="ltr"><<a href="mailto:rmannibucau@gmail.com" target="_blank">rmannibucau@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div><div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><br></div></div></div></div></div></div>
<br><div class="gmail_quote"><span>2015-04-01 19:43 GMT+02:00 José Paumard <span dir="ltr"><<a href="mailto:jose.paumard@gmail.com" target="_blank">jose.paumard@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">CompletionStage has a toCompletableFuture() method, that returns a CompletableFuture. So there is no limitation in returning CompletionStage. It could allow different implementation in the future than the only one we have so far : CompletableFuture, since one can build a CompletableFuture that wraps another implementation. <div><br></div></div></blockquote><div><br></div></span><div>+1, missed it</div><span><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div></div><div>Problem with CF.allOf() and anyOf() is that they return resp. CF<Void> and CF<Object>, which is not very API friendly. </div><div><br></div></div></blockquote><div><br></div></span><div>it is enough in enough cases IMO</div><span><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div></div><div>Having the observers writers to provide his own implementation of CompletableFuture is not that great imho. For the async EJB, all you can do is return executorService.submit(myTask). I understand why the API designers have chosen that, but I dont think it's that great. Correct me if I'm wrong, but I think that we have the opportunity to move that burden from the observers writers to the framework. And I think it would make the API easier to use. </div><div><br></div></div></blockquote><div><br></div></span><div>What's your proposal? EJB API is quite nice to use and it integrates smoothly with Future<>, not sure I get what's your issue is here.</div><div><div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div></div><div>José</div><div><br></div></div><div class="gmail_extra"><div><div><br><div class="gmail_quote">2015-04-01 10:08 GMT+02:00 Romain Manni-Bucau <span dir="ltr"><<a href="mailto:rmannibucau@gmail.com" target="_blank">rmannibucau@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">Hello Antoine,<br><div class="gmail_extra"><span><br clear="all"><div><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><br><span style="font-size:small">Romain Manni-Bucau</span><br><a href="https://twitter.com/rmannibucau" target="_blank">@rmannibucau</a> | <a href="http://rmannibucau.wordpress.com" target="_blank">Blog</a> | <a href="https://github.com/rmannibucau" target="_blank">Github</a> | <a href="https://www.linkedin.com/in/rmannibucau" target="_blank">LinkedIn</a> | <a href="http://www.tomitribe.com" target="_blank">Tomitriber</a></div></div></div></div></div></div></div></div></div></div>
<br></span><div class="gmail_quote"><span>2015-04-01 9:55 GMT+02:00 Antoine Sabot-Durand <span dir="ltr"><<a href="mailto:antoine@sabot-durand.net" target="_blank">antoine@sabot-durand.net</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><div>Hi Romain,</div><div><br></div><div>Intersting proposal. As I felt reading you that we misse the CompletableFuture stuff in Java 8, I just repeat here that the agreed on fireAsync signatures </div><div><br></div><div><U extends T> CompletionStage<U> fireAsync(U event);</div><div>and</div><div><U extends T> CompletionStage<U> fireAsync(U event, Executor executor);<br><br>Yeah it’s CompletionStage because Jozef preferred using interfaces in our API, but I guess implementation will use CompletableFuture under the hood to avoid reinventing the wheel.</div><div><br></div></div></blockquote><div><br></div></span><div>This sounds "normal" but JVM doesn't follow it with its utility methods so basically today CompletionStage is super poor compared to CompletionFuture so I'm tempted to say the impl is preferred here. I didn't check what is the adoption of both in other framework, can validate or not my thought maybe.</div><span><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><div></div><div>With this approach your example:</div><span><div><br></div><div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF"><div dir="ltr"><div>event.fireAsync(new LetTheWorldKnow()).thenRun(() -> System.out.println("We did it!"));</div></div></div></blockquote></div></div><div><br></div></span><div>will work without adding constraint on observer signature.</div><div><br></div><div>Regarding the observer part, we already discuss similar approach. In a former version of my async event doc I proposed using return type on observer to do discrimination between async and sync and Mark made a suggestion near yours during this meeting:</div><div><br></div><div><a href="http://transcripts.jboss.org/meeting/irc.freenode.org/cdi-dev/2015/cdi-dev.2015-02-25-17.06.log.html" target="_blank">http://transcripts.jboss.org/meeting/irc.freenode.org/cdi-dev/2015/cdi-dev.2015-02-25-17.06.log.html</a></div><div><br></div><div>(search for the first “signature” in text)</div><div><br></div><div>The main drawback of this approach is to let end user generate the returned CompletableFuture. So each async observer should provide a way to construct this completableFuture. The second question is the type param of the returned CompletableFuture. Should we use raw type? Now we could imagine helped to do that but...</div><div><br></div></div></blockquote><div><br></div></span><div>Exactly why I think this is a better solution. Cause it opens the door to asynchronism in a more elegant manner handling completion properly. I guess first impl will use allOf() combination but I see anyOf() - i fire to "notifiers" and I care only of 1 at least being called as a caller - and potentially other combinations other potentials needs we could cover in another spec (hopefully).</div><div><br></div><div>If async is just fire and forget we don't need fireAsync() but only fire() (void) and then observers are async or not which ensures compat at all levels since observers decide to be in the same context or not but I guess we don't want only fire and forget.</div><div><br></div><div>About creating a CompletableFuture we can do as in EJB spec and provide version to use by observer impl (<span style="color:rgb(53,56,51);font-family:Arial,Helvetica,sans-serif;font-size:12.1599998474121px">javax.ejb.AsyncResult)</span>.</div><div><div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><div></div><div>Don’t get me wrong, I’d love to find a solution based on this kind of idea, but I fear it will add more complexity than double activation.</div><span><font color="#888888"><div><br></div><div>Antoine</div></font></span><div><div><div><br></div><br><div><blockquote type="cite"><div>Le 1 avr. 2015 à 09:15, Romain Manni-Bucau <<a href="mailto:rmannibucau@gmail.com" target="_blank">rmannibucau@gmail.com</a>> a écrit :</div><br><div><p dir="ltr">No, fireAsync is still needed for all the reason we mzntionned - strongest one being the fact we need a return type and cant change fire - but using the return type we have the double activation without introducing a new API. Said otherwise API stays natural on both sides which was my main fear with a fireAsync and an @ObservesAsync (or any other new api we talked about). And we have the bonus to be aligned on SE async which sounds quite interesting for the future.</p>
<div class="gmail_quote">Le 1 avr. 2015 08:48, "Jozef Hartinger" <<a href="mailto:jharting@redhat.com" target="_blank">jharting@redhat.com</a>> a écrit :<br type="attribution"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
So instead of calling observers asynchronously you suggest turning
observers into producers of CompletableFuture that will then be
completed asynchronously?<br>
<br>
<div>On 03/31/2015 06:21 PM, Romain
Manni-Bucau wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">// fire side
<div>event.fireAsync(new LetTheWorldKnow()).thenRun(() ->
System.out.println("We did it!"));</div>
<div><br>
</div>
<div>// observer side</div>
<div>CompletableFuture iWantToKnow(@Observes LetTheWorldKnow
event) {}</div>
<div><br>
</div>
<div>// impl behavior would be like
CompletableFuture.allOf(allObserverReturnedInstances) to be
aligned on CompletableFuture behavior I think</div>
<div><br>
</div>
<div>Am I clearer?</div>
<div><br>
</div>
</div>
<div class="gmail_extra"><br clear="all">
<div>
<div>
<div dir="ltr">
<div>
<div dir="ltr">
<div>
<div dir="ltr">
<div>
<div dir="ltr">
<div><br>
<span style="font-size:small">Romain
Manni-Bucau</span><br>
<a href="https://twitter.com/rmannibucau" target="_blank">@rmannibucau</a> | <a href="http://rmannibucau.wordpress.com/" target="_blank">Blog</a> | <a href="https://github.com/rmannibucau" target="_blank">Github</a> | <a href="https://www.linkedin.com/in/rmannibucau" target="_blank">LinkedIn</a> | <a href="http://www.tomitribe.com/" target="_blank">Tomitriber</a></div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
<br>
<div class="gmail_quote">2015-03-31 18:15 GMT+02:00 Sven
Linstaedt <span dir="ltr"><<a href="mailto:sven.linstaedt@gmail.com" target="_blank">sven.linstaedt@gmail.com</a>></span>:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir="ltr">
<div>Hi Romain,</div>
<div><br>
</div>
I am not sure, I have fully understand how an observer
with <span style="font-size:12.8000001907349px">CompletableFuture could
look like. Could you give us an example? </span>
<div><span style="font-size:12.8000001907349px"><br>
</span></div>
<div><span style="font-size:12.8000001907349px">Afair </span><span style="font-size:12.8000001907349px">CompletableFuture</span><span style="font-size:12.8000001907349px"> was considered
to be used in the "trigger" side in order to track
async event invocation completion.</span></div>
<div><span style="font-size:12.8000001907349px"><br>
</span></div>
<div><span style="font-size:12.8000001907349px">br, Sven</span></div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">
<div>
<div>2015-03-31 18:00 GMT+02:00 Romain
Manni-Bucau <span dir="ltr"><<a href="mailto:rmannibucau@gmail.com" target="_blank">rmannibucau@gmail.com</a>></span>:<br>
</div>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div>
<div>
<div dir="ltr">Hi guys,
<div><br>
</div>
<div>on async topic if I followed we are at the
point where we are looking for an activation
on the observer side.</div>
<div><br>
</div>
<div>Since Java 8 has now CompletableFuture it
would be great to use it. Today the spec
doesnt use observer returned values so it is
mainly a bad practise to have one even if not
strictly forbidden - BTW never saw it in real
applications - plus spec is not compatible -
not specified at all - with CompletableFuture
since it is a new API so we can use it as a
marker.</div>
<div><br>
</div>
<div>This is quite interesting for few reasons:</div>
<div>1- we have our double activation</div>
<div>2- API is user friendly (observer is async
and has an async signature)</div>
<div>3- open door for future async enhancements
(hopefully not in CDI) with composition of
these observers</div>
<div><br>
</div>
<div><br>
</div>
<div>Only point I'm not sure is should these
observers support sync events. I don't see
anything blocking to do it but can have missed
something.</div>
<div><br>
</div>
<div><br>
</div>
<div>wdyt?</div>
<span><font color="#888888">
<div><br clear="all">
<div>
<div>
<div dir="ltr">
<div>
<div dir="ltr">
<div>
<div dir="ltr">
<div>
<div dir="ltr">
<div><br>
<span style="font-size:small">Romain
Manni-Bucau</span><br>
<a href="https://twitter.com/rmannibucau" target="_blank">@rmannibucau</a>
| <a href="http://rmannibucau.wordpress.com/" target="_blank">Blog</a> | <a href="https://github.com/rmannibucau" target="_blank">Github</a> | <a href="https://www.linkedin.com/in/rmannibucau" target="_blank">LinkedIn</a> |
<a href="http://www.tomitribe.com/" target="_blank">Tomitriber</a></div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</font></span></div>
<br>
</div>
</div>
_______________________________________________<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" target="_blank">https://lists.jboss.org/mailman/listinfo/cdi-dev</a><br>
<br>
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" target="_blank">http://www.apache.org/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>
<br>
</div>
</blockquote>
</div>
<br>
</div>
<br>
<fieldset></fieldset>
<br>
<pre>_______________________________________________
cdi-dev mailing list
<a href="mailto:cdi-dev@lists.jboss.org" target="_blank">cdi-dev@lists.jboss.org</a>
<a href="https://lists.jboss.org/mailman/listinfo/cdi-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/cdi-dev</a>
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" target="_blank">http://www.apache.org/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.</pre>
</blockquote>
<br>
</div>
</blockquote></div>
_______________________________________________<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" target="_blank">https://lists.jboss.org/mailman/listinfo/cdi-dev</a><br><br>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" target="_blank">http://www.apache.org/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.</div></blockquote></div><br></div></div></div></blockquote></div></div></div><br></div></div>
<br>_______________________________________________<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" target="_blank">https://lists.jboss.org/mailman/listinfo/cdi-dev</a><br>
<br>
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" target="_blank">http://www.apache.org/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><br><br clear="all"><div><br></div></div></div><span><font color="#888888">-- <br><div><div><a href="http://blog.paumard.org" target="_blank">Java le soir</a> <a href="http://blog.paumard.org/cours-tutoriaux/" target="_blank">Cours Java en ligne</a></div><div><a href="http://twitter.com/#!/JosePaumard" target="_blank">Twitter</a> <a href="http://www.parisjug.org" target="_blank">Paris JUG</a> <a href="http://www.devoxx.fr" target="_blank">Devoxx France</a></div><div>M : <a href="tel:%2B33%206%2076%2082%2091%2047" value="+33676829147" target="_blank">+33 6 76 82 91 47</a></div></div>
</font></span></div>
</blockquote></div></div></div><br></div></div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div><div><a href="http://blog.paumard.org" target="_blank">Java le soir</a> <a href="http://blog.paumard.org/cours-tutoriaux/" target="_blank">Cours Java en ligne</a></div><div><a href="http://twitter.com/#!/JosePaumard" target="_blank">Twitter</a> <a href="http://www.parisjug.org" target="_blank">Paris JUG</a> <a href="http://www.devoxx.fr" target="_blank">Devoxx France</a></div><div>M : <a href="tel:%2B33%206%2076%2082%2091%2047" value="+33676829147" target="_blank">+33 6 76 82 91 47</a></div></div>
</div>
</div></div></blockquote></div></div></div><br></div></div>
</blockquote></div></div></div><div><div><br><br clear="all"><div><br></div>-- <br><div><div><a href="http://blog.paumard.org" target="_blank">Java le soir</a> <a href="http://blog.paumard.org/cours-tutoriaux/" target="_blank">Cours Java en ligne</a></div><div><a href="http://twitter.com/#!/JosePaumard" target="_blank">Twitter</a> <a href="http://www.parisjug.org" target="_blank">Paris JUG</a> <a href="http://www.devoxx.fr" target="_blank">Devoxx France</a></div><div>M : <a href="tel:%2B33%206%2076%2082%2091%2047" value="+33676829147" target="_blank">+33 6 76 82 91 47</a></div></div>
</div></div></div></div>
</blockquote></div></div></div><br></div></div>
<br>_______________________________________________<br>
cdi-dev mailing list<br>
<a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/cdi-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/cdi-dev</a><br>
<br>
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" target="_blank">http://www.apache.org/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><br></div></div>