<div dir="ltr"><div>I suppose the part "Specifications that define an SPI" only covers those under the EE umbrella, though the document is about SE?</div><div><br></div><div><br></div><div>Werner</div><div><br></div><div class="gmail_extra"><div class="gmail_quote">On Thu, Dec 18, 2014 at 1:26 PM, <span dir="ltr"><<a href="mailto:cdi-dev-request@lists.jboss.org" target="_blank">cdi-dev-request@lists.jboss.org</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid">Send cdi-dev mailing list submissions to<br>
<a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a><br>
<br>
To subscribe or unsubscribe via the World Wide Web, visit<br>
<a href="https://lists.jboss.org/mailman/listinfo/cdi-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/cdi-dev</a><br>
or, via email, send a message with subject or body 'help' to<br>
<a href="mailto:cdi-dev-request@lists.jboss.org">cdi-dev-request@lists.jboss.org</a><br>
<br>
You can reach the person managing the list at<br>
<a href="mailto:cdi-dev-owner@lists.jboss.org">cdi-dev-owner@lists.jboss.org</a><br>
<br>
When replying, please edit your Subject line so it is more specific<br>
than "Re: Contents of cdi-dev digest..."<br>
<br>
<br>
Today's Topics:<br>
<br>
1. Re: Today's meeting will be shorter and about SE (John D. Ament)<br>
<br>
<br>
----------------------------------------------------------------------<br>
<br>
Message: 1<br>
Date: Thu, 18 Dec 2014 07:26:02 -0500<br>
From: "John D. Ament" <<a href="mailto:john.d.ament@gmail.com">john.d.ament@gmail.com</a>><br>
Subject: Re: [cdi-dev] Today's meeting will be shorter and about SE<br>
To: Jos? Paumard <<a href="mailto:jose.paumard@gmail.com">jose.paumard@gmail.com</a>><br>
Cc: cdi-dev <<a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a>><br>
Message-ID:<br>
<CAOqetn-dUX8HP5v9hCYKP-i8eViK69ZXDf0urtqUv1GtL=<a href="mailto:10RA@mail.gmail.com">10RA@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
I would recommend that at least some of these comments make their way into<br>
the google doc. Things like BeanManager come from there.<br>
<br>
I simply dropped a huge code snippet in here since there was no easy way to<br>
include it in the doc.<br>
<br>
On Thu, Dec 18, 2014 at 5:57 AM, Jos? Paumard <<a href="mailto:jose.paumard@gmail.com">jose.paumard@gmail.com</a>><br>
wrote:<br>
><br>
> Yes, there are good use cases for letting the user provide his own ES to<br>
> have async calls executed in them. They are the same kind of use cases we<br>
> have for CompletionStage.<br>
><br>
> Jos?<br>
><br>
> 2014-12-18 10:18 GMT+01:00 Romain Manni-Bucau <<a href="mailto:rmannibucau@gmail.com">rmannibucau@gmail.com</a>>:<br>
>><br>
>> 2014-12-18 9:58 GMT+01:00 Jos? Paumard <<a href="mailto:jose.paumard@gmail.com">jose.paumard@gmail.com</a>>:<br>
>> > From what we wrote about async events, ES can be submitted through the<br>
>> > fireAsync call, following the patterns of CompletionStage. We can also<br>
>> > submit a default ES while building a CDI container (a you wrote), and<br>
>> if we<br>
>> > dont the default ES will probably be the default ForkJoinPool.<br>
>> ><br>
>> > So we may have more than one ES, making things more complicated than the<br>
>> > pattern you wrote. I think that having the user to close all the ESes<br>
>> will<br>
>> > lead to the same pattern again and again :<br>
>> > for (ES es : cdi.getESes()) {<br>
>> > myShutdown(es) ;<br>
>> > }<br>
>> ><br>
>><br>
>> Sorry I missed something here: how can we get multiple ES? Basically<br>
>> if CDI needs a ES behing the scene I expect it expose few config like<br>
>> potential concurrent calls number etc...In such a case I'm not sure if<br>
>> having multiple ES would be a good idea.<br>
>><br>
>> > I'd prefer to have a cdi.shutdown(), cdi.shudownNow() or<br>
>> > cdi.awaitTermination(...) or whatever we call those methods, to<br>
>> encapsulate<br>
>> > this code. Seems cleaner to me. It might look like CDI is becoming an ES<br>
>> > itself, but it's delegation, not inheritance.<br>
>> ><br>
>> ><br>
>> ><br>
>> > 2014-12-18 9:28 GMT+01:00 Romain Manni-Bucau <<a href="mailto:rmannibucau@gmail.com">rmannibucau@gmail.com</a>>:<br>
>> >><br>
>> >> Why exposing them? When not simply exposing the executor service (in<br>
>> >> "init" method).<br>
>> >><br>
>> >> CDIContainer cdi =<br>
>> CDIContainer.init(singletonMap(ExecutorService.class,<br>
>> >> myEs));<br>
>> >> // do something awesome<br>
>> >> shutdownAsIwant(myEs);<br>
>> >> cdi.close();<br>
>> >><br>
>> >> Would avoid to have a lot of method several users will not care about.<br>
>> >><br>
>> >> By default it would do a if (timeout <= 0 ||<br>
>> >> !defaultEs.awaitTermination(timeout, MILLISECONDS)) { for (Runnable r<br>
>> >> : defaultEs.shutdownNow()) { try { r.cancel(); } catch(e) { log(e); }<br>
>> >> } } with timeout a property of the init map with a default in<br>
>> >> CDIContainer (constant)<br>
>> >><br>
>> >> wdyt?<br>
>> >><br>
>> >><br>
>> >> Romain Manni-Bucau<br>
>> >> @rmannibucau<br>
>> >> <a href="http://www.tomitribe.com" target="_blank">http://www.tomitribe.com</a><br>
>> >> <a href="http://rmannibucau.wordpress.com" target="_blank">http://rmannibucau.wordpress.com</a><br>
>> >> <a href="https://github.com/rmannibucau" target="_blank">https://github.com/rmannibucau</a><br>
>> >><br>
>> >><br>
>> >> 2014-12-18 9:19 GMT+01:00 Jos? Paumard <<a href="mailto:jose.paumard@gmail.com">jose.paumard@gmail.com</a>>:<br>
>> >> > I think we need to think more about how to close the Container.<br>
>> >> ><br>
>> >> > We need to take into account the fact that there wil be async process<br>
>> >> > running in ExecutorServices (SE) or ManagedExecutorServices (EE). So<br>
>> the<br>
>> >> > shutting down the container will mean shutting down these ES too.<br>
>> >> ><br>
>> >> > So I think we should need to carefully look at the way ES are closed.<br>
>> >> > The<br>
>> >> > question being : what do we do with async tasks that are still<br>
>> running :<br>
>> >> > should we abruptely interrupt them ? give them a chance to complete ?<br>
>> >> > All<br>
>> >> > these are exposed in different methods of ES : shutdown(),<br>
>> shutdownNow()<br>
>> >> > and<br>
>> >> > awaitTermination(timeout). Since the container will have to call one<br>
>> of<br>
>> >> > these methods per ES it will manage, I think we should also expose<br>
>> them.<br>
>> >> ><br>
>> >> > Jos?<br>
>> >> ><br>
>> >> ><br>
>> >> > 2014-12-18 9:14 GMT+01:00 Romain Manni-Bucau <<a href="mailto:rmannibucau@gmail.com">rmannibucau@gmail.com</a><br>
>> >:<br>
>> >> >><br>
>> >> >> ServiceLoader.load(<api>) = ServiceLoader.load(<api>, tccl)<br>
>> >> >><br>
>> >> >> I was thinking to a plain servlet engine (tomcat to not say any<br>
>> name)<br>
>> >> >> and CDI container API to boot in webapps. Having cdi API in tomcat<br>
>> >> >> itself and CDI impl in webapps (Weld in webapp1, OWB in webapp2 for<br>
>> >> >> instance). This would mean using one webapp classloader to find the<br>
>> >> >> booter/container. This is fine excepted if the instance is cached.<br>
>> >> >><br>
>> >> >> Same thought in more complicated about OSGi but I guess it is not<br>
>> yet<br>
>> >> >> the target.<br>
>> >> >><br>
>> >> >><br>
>> >> >> Romain Manni-Bucau<br>
>> >> >> @rmannibucau<br>
>> >> >> <a href="http://www.tomitribe.com" target="_blank">http://www.tomitribe.com</a><br>
>> >> >> <a href="http://rmannibucau.wordpress.com" target="_blank">http://rmannibucau.wordpress.com</a><br>
>> >> >> <a href="https://github.com/rmannibucau" target="_blank">https://github.com/rmannibucau</a><br>
>> >> >><br>
>> >> >><br>
>> >> >> 2014-12-18 8:58 GMT+01:00 Jozef Hartinger <<a href="mailto:jharting@redhat.com">jharting@redhat.com</a>>:<br>
>> >> >> ><br>
>> >> >> > On 12/18/2014 08:48 AM, Romain Manni-Bucau wrote:<br>
>> >> >> >><br>
>> >> >> >> Hi guys,<br>
>> >> >> >><br>
>> >> >> >> - why shutdown and not AutoClosable?<br>
>> >> >> ><br>
>> >> >> > I like this idea.<br>
>> >> >> >><br>
>> >> >> >> - about instance: it uses TCCL to load the impls, not sure it is<br>
>> >> >> >> intended but depending the deployment it can be an issue (is this<br>
>> >> >> >> api<br>
>> >> >> >> 100% JavaSE + flat classpath - ie more constrained than JavaSE?)<br>
>> +<br>
>> >> >> >> most of javax SPI creates a new instance each time "creator" is<br>
>> >> >> >> called.<br>
>> >> >> ><br>
>> >> >> > I don't follow. Who uses TCCL?<br>
>> >> >> >><br>
>> >> >> >> - Why Booter and not Container (better than factory IMO)? 1) for<br>
>> >> >> >> consistency with other spec, 2) why can I shutdown a booter ;)?<br>
>> >> >> ><br>
>> >> >> > Exactly<br>
>> >> >> ><br>
>> >> >> >><br>
>> >> >> >><br>
>> >> >> >><br>
>> >> >> >> Romain Manni-Bucau<br>
>> >> >> >> @rmannibucau<br>
>> >> >> >> <a href="http://www.tomitribe.com" target="_blank">http://www.tomitribe.com</a><br>
>> >> >> >> <a href="http://rmannibucau.wordpress.com" target="_blank">http://rmannibucau.wordpress.com</a><br>
>> >> >> >> <a href="https://github.com/rmannibucau" target="_blank">https://github.com/rmannibucau</a><br>
>> >> >> >><br>
>> >> >> >><br>
>> >> >> >> 2014-12-18 8:37 GMT+01:00 Jozef Hartinger <<a href="mailto:jharting@redhat.com">jharting@redhat.com</a>>:<br>
>> >> >> >>><br>
>> >> >> >>> On 12/18/2014 04:33 AM, John D. Ament wrote:<br>
>> >> >> >>><br>
>> >> >> >>> I thought today's meeting was pretty good. Based on one of the<br>
>> >> >> >>> discussion<br>
>> >> >> >>> points, I wanted to try putting together an interface that<br>
>> >> >> >>> described<br>
>> >> >> >>> the<br>
>> >> >> >>> boot paradigm. Unfortunately even in Java 8 it doesn't work too<br>
>> >> >> >>> well,<br>
>> >> >> >>> I<br>
>> >> >> >>> cannot assign a static variable in an interface the way I can<br>
>> in an<br>
>> >> >> >>> abstract<br>
>> >> >> >>> class. More importantly, it doesn't give us the private level<br>
>> >> >> >>> expectation I<br>
>> >> >> >>> would look for in this case. I best I could come up with using<br>
>> an<br>
>> >> >> >>> interface<br>
>> >> >> >>> is:<br>
>> >> >> >>><br>
>> >> >> >>> public interface CDIBooter {<br>
>> >> >> >>> default BeanManager initialize() {<br>
>> >> >> >>> return initialize(new HashMap<>());<br>
>> >> >> >>> }<br>
>> >> >> >>><br>
>> >> >> >>> BeanManager initialize(Map<?,?> properties);<br>
>> >> >> >>><br>
>> >> >> >>> Why BeanManager? I think it would be better to return CDI or its<br>
>> >> >> >>> subclass<br>
>> >> >> >>> rather than this low-level SPI. With the CDI class we get more<br>
>> >> >> >>> user-friendly<br>
>> >> >> >>> Instance<T> for free. We could also expose Event<T> similarly.<br>
>> >> >> >>><br>
>> >> >> >>><br>
>> >> >> >>> void shutdown();<br>
>> >> >> >>><br>
>> >> >> >>> class BootHolder {<br>
>> >> >> >>><br>
>> >> >> >>> static CDIBooter instance = null;<br>
>> >> >> >>><br>
>> >> >> >>> }<br>
>> >> >> >>><br>
>> >> >> >>> static CDIBooter instance() {<br>
>> >> >> >>> if(BootHolder.instance == null) {<br>
>> >> >> >>> ServiceLoader<CDIBooter> serviceLoader =<br>
>> >> >> >>> ServiceLoader.load(CDIBooter.class);<br>
>> >> >> >>> for(CDIBooter booter : serviceLoader) {<br>
>> >> >> >>> BootHolder.instance = booter;<br>
>> >> >> >>> break;<br>
>> >> >> >>> }<br>
>> >> >> >>> }<br>
>> >> >> >>> return BootHolder.instance;<br>
>> >> >> >>> }<br>
>> >> >> >>> }<br>
>> >> >> >>><br>
>> >> >> >>> where as the abstract class is a bit briefer, while also being<br>
>> >> >> >>> private.<br>
>> >> >> >>><br>
>> >> >> >>> public abstract class CDIBooter {<br>
>> >> >> >>> public BeanManager initialize() {<br>
>> >> >> >>> return initialize(new HashMap<>());<br>
>> >> >> >>> }<br>
>> >> >> >>><br>
>> >> >> >>> public abstract BeanManager initialize(Map<?,?><br>
>> properties);<br>
>> >> >> >>><br>
>> >> >> >>> public abstract void shutdown();<br>
>> >> >> >>><br>
>> >> >> >>> private static CDIBooter instance = null;<br>
>> >> >> >>><br>
>> >> >> >>> public static CDIBooter instance() {<br>
>> >> >> >>> if(instance == null) {<br>
>> >> >> >>> ServiceLoader<CDIBooter> serviceLoader =<br>
>> >> >> >>> ServiceLoader.load(CDIBooter.class);<br>
>> >> >> >>> for(CDIBooter booter : serviceLoader) {<br>
>> >> >> >>> instance = booter;<br>
>> >> >> >>> break;<br>
>> >> >> >>> }<br>
>> >> >> >>> }<br>
>> >> >> >>> return instance;<br>
>> >> >> >>> }<br>
>> >> >> >>> }<br>
>> >> >> >>><br>
>> >> >> >>> Obviously ignore concurrency issues, etc. It does look to be<br>
>> safer<br>
>> >> >> >>> to<br>
>> >> >> >>> do<br>
>> >> >> >>> an<br>
>> >> >> >>> abstract class, rather than a factory-interface.<br>
>> >> >> >>><br>
>> >> >> >>> John<br>
>> >> >> >>><br>
>> >> >> >>><br>
>> >> >> >>> On Wed Dec 17 2014 at 10:40:44 AM Antoine Sabot-Durand<br>
>> >> >> >>> <<a href="mailto:antoine@sabot-durand.net">antoine@sabot-durand.net</a>> wrote:<br>
>> >> >> >>>><br>
>> >> >> >>>> Hi all,<br>
>> >> >> >>>><br>
>> >> >> >>>><br>
>> >> >> >>>> I have business matter and will have to shorten the meeting<br>
>> >> >> >>>> tonight<br>
>> >> >> >>>> (half<br>
>> >> >> >>>> an hour instead of 1h).<br>
>> >> >> >>>><br>
>> >> >> >>>> I updated the SE doc and Antonio added useful annexes :<br>
>> >> >> >>>><br>
>> >> >> >>>><br>
>> >> >> >>>><br>
>> >> >> >>>><br>
>> <a href="https://docs.google.com/document/d/1LgsGT-AAlrF72Z5pW4xNQiVjUHGUME46ZmB-wwF35Yw/edit?usp=sharing" target="_blank">https://docs.google.com/document/d/1LgsGT-AAlrF72Z5pW4xNQiVjUHGUME46ZmB-wwF35Yw/edit?usp=sharing</a><br>
>> >> >> >>>><br>
>> >> >> >>>> I propose we focus on this in these 30 mn<br>
>> >> >> >>>><br>
>> >> >> >>>> regards,<br>
>> >> >> >>>><br>
>> >> >> >>>> Antoine<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<br>
>> >> >> >>>> licenses<br>
>> >> >> >>>> the<br>
>> >> >> >>>> code under the Apache License, Version 2<br>
>> >> >> >>>> (<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<br>
>> other<br>
>> >> >> >>>> ideas<br>
>> >> >> >>>> provided on this list, the provider waives all patent and other<br>
>> >> >> >>>> intellectual<br>
>> >> >> >>>> property rights inherent in such information.<br>
>> >> >> >>><br>
>> >> >> >>><br>
>> >> >> >>><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<br>
>> licenses<br>
>> >> >> >>> the<br>
>> >> >> >>> code<br>
>> >> >> >>> under the Apache License, Version 2<br>
>> >> >> >>> (<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<br>
>> other<br>
>> >> >> >>> ideas<br>
>> >> >> >>> provided on this list, the provider waives all patent and other<br>
>> >> >> >>> intellectual<br>
>> >> >> >>> property rights inherent in such information.<br>
>> >> >> >>><br>
>> >> >> >>><br>
>> >> >> >>><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<br>
>> licenses<br>
>> >> >> >>> the<br>
>> >> >> >>> code<br>
>> >> >> >>> under the Apache License, Version 2<br>
>> >> >> >>> (<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<br>
>> other<br>
>> >> >> >>> ideas<br>
>> >> >> >>> provided on this list, the provider waives all patent and other<br>
>> >> >> >>> intellectual<br>
>> >> >> >>> property rights inherent in such information.<br>
>> >> >> ><br>
>> >> >> ><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<br>
>> the<br>
>> >> >> code under the Apache License, Version 2<br>
>> >> >> (<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<br>
>> ideas<br>
>> >> >> provided on this list, the provider waives all patent and other<br>
>> >> >> intellectual<br>
>> >> >> property rights inherent in such information.<br>
>> >> ><br>
>> >> ><br>
>> >> ><br>
>> >> > --<br>
>> >> > Java le soir Cours Java en ligne<br>
>> >> > Twitter Paris JUG Devoxx France<br>
>> >> > M : <a href="tel:%2B33%206%2076%2082%2091%2047" value="+33676829147">+33 6 76 82 91 47</a><br>
>> ><br>
>> ><br>
>> ><br>
>> > --<br>
>> > Java le soir Cours Java en ligne<br>
>> > Twitter Paris JUG Devoxx France<br>
>> > M : <a href="tel:%2B33%206%2076%2082%2091%2047" value="+33676829147">+33 6 76 82 91 47</a><br>
>><br>
><br>
><br>
> --<br>
> Java le soir <<a href="http://blog.paumard.org" target="_blank">http://blog.paumard.org</a>> Cours Java en ligne<br>
> <<a href="http://blog.paumard.org/cours-tutoriaux/" target="_blank">http://blog.paumard.org/cours-tutoriaux/</a>><br>
> Twitter <<a href="http://twitter.com/#!/JosePaumard" target="_blank">http://twitter.com/#!/JosePaumard</a>> Paris JUG<br>
> <<a href="http://www.parisjug.org" target="_blank">http://www.parisjug.org</a>> Devoxx France <<a href="http://www.devoxx.fr" target="_blank">http://www.devoxx.fr</a>><br>
> M : <a href="tel:%2B33%206%2076%2082%2091%2047" value="+33676829147">+33 6 76 82 91 47</a><br>
><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<br>
> code under the Apache License, Version 2 (<br>
> <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<br>
> provided on this list, the provider waives all patent and other<br>
> intellectual property rights inherent in such information.<br>
><br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <a href="http://lists.jboss.org/pipermail/cdi-dev/attachments/20141218/dd583504/attachment.html" target="_blank">http://lists.jboss.org/pipermail/cdi-dev/attachments/20141218/dd583504/attachment.html</a><br>
<br>
------------------------------<br>
<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>
<br>
End of cdi-dev Digest, Vol 49, Issue 23<br>
***************************************<br>
</blockquote></div></div></div>