Could you build something that we can reproduce ? Ot at least give more details about what happens (services, start level, etc..) ?
I've done an enhancement in blueprint so that when the extender detects that the framework is stopping, it will preemptively shutdown all blueprint containers. So is the bundle accessing the service a blueprint one ? If not, then that's somewhat expected. You can disable this behaviour by setting the org.apache.aries.blueprint.preemptiveShutdown=false in etc/config.properties However, if you expect things to just shutdown bundles in the correct order, that's not gonna happen. The framework shut them down in reverse start level order, so services are removed in that way. If a bundle with a low start level uses a service from a bundle with a higher start level, it won't be there. And that means that the bundle is flawed and should support the fact that one of its needed service is gone. On Sun, Feb 17, 2013 at 8:44 AM, Dan Tran <dant...@gmail.com> wrote: > karf-2.3.1-snapshot with felix 4.2.0 does not help either. > > Thanks your for looking into this issue > > -D > > On Sat, Feb 16, 2013 at 11:40 PM, Jean-Baptiste Onofré <j...@nanthrax.net> > wrote: > > It sounds like a bug in Aries Blueprint. Let me try to reproduce with a > > simple test case. > > > > Regards > > JB > > > > > > On 02/17/2013 08:21 AM, Dan Tran wrote: > >> > >> this issue also happens in karaf 2.3.0 but it is very intermittent, I > >> am able to play with start level, and with some luck, the problem went > >> away. > >> > >> Only with 2.3.1-snapshot the issue is very repeatable. > >> > >> I am going to build 2.3.1-snapshot with filix 4.2.0 to see if it helps. > >> > >> for me both 2.3.0 and 2.3.1 is not ready for full production yet and I > >> still have some time to wait as well > >> > >> Thanks > >> > >> -D > >> > >> > >> On Sat, Feb 16, 2013 at 11:15 PM, Jean-Baptiste Onofré <j...@nanthrax.net > > > >> wrote: > >>> > >>> I created a Jira to update to Felix Framework 4.2.0 but only on trunk > and > >>> for Karaf 2.4.0. > >>> > >>> I'm going to test if it helps for this issue, if so, I will upgrade for > >>> Karaf 2.3.1 as well. > >>> > >>> Did you notice this issue with Karaf 2.3.0 as well ? > >>> > >>> Thanks > >>> Regards > >>> JB > >>> > >>> > >>> On 02/17/2013 08:12 AM, Dan Tran wrote: > >>>> > >>>> > >>>> May be an upgrade to felix 4.2 is needed? > >>>> > >>>> On Mon, Feb 11, 2013 at 8:56 AM, Dan Tran <dant...@gmail.com> wrote: > >>>>> > >>>>> > >>>>> In 2.3.0, this issue is intermittent, I was able to twist start > level, > >>>>> and luckily it disappears. In 2.3.1-SNAPSHOT, it consistently > happen, > >>>>> In a way this is a good news since It is always reproducible. > >>>>> > >>>>> -D > >>>>> > >>>>> On Fri, Feb 8, 2013 at 1:52 PM, Dan Tran <dant...@gmail.com> wrote: > >>>>>> > >>>>>> > >>>>>> I am testing with the latest apache-karaf-2.3.1-SNAPSHOT with latest > >>>>>> aries blueprint. and still see this issue > >>>>>> > >>>>>> where one of my blueprint's destroy method needs a service from > >>>>>> another bundle, however, that bundle's service is not longer > >>>>>> available. Is it bug from latest blueprint? Looks like blueprint > >>>>>> remove the service too early? > >>>>>> > >>>>>> > >>>>>> 2013-02-08 13:31:16,067 | ERROR | FelixShutdown | BeanRecipe > >>>>>> | s.blueprint.container.BeanRecipe 873 | 7 - > >>>>>> org.apache.aries.blueprint.core - 1.1.0 | The blueprint bean > >>>>>> fileStreamDataProviderFactory in bundle > >>>>>> xxxxx.data.provider.filestream/1.0.0.SNAPSHOT incorrectly threw an > >>>>>> exception from its destroy method. > >>>>>> org.osgi.service.blueprint.container.ServiceUnavailableException: > The > >>>>>> Blueprint container is being or has been destroyed: > >>>>>> (objectClass=xxxxxd.data.provider.core.ConnectionFactory) > >>>>>> at > >>>>>> > >>>>>> > org.apache.aries.blueprint.container.ReferenceRecipe.getService(ReferenceRecipe.java:233) > >>>>>> at > >>>>>> > >>>>>> > org.apache.aries.blueprint.container.ReferenceRecipe.access$000(ReferenceRecipe.java:54) > >>>>>> at > >>>>>> > >>>>>> > org.apache.aries.blueprint.container.ReferenceRecipe$ServiceDispatcher.call(ReferenceRecipe.java:291) > >>>>>> at > >>>>>> > >>>>>> > Proxy292eef6e_56c9_4a23_9717_803ff8d4fb86.deregisterDataProvider(Unknown > >>>>>> Source) > >>>>>> at > >>>>>> > >>>>>> > xxxxxx.data.provider.filestream.internal.core.DefaultFileStreamDataProviderFactory.cleanup(DefaultFileStreamDataProviderFactory.java:114) > >>>>>> > >>>>>> [....] > >>>>>> > >>>>>> 2013-02-08 13:31:16,159 | INFO | FelixShutdown | > BlueprintExtender > >>>>>> | nt.container.BlueprintExtender$3 282 | 7 - > >>>>>> org.apache.aries.blueprint.core - 1.1.0 | Destroying > >>>>>> BlueprintContainer for bundle xxxxx.storage.core > >>>>>> > >>>>>> > >>>>>> The service not available bundle eventually destroyed at the end > >>>>>> successfully > >>>>>> > >>>>>> > >>>>>> Thanks > >>>>>> > >>>>>> -D > >>>>>> > >>>>>> On Fri, Jan 18, 2013 at 2:21 PM, Dan Tran <dant...@gmail.com> > wrote: > >>>>>>> > >>>>>>> > >>>>>>> Thanks JB > >>>>>>> > >>>>>>> -D > >>>>>>> > >>>>>>> On Fri, Jan 18, 2013 at 2:19 PM, Jean-Baptiste Onofré > >>>>>>> <j...@nanthrax.net> > >>>>>>> wrote: > >>>>>>>> > >>>>>>>> > >>>>>>>> Hi Dan, > >>>>>>>> > >>>>>>>> yes, we are working on the Aries update (to fix the Blueprint > >>>>>>>> issues). > >>>>>>>> > >>>>>>>> I submitted a patch about to Aries, I gonna check if a new > SNAPSHOT > >>>>>>>> has been > >>>>>>>> deployed (at Aries) including the patch. > >>>>>>>> > >>>>>>>> I keep you posted. > >>>>>>>> > >>>>>>>> Regards > >>>>>>>> JB > >>>>>>>> > >>>>>>>> > >>>>>>>> On 01/18/2013 11:17 PM, Dan Tran wrote: > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> I now have my apache karaf 2.3.1-snapshot to pickup > blueprint-core > >>>>>>>>> 1.1.0-SNAPSHOT and blueprint-cm 1.0.1-SNAPSHOT > >>>>>>>>> > >>>>>>>>> my karaf.bat now hangs at startup > >>>>>>>>> > >>>>>>>>> ERROR: Bundle org.apache.aries.blueprint.cm [8] Error starting > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> mvn:org.apache.aries.blueprint/ > org.apache.aries.blueprint.cm/1.0.1-SNAPSHOT > >>>>>>>>> (org.osgi.framework.BundleException: Unresolved constraint in > >>>>>>>>> bundle org.apache.aries.blueprint.cm [8]: Unable to resolve > >>>>>>>>> 8.0: > >>>>>>>>> missing requirement [8.0] osgi.wiring.package; > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > (&(osgi.wiring.package=org.apache.aries.blueprint)(version>=1.0.0)(!(version>=1.2.0)))) > >>>>>>>>> > >>>>>>>>> org.osgi.framework.BundleException: Unresolved constraint in > bundle > >>>>>>>>> org.apache.aries.blueprint.cm [8]: Unable to resolve 8.0: > missing > >>>>>>>>> requirement [8.0] osgi.wiring.package; > (&(osgi.wiring.package=org. > >>>>>>>>> apache.aries.blueprint)(version>=1.0.0)(!(version>=1.2.0))) > >>>>>>>>> at > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:3826) > >>>>>>>>> at > >>>>>>>>> org.apache.felix.framework.Felix.startBundle(Felix.java:1868) > >>>>>>>>> at > >>>>>>>>> > >>>>>>>>> > org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1191) > >>>>>>>>> at > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLevelImpl.java:295) > >>>>>>>>> at java.lang.Thread.run(Thread.java:722) > >>>>>>>>> > >>>>>>>>> not sure what is the artifact org.apache.aries.blueprint is from > >>>>>>>>> > >>>>>>>>> Thanks > >>>>>>>>> > >>>>>>>>> -D > >>>>>>>>> > >>>>>>>>> On Fri, Jan 18, 2013 at 12:14 PM, Christoph Gritschenberger > >>>>>>>>> <christoph.gritschenber...@gmail.com> wrote: > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> You also need blueprint-cm in version 1.0.1-SNAPSHOT. The > >>>>>>>>>> version-range > >>>>>>>>>> for > >>>>>>>>>> blueprint-core has been increased there. That's all I had to do. > >>>>>>>>>> > >>>>>>>>>> blueprint-core-1.1.0-SNAPSHOT and blueprint-cm-1.0.1-SNAPSHOT > >>>>>>>>>> > >>>>>>>>>> kind regards, > >>>>>>>>>> christoph > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> On 2013-01-18 20:34, Dan Tran wrote: > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> I checkout the blueprint-core from trunk, which is currently at > >>>>>>>>>>> 1.1.0-SNAPSHOT, it it right? ) and build with apache-karaf > >>>>>>>>>>> 2.3.1-snapshot > >>>>>>>>>>> > >>>>>>>>>>> upon startup with karaf.bat i got the following stderr > >>>>>>>>>>> > >>>>>>>>>>> ERROR: Bundle org.apache.aries.blueprint.cm [13] Error > starting > >>>>>>>>>>> > >>>>>>>>>>> mvn:org.apache.aries.blueprint/ > org.apache.aries.blueprint.cm/1.0.0 > >>>>>>>>>>> (org.osgi.framework.BundleException: Unresolved constraint in > >>>>>>>>>>> bundle > >>>>>>>>>>> org.apache.aries.blueprint.cm [13]: Unable to resolve 13.0: > >>>>>>>>>>> missing > >>>>>>>>>>> requirement [13.0] osgi.wiring.package; > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > (&(osgi.wiring.package=org.apache.aries.blueprint)(version>=1.0.0)(!(version>=1.1.0)))) > >>>>>>>>>>> org.osgi.framework.BundleException: Unresolved constraint in > >>>>>>>>>>> bundle > >>>>>>>>>>> org.apache.aries.blueprint.cm [13]: Unable to resolve 13.0: > >>>>>>>>>>> missing > >>>>>>>>>>> requirement [13.0] osgi.wiring.package; > (&(osgi.wiring.package=o > >>>>>>>>>>> rg.apache.aries.blueprint)(version>=1.0.0)(!(version>=1.1.0))) > >>>>>>>>>>> at > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:3826) > >>>>>>>>>>> at > >>>>>>>>>>> org.apache.felix.framework.Felix.startBundle(Felix.java:1868) > >>>>>>>>>>> at > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1191) > >>>>>>>>>>> at > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLevelImpl.java:295) > >>>>>>>>>>> at java.lang.Thread.run(Thread.java:662) > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> On Fri, Jan 18, 2013 at 10:37 AM, Dan Tran <dant...@gmail.com> > >>>>>>>>>>> wrote: > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> would it be possible to have aries blueprint 1.0.2-snashot > >>>>>>>>>>>> deployed? > >>>>>>>>>>>> > >>>>>>>>>>>> apache snapshot at > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > https://repository.apache.org/content/repositories/snapshots/org/apache/aries/blueprint/org.apache.aries.blueprint.core/1.0.2-SNAPSHOT/ > >>>>>>>>>>>> is quite old > >>>>>>>>>>>> > >>>>>>>>>>>> Thanks > >>>>>>>>>>>> > >>>>>>>>>>>> -D > >>>>>>>>>>>> > >>>>>>>>>>>> On Fri, Jan 18, 2013 at 9:09 AM, Dan Tran <dant...@gmail.com> > >>>>>>>>>>>> wrote: > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> cool, I will try to build my own version of karaf 2.3.1 > >>>>>>>>>>>>> snapshot > >>>>>>>>>>>>> to > >>>>>>>>>>>>> aries 1.0.2 > >>>>>>>>>>>>> > >>>>>>>>>>>>> Thanks > >>>>>>>>>>>>> > >>>>>>>>>>>>> -Dan > >>>>>>>>>>>>> > >>>>>>>>>>>>> On Fri, Jan 18, 2013 at 12:35 AM, Guillaume Nodet > >>>>>>>>>>>>> <gno...@gmail.com> > >>>>>>>>>>>>> wrote: > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Actually, I've raised and fixed > >>>>>>>>>>>>>> https://issues.apache.org/jira/browse/ARIES-1004 > >>>>>>>>>>>>>> Can you see if the latest snapshots works better for you ? > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> On Fri, Jan 18, 2013 at 8:26 AM, Guillaume Nodet > >>>>>>>>>>>>>> <gno...@gmail.com> > >>>>>>>>>>>>>> wrote: > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> I fix a bunch of problems with blueprint shutting down > >>>>>>>>>>>>>>> recently, so > >>>>>>>>>>>>>>> could > >>>>>>>>>>>>>>> you try with a recent blueprint snapshot and see if that > >>>>>>>>>>>>>>> helps > >>>>>>>>>>>>>>> ? > >>>>>>>>>>>>>>> For now, blueprint bundles are shut down roughly according > to > >>>>>>>>>>>>>>> their > >>>>>>>>>>>>>>> start > >>>>>>>>>>>>>>> level. THere's something in blueprint which is supposed > to > >>>>>>>>>>>>>>> better > >>>>>>>>>>>>>>> use the > >>>>>>>>>>>>>>> bundle service usage and shutdown bundles so that the > problem > >>>>>>>>>>>>>>> you > >>>>>>>>>>>>>>> see > >>>>>>>>>>>>>>> would > >>>>>>>>>>>>>>> not happen, however, this only happen when the blueprint > >>>>>>>>>>>>>>> extender > >>>>>>>>>>>>>>> itself is > >>>>>>>>>>>>>>> stopped, which in fact, does not really help because the > >>>>>>>>>>>>>>> extender > >>>>>>>>>>>>>>> has > >>>>>>>>>>>>>>> a very > >>>>>>>>>>>>>>> low start level and is thus stopped very late in the > process. > >>>>>>>>>>>>>>> Something that could be improved in blueprint is reacting > to > >>>>>>>>>>>>>>> the > >>>>>>>>>>>>>>> fact > >>>>>>>>>>>>>>> that > >>>>>>>>>>>>>>> a framework shutdown is initiated and do that orderly > >>>>>>>>>>>>>>> shutdown > >>>>>>>>>>>>>>> earlier > >>>>>>>>>>>>>>> in > >>>>>>>>>>>>>>> the process. > >>>>>>>>>>>>>>> In all cases, your bundles should be able to deal with > cases > >>>>>>>>>>>>>>> where > >>>>>>>>>>>>>>> one > >>>>>>>>>>>>>>> dependency is missing and be able to shutdown cleanly > anyway. > >>>>>>>>>>>>>>> So I would suggest you try with the latest blueprint > >>>>>>>>>>>>>>> snapshots > >>>>>>>>>>>>>>> and > >>>>>>>>>>>>>>> see > >>>>>>>>>>>>>>> if > >>>>>>>>>>>>>>> it helps. I can write a patch to see if the modification i > >>>>>>>>>>>>>>> suggested > >>>>>>>>>>>>>>> above > >>>>>>>>>>>>>>> would help (I think it should) if you want to give it a > try. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> On Wed, Jan 16, 2013 at 9:31 PM, Dan Tran < > dant...@gmail.com> > >>>>>>>>>>>>>>> wrote: > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> Hi JB, > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> I only try 2.3, my new work does not work with 2.2 > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> what is osgi/karaf shutdown sequencing flow? like it > would > >>>>>>>>>>>>>>>> shutdown > >>>>>>>>>>>>>>>> all bundles with the same start- level in the order from > >>>>>>>>>>>>>>>> high > >>>>>>>>>>>>>>>> to > >>>>>>>>>>>>>>>> low > >>>>>>>>>>>>>>>> ? > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> Thanks > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> -D > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> On Wed, Jan 16, 2013 at 12:18 PM, Jean-Baptiste Onofré > >>>>>>>>>>>>>>>> <j...@nanthrax.net> > >>>>>>>>>>>>>>>> wrote: > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> Hi Dan, > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> did you try both with Karaf 2.2.x and 2.3.x ? > >>>>>>>>>>>>>>>>> did you see differences in the behavior ? > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> Regards > >>>>>>>>>>>>>>>>> JB > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> On 01/16/2013 09:17 PM, Dan Tran wrote: > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> Hi I have a service's PreDestroy method which requires a > >>>>>>>>>>>>>>>>>> service > >>>>>>>>>>>>>>>>>> from > >>>>>>>>>>>>>>>>>> other bundle during shutdown. However at shutdown time, > >>>>>>>>>>>>>>>>>> blueprint > >>>>>>>>>>>>>>>>>> make > >>>>>>>>>>>>>>>>>> the required service 'unavailable'. Using start level > >>>>>>>>>>>>>>>>>> ordering > >>>>>>>>>>>>>>>>>> does > >>>>>>>>>>>>>>>>>> not seem to help. > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> What are your experiences dealing with this issue? > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> Big thanks ahead. > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> -Dan > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> -- > >>>>>>>>>>>>>>>>> Jean-Baptiste Onofré > >>>>>>>>>>>>>>>>> jbono...@apache.org > >>>>>>>>>>>>>>>>> http://blog.nanthrax.net > >>>>>>>>>>>>>>>>> Talend - http://www.talend.com > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> -- > >>>>>>>>>>>>>>> ------------------------ > >>>>>>>>>>>>>>> Guillaume Nodet > >>>>>>>>>>>>>>> ------------------------ > >>>>>>>>>>>>>>> Blog: http://gnodet.blogspot.com/ > >>>>>>>>>>>>>>> ------------------------ > >>>>>>>>>>>>>>> FuseSource, Integration everywhere > >>>>>>>>>>>>>>> http://fusesource.com > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> -- > >>>>>>>>>>>>>> ------------------------ > >>>>>>>>>>>>>> Guillaume Nodet > >>>>>>>>>>>>>> ------------------------ > >>>>>>>>>>>>>> Blog: http://gnodet.blogspot.com/ > >>>>>>>>>>>>>> ------------------------ > >>>>>>>>>>>>>> FuseSource, Integration everywhere > >>>>>>>>>>>>>> http://fusesource.com > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>> > >>>>>>>> -- > >>>>>>>> Jean-Baptiste Onofré > >>>>>>>> jbono...@apache.org > >>>>>>>> http://blog.nanthrax.net > >>>>>>>> Talend - http://www.talend.com > >>> > >>> > >>> > >>> -- > >>> Jean-Baptiste Onofré > >>> jbono...@apache.org > >>> http://blog.nanthrax.net > >>> Talend - http://www.talend.com > > > > > > -- > > Jean-Baptiste Onofré > > jbono...@apache.org > > http://blog.nanthrax.net > > Talend - http://www.talend.com > -- ------------------------ Guillaume Nodet ------------------------ Red Hat, Open Source Integration Email: gno...@redhat.com Web: http://fusesource.com Blog: http://gnodet.blogspot.com/
