It my case, i have bundle with higher start level trying to access service from lower start level at shutdown time ( ie blueprint destroy-method ), it seems like the lower blueprint bundle service get removed early, even thou the bundle is not stopped yet.
I will create a couple of simple of bundles to reproduce this issue. Thank you for looking into this -Dan On Wed, Feb 27, 2013 at 11:30 PM, Guillaume Nodet <[email protected]> wrote: > 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 <[email protected]> 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é <[email protected]> >> 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é >> >> <[email protected]> >> >> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> >> >>>>>> wrote: >> >>>>>>> >> >>>>>>> >> >>>>>>> Thanks JB >> >>>>>>> >> >>>>>>> -D >> >>>>>>> >> >>>>>>> On Fri, Jan 18, 2013 at 2:19 PM, Jean-Baptiste Onofré >> >>>>>>> <[email protected]> >> >>>>>>> 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 >> >>>>>>>>> <[email protected]> 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 <[email protected]> >> >>>>>>>>>>> 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 <[email protected]> >> >>>>>>>>>>>> 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 >> >>>>>>>>>>>>> <[email protected]> >> >>>>>>>>>>>>> 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 >> >>>>>>>>>>>>>> <[email protected]> >> >>>>>>>>>>>>>> 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 >> >>>>>>>>>>>>>>> <[email protected]> >> >>>>>>>>>>>>>>> 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é >> >>>>>>>>>>>>>>>> <[email protected]> >> >>>>>>>>>>>>>>>> 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é >> >>>>>>>>>>>>>>>>> [email protected] >> >>>>>>>>>>>>>>>>> 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é >> >>>>>>>> [email protected] >> >>>>>>>> http://blog.nanthrax.net >> >>>>>>>> Talend - http://www.talend.com >> >>> >> >>> >> >>> >> >>> -- >> >>> Jean-Baptiste Onofré >> >>> [email protected] >> >>> http://blog.nanthrax.net >> >>> Talend - http://www.talend.com >> > >> > >> > -- >> > Jean-Baptiste Onofré >> > [email protected] >> > http://blog.nanthrax.net >> > Talend - http://www.talend.com > > > > > -- > ------------------------ > Guillaume Nodet > ------------------------ > Red Hat, Open Source Integration > > Email: [email protected] > Web: http://fusesource.com > Blog: http://gnodet.blogspot.com/ >
