You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@karaf.apache.org by Guillaume Nodet <gn...@apache.org> on 2016/08/25 16:44:04 UTC
[DISCUSS] Service capabilities (was: [VOTE] Apache Karaf (Container)
4.0.6 release)
You don't use any extender like DS or blueprint ?
The capabilities can be easily auto-generated for those.
You can always disable service requirements globally by setting
serviceRequirements = disable
in the etc/org.apache.karaf.features.cfg config file.
Guillaume
2016-08-25 16:17 GMT+02:00 Markus Rathgeb <ma...@gmail.com>:
> So, is there a way to use 1.3.0 (IIRC prerequisite and dependency has
> been added there) or newer without adding the capability instruction
> to every feature using a bundle without that information in the
> manifest?
> I see there is a configuration for the runtime, but is there one for
> the plugin to control the verification?
>
> I have to use a dozen of third party bundles that miss that
> information and that change frequently, adding the capability to the
> feature is a too time consuming effort.
>
> 2016-08-25 16:12 GMT+02:00 Guillaume Nodet <gn...@apache.org>:
> > Agreed, so the problem was caused by a custom feature ?
> > I thought it was directly the pax-web feature.
> >
> > In that case, I agree, that's exactly the behavior we wanted I think.
> >
> > On a side note, if pax-web does not expose the service capability, it
> > should also be fixed ;-)
> >
> > Guillaume
> >
> > 2016-08-25 15:55 GMT+02:00 Jean-Baptiste Onofré <jb...@nanthrax.net>:
> >
> >> After digging a bit, I don't think it's actually a bug.
> >>
> >> Let me explain and see we all agree ;)
> >>
> >> Previously to the commit, the service enforcement was "enabled" only for
> >> features XML using xmlns 1.3.0 (not 1.4.0). The commit fixed service
> >> enforcement also for xmlns 1.4.0 (which makes sense).
> >>
> >> In Markus' use case, he said he tried xmlns 1.2.0 and it failed.
> However,
> >> as he's using Karaf Maven plugin to generate the descriptor, by default,
> >> even if the "source" features XML contains xmlns 1.2.0, the generated
> one
> >> is using xmlns 1.4.0.
> >>
> >> That's why it worked before and not after the commit.
> >>
> >> Due to that, I don't think we have to consider it as a bug:
> >> 1. If we don't want service enforcement, than, we have to use a feature
> >> with xmlns 1.2.0
> >> 2. Actually using features xmlns 1.3.0 or 1.4.0 means we want resolver
> >> features including services enforcement.
> >>
> >> WDYT ?
> >>
> >> Regards
> >> JB
> >>
> >>
> >> On 08/25/2016 03:41 PM, Jean-Baptiste Onofré wrote:
> >>
> >>> It looks like the commit in cause is the following:
> >>>
> >>> ---------------------
> >>> 5c5828322ad898e80e66923edeb29e1a25b774cb is the first bad commit
> >>> commit 5c5828322ad898e80e66923edeb29e1a25b774cb
> >>> Author: Guillaume Nodet <gn...@apache.org>
> >>> Date: Fri Jul 22 12:33:17 2016 +0200
> >>>
> >>> [KARAF-4632] Default serviceRequirements should handle 1.4.0 schema
> >>>
> >>> :040000 040000 d038cf82d490d3cd0c7df97376575e323ef2382f
> >>> 2e6efa64dfd142e722970949b05dcc1e152a3cd8 M features
> >>> ----------------------
> >>>
> >>> I'm testing a revert.
> >>>
> >>> Regards
> >>> JB
> >>>
> >>> On 08/25/2016 11:03 AM, Jean-Baptiste Onofré wrote:
> >>>
> >>>> No, I don't think it's related as it's not a change in 4.0.6.
> >>>>
> >>>> I think it's a combination between the features resolver and the
> >>>> karaf-maven-plugin.
> >>>>
> >>>> I'm pretty close in the bisect now ;)
> >>>>
> >>>> Regards
> >>>> JB
> >>>>
> >>>> On 08/25/2016 10:46 AM, Markus Rathgeb wrote:
> >>>>
> >>>>> I found this one:
> >>>>>
> >>>>> # By default, the feature resolver checks the service
> >>>>> requirements/capabilities of
> >>>>> # bundles for new features (xml schema >= 1.3.0) in order to
> >>>>> automatically installs
> >>>>> # the required bundles.
> >>>>> # The following flag can have those values:
> >>>>> # - disable: service requirements are completely ignored
> >>>>> # - default: service requirements are ignored for old features
> >>>>> # - enforce: service requirements are always verified
> >>>>> #
> >>>>> #serviceRequirements=default
> >>>>>
> >>>>> Do you think this one could be related?
> >>>>>
> >>>>> Changing the xmlns from v1.4.0 to v1.2.0 does not result in a
> >>>>> successful verification.
> >>>>>
> >>>>> -<features xmlns="http://karaf.apache.org/xmlns/features/v1.4.0"
> >>>>> name="${project.artifactId}-${project.version}">
> >>>>> +<features xmlns="http://karaf.apache.org/xmlns/features/v1.2.0"
> >>>>> name="${project.artifactId}-${project.version}">
> >>>>>
> >>>>> 2016-08-25 10:40 GMT+02:00 Jean-Baptiste Onofré <jb...@nanthrax.net>:
> >>>>>
> >>>>>> Hi Guillaume,
> >>>>>>
> >>>>>> I'm on git biset to identify the guilty ;)
> >>>>>>
> >>>>>> And yes, I will recut a release.
> >>>>>>
> >>>>>> Regards
> >>>>>> JB
> >>>>>>
> >>>>>>
> >>>>>> On 08/25/2016 10:25 AM, Guillaume Nodet wrote:
> >>>>>>
> >>>>>>>
> >>>>>>> Yeah, if it breaks compatibility, we should recut a release ?
> >>>>>>> Has anyone identified the culprit commit yet ?
> >>>>>>>
> >>>>>>> 2016-08-25 9:39 GMT+02:00 Jean-Baptiste Onofré <jb...@nanthrax.net>:
> >>>>>>>
> >>>>>>> I think it's a change in the karaf-maven-plugin.
> >>>>>>>>
> >>>>>>>> And yes, I reproduce Markus' issue as well.
> >>>>>>>>
> >>>>>>>> Do we consider as release blocker ?
> >>>>>>>>
> >>>>>>>> If so, I will fix it today and submit a new vote.
> >>>>>>>>
> >>>>>>>> Regards
> >>>>>>>> JB
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> On 08/25/2016 09:34 AM, Achim Nierbeck wrote:
> >>>>>>>>
> >>>>>>>> Hi,
> >>>>>>>>>
> >>>>>>>>> I was able to reproduce the issue Markus described with his test.
> >>>>>>>>> One thing that crosses my mind, did we change something with the
> >>>>>>>>> feature
> >>>>>>>>> resolver? Cause I can't remember that the pax-web-api did
> actually
> >>>>>>>>> contain
> >>>>>>>>> a provide-capability for the WebContainer Service.
> >>>>>>>>>
> >>>>>>>>> regards, Achim
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> 2016-08-25 0:44 GMT+02:00 Krzysztof Sobkowiak
> >>>>>>>>> <krzys.sobkowiak@gmail.com
> >>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> :
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> +1 (non-binding)
> >>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> ServiceMix 7.x tests ok. Thanks!!!
> >>>>>>>>>>
> >>>>>>>>>> Regards
> >>>>>>>>>> Krzysztof
> >>>>>>>>>>
> >>>>>>>>>> On 24.08.2016 06:47, Jean-Baptiste Onofré wrote:
> >>>>>>>>>>
> >>>>>>>>>> Hi all,
> >>>>>>>>>>>
> >>>>>>>>>>> I submit Karaf (Container) 4.0.6 release to your vote.
> >>>>>>>>>>>
> >>>>>>>>>>> Release Notes:
> >>>>>>>>>>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?
> >>>>>>>>>>>
> >>>>>>>>>>> projectId=12311140&version=12335477
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>> Staging Repository:
> >>>>>>>>>>>
> >>>>>>>>>>> https://repository.apache.org/content/repositories/orgapache
> >>>>>>>>>>> karaf-1071/
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> Git Tag:
> >>>>>>>>>>> karaf-4.0.6
> >>>>>>>>>>>
> >>>>>>>>>>> Please vote to approve this release:
> >>>>>>>>>>>
> >>>>>>>>>>> [ ] +1 Approve the release
> >>>>>>>>>>> [ ] -1 Don't approve the release (please provide specific
> >>>>>>>>>>> comments)
> >>>>>>>>>>>
> >>>>>>>>>>> This vote will be open for at least 72 hours.
> >>>>>>>>>>>
> >>>>>>>>>>> Thanks,
> >>>>>>>>>>> Regards
> >>>>>>>>>>> JB
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>> --
> >>>>>>>>>> Krzysztof Sobkowiak (@ksobkowiak)
> >>>>>>>>>>
> >>>>>>>>>> JEE & OSS Architect, Integration Architect
> >>>>>>>>>> Apache Software Foundation Member (http://apache.org/)
> >>>>>>>>>> Apache ServiceMix Committer & PMC Member
> >>>>>>>>>> (http://servicemix.apache.org/)
> >>>>>>>>>> Senior Solution Architect @ Capgemini SSC
> >>>>>>>>>> (http://www.capgeminisoftware.
> >>>>>>>>>> pl/)
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> --
> >>>>>>>> Jean-Baptiste Onofré
> >>>>>>>> jbonofre@apache.org
> >>>>>>>> http://blog.nanthrax.net
> >>>>>>>> Talend - http://www.talend.com
> >>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>> --
> >>>>>> Jean-Baptiste Onofré
> >>>>>> jbonofre@apache.org
> >>>>>> http://blog.nanthrax.net
> >>>>>> Talend - http://www.talend.com
> >>>>>>
> >>>>>
> >>>>
> >>>
> >> --
> >> Jean-Baptiste Onofré
> >> jbonofre@apache.org
> >> http://blog.nanthrax.net
> >> Talend - http://www.talend.com
> >>
> >
> >
> >
> > --
> > ------------------------
> > Guillaume Nodet
> > ------------------------
> > Red Hat, Open Source Integration
> >
> > Email: gnodet@redhat.com
> > Web: http://fusesource.com
> > Blog: http://gnodet.blogspot.com/
>
--
------------------------
Guillaume Nodet
------------------------
Red Hat, Open Source Integration
Email: gnodet@redhat.com
Web: http://fusesource.com
Blog: http://gnodet.blogspot.com/
Re: [DISCUSS] Service capabilities (was: [VOTE] Apache Karaf
(Container) 4.0.6 release)
Posted by Markus Rathgeb <ma...@gmail.com>.
Hi,
let me give you a short summary of the background / the situation I
run into the problem:
There is an Eclipse project "Eclipse SmartHome" (ESH) that provides a
framework / a collection of bundles that could be used to create a
smarthome system (open source, commercial, whatever / doesn't matter).
The project is using (AFAIK common for Eclipse projects) the Manifest
first approach.
So, no tool that creates the manifest, but handwritten (with Eclipse
PDE support) manifests.
The OSGi version that is choosen by the project is OSGi R4.2.
There is no "Provide-Capability" used ATM and I don't think any
developer will maintain this one.
I am a committer of that project, but I don't think I am able to
change the manifest first approach.
I have created Karaf feature some time ago for the Eclipse SmartHome
project that could be consumed by products / custom distributions,
because I like Karaf and would like to support the usage of Karaf and
Eclipse SmartHome.
* https://github.com/eclipse/smarthome/blob/master/features/karaf/src/main/feature/feature.xml
* https://github.com/eclipse/smarthome/blob/master/features/karaf-tp/src/main/feature/feature.xml
As written above, the bundles are missing the Provide-Capability
entries in their manifest.
The project is under development and there are a lot of changes all the time.
The developers will not add (IMHO) this entries to the manifest.
I have no time to check every commit and add / remove / change
"Capability" nodes in the ESH Feature XML all the time.
The products that are using Karaf and the ESH features provides
bundles and features itself.
Some of that bundles are created using the maven-bundle-plugin, the
bnd-maven-plugin, Bndtools, ...
That bundles have a Require-Capability entry in their manifest.
The products create features for their bundles / functions and depend
on the Eclipse SmartHome feature.
As the ESH Karaf Features are using "dependency" attributes in their
XML they need to use >= v1.3.0.
The problem is, that the feature verification (regardless if it is
used by the karaf-maven-plugin or at runtime on feature installation)
fails with K406 but works with K405.
I already learned that it has been a bug that the feature verification
has been working using XML NS1.4.0. It fails with 1.3.0 only but
should fail with >= 1.3.0.
So, it has been working, but it shouldn't. I understand....
> <feature name="foo" serviceRequirements="disable|default|enforce" ...>
That is something I already posted as an idea today on IRC.
Perhaps that would be possible.
I hope you understand the situation I want to describe above.
Have you some tips how what we could do?
I assume the best solution would be if the ESH bundles' manifest have
an "Provide-Capability" entry.
I assume the next best solution would be if the ESH features have an
"Capability" entry.
But what could be done if that "third party" stuff will not be changed?
I don't like to remove the ESH Karaf features from the ESH repo and
drop the support of Karaf features completely.
But I cannot maintain the features and bundles for all the other
developers and I am pretty sure the project will not add this stuff to
their guidelines.
Any tips and help is welcome.
Best regards and thanks for your time,
Markus Rathgeb
Re: [DISCUSS] Service capabilities (was: [VOTE] Apache Karaf
(Container) 4.0.6 release)
Posted by Guillaume Nodet <gn...@apache.org>.
And btw, given the code to remove service requirements is already present,
we could go a bit more fine grained and add a flag on the feature xml
element to disable/enforce service requirements :
<feature name="foo" serviceRequirements="disable|default|enforce" ...>
That should be fairly easy to do in a 1.5 schema for Karaf 4.1 imho.
2016-08-25 18:44 GMT+02:00 Guillaume Nodet <gn...@apache.org>:
> You don't use any extender like DS or blueprint ?
> The capabilities can be easily auto-generated for those.
>
> You can always disable service requirements globally by setting
> serviceRequirements = disable
> in the etc/org.apache.karaf.features.cfg config file.
>
> Guillaume
>
> 2016-08-25 16:17 GMT+02:00 Markus Rathgeb <ma...@gmail.com>:
>
>> So, is there a way to use 1.3.0 (IIRC prerequisite and dependency has
>> been added there) or newer without adding the capability instruction
>> to every feature using a bundle without that information in the
>> manifest?
>> I see there is a configuration for the runtime, but is there one for
>> the plugin to control the verification?
>>
>> I have to use a dozen of third party bundles that miss that
>> information and that change frequently, adding the capability to the
>> feature is a too time consuming effort.
>>
>> 2016-08-25 16:12 GMT+02:00 Guillaume Nodet <gn...@apache.org>:
>> > Agreed, so the problem was caused by a custom feature ?
>> > I thought it was directly the pax-web feature.
>> >
>> > In that case, I agree, that's exactly the behavior we wanted I think.
>> >
>> > On a side note, if pax-web does not expose the service capability, it
>> > should also be fixed ;-)
>> >
>> > Guillaume
>> >
>> > 2016-08-25 15:55 GMT+02:00 Jean-Baptiste Onofré <jb...@nanthrax.net>:
>> >
>> >> After digging a bit, I don't think it's actually a bug.
>> >>
>> >> Let me explain and see we all agree ;)
>> >>
>> >> Previously to the commit, the service enforcement was "enabled" only
>> for
>> >> features XML using xmlns 1.3.0 (not 1.4.0). The commit fixed service
>> >> enforcement also for xmlns 1.4.0 (which makes sense).
>> >>
>> >> In Markus' use case, he said he tried xmlns 1.2.0 and it failed.
>> However,
>> >> as he's using Karaf Maven plugin to generate the descriptor, by
>> default,
>> >> even if the "source" features XML contains xmlns 1.2.0, the generated
>> one
>> >> is using xmlns 1.4.0.
>> >>
>> >> That's why it worked before and not after the commit.
>> >>
>> >> Due to that, I don't think we have to consider it as a bug:
>> >> 1. If we don't want service enforcement, than, we have to use a feature
>> >> with xmlns 1.2.0
>> >> 2. Actually using features xmlns 1.3.0 or 1.4.0 means we want resolver
>> >> features including services enforcement.
>> >>
>> >> WDYT ?
>> >>
>> >> Regards
>> >> JB
>> >>
>> >>
>> >> On 08/25/2016 03:41 PM, Jean-Baptiste Onofré wrote:
>> >>
>> >>> It looks like the commit in cause is the following:
>> >>>
>> >>> ---------------------
>> >>> 5c5828322ad898e80e66923edeb29e1a25b774cb is the first bad commit
>> >>> commit 5c5828322ad898e80e66923edeb29e1a25b774cb
>> >>> Author: Guillaume Nodet <gn...@apache.org>
>> >>> Date: Fri Jul 22 12:33:17 2016 +0200
>> >>>
>> >>> [KARAF-4632] Default serviceRequirements should handle 1.4.0
>> schema
>> >>>
>> >>> :040000 040000 d038cf82d490d3cd0c7df97376575e323ef2382f
>> >>> 2e6efa64dfd142e722970949b05dcc1e152a3cd8 M features
>> >>> ----------------------
>> >>>
>> >>> I'm testing a revert.
>> >>>
>> >>> Regards
>> >>> JB
>> >>>
>> >>> On 08/25/2016 11:03 AM, Jean-Baptiste Onofré wrote:
>> >>>
>> >>>> No, I don't think it's related as it's not a change in 4.0.6.
>> >>>>
>> >>>> I think it's a combination between the features resolver and the
>> >>>> karaf-maven-plugin.
>> >>>>
>> >>>> I'm pretty close in the bisect now ;)
>> >>>>
>> >>>> Regards
>> >>>> JB
>> >>>>
>> >>>> On 08/25/2016 10:46 AM, Markus Rathgeb wrote:
>> >>>>
>> >>>>> I found this one:
>> >>>>>
>> >>>>> # By default, the feature resolver checks the service
>> >>>>> requirements/capabilities of
>> >>>>> # bundles for new features (xml schema >= 1.3.0) in order to
>> >>>>> automatically installs
>> >>>>> # the required bundles.
>> >>>>> # The following flag can have those values:
>> >>>>> # - disable: service requirements are completely ignored
>> >>>>> # - default: service requirements are ignored for old features
>> >>>>> # - enforce: service requirements are always verified
>> >>>>> #
>> >>>>> #serviceRequirements=default
>> >>>>>
>> >>>>> Do you think this one could be related?
>> >>>>>
>> >>>>> Changing the xmlns from v1.4.0 to v1.2.0 does not result in a
>> >>>>> successful verification.
>> >>>>>
>> >>>>> -<features xmlns="http://karaf.apache.org/xmlns/features/v1.4.0"
>> >>>>> name="${project.artifactId}-${project.version}">
>> >>>>> +<features xmlns="http://karaf.apache.org/xmlns/features/v1.2.0"
>> >>>>> name="${project.artifactId}-${project.version}">
>> >>>>>
>> >>>>> 2016-08-25 10:40 GMT+02:00 Jean-Baptiste Onofré <jb...@nanthrax.net>:
>> >>>>>
>> >>>>>> Hi Guillaume,
>> >>>>>>
>> >>>>>> I'm on git biset to identify the guilty ;)
>> >>>>>>
>> >>>>>> And yes, I will recut a release.
>> >>>>>>
>> >>>>>> Regards
>> >>>>>> JB
>> >>>>>>
>> >>>>>>
>> >>>>>> On 08/25/2016 10:25 AM, Guillaume Nodet wrote:
>> >>>>>>
>> >>>>>>>
>> >>>>>>> Yeah, if it breaks compatibility, we should recut a release ?
>> >>>>>>> Has anyone identified the culprit commit yet ?
>> >>>>>>>
>> >>>>>>> 2016-08-25 9:39 GMT+02:00 Jean-Baptiste Onofré <jb...@nanthrax.net>:
>> >>>>>>>
>> >>>>>>> I think it's a change in the karaf-maven-plugin.
>> >>>>>>>>
>> >>>>>>>> And yes, I reproduce Markus' issue as well.
>> >>>>>>>>
>> >>>>>>>> Do we consider as release blocker ?
>> >>>>>>>>
>> >>>>>>>> If so, I will fix it today and submit a new vote.
>> >>>>>>>>
>> >>>>>>>> Regards
>> >>>>>>>> JB
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>> On 08/25/2016 09:34 AM, Achim Nierbeck wrote:
>> >>>>>>>>
>> >>>>>>>> Hi,
>> >>>>>>>>>
>> >>>>>>>>> I was able to reproduce the issue Markus described with his
>> test.
>> >>>>>>>>> One thing that crosses my mind, did we change something with the
>> >>>>>>>>> feature
>> >>>>>>>>> resolver? Cause I can't remember that the pax-web-api did
>> actually
>> >>>>>>>>> contain
>> >>>>>>>>> a provide-capability for the WebContainer Service.
>> >>>>>>>>>
>> >>>>>>>>> regards, Achim
>> >>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>> 2016-08-25 0:44 GMT+02:00 Krzysztof Sobkowiak
>> >>>>>>>>> <krzys.sobkowiak@gmail.com
>> >>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>> :
>> >>>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>> +1 (non-binding)
>> >>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>> ServiceMix 7.x tests ok. Thanks!!!
>> >>>>>>>>>>
>> >>>>>>>>>> Regards
>> >>>>>>>>>> Krzysztof
>> >>>>>>>>>>
>> >>>>>>>>>> On 24.08.2016 06:47, Jean-Baptiste Onofré wrote:
>> >>>>>>>>>>
>> >>>>>>>>>> Hi all,
>> >>>>>>>>>>>
>> >>>>>>>>>>> I submit Karaf (Container) 4.0.6 release to your vote.
>> >>>>>>>>>>>
>> >>>>>>>>>>> Release Notes:
>> >>>>>>>>>>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?
>> >>>>>>>>>>>
>> >>>>>>>>>>> projectId=12311140&version=12335477
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>>> Staging Repository:
>> >>>>>>>>>>>
>> >>>>>>>>>>> https://repository.apache.org/content/repositories/orgapache
>> >>>>>>>>>>> karaf-1071/
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>> Git Tag:
>> >>>>>>>>>>> karaf-4.0.6
>> >>>>>>>>>>>
>> >>>>>>>>>>> Please vote to approve this release:
>> >>>>>>>>>>>
>> >>>>>>>>>>> [ ] +1 Approve the release
>> >>>>>>>>>>> [ ] -1 Don't approve the release (please provide specific
>> >>>>>>>>>>> comments)
>> >>>>>>>>>>>
>> >>>>>>>>>>> This vote will be open for at least 72 hours.
>> >>>>>>>>>>>
>> >>>>>>>>>>> Thanks,
>> >>>>>>>>>>> Regards
>> >>>>>>>>>>> JB
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>> --
>> >>>>>>>>>> Krzysztof Sobkowiak (@ksobkowiak)
>> >>>>>>>>>>
>> >>>>>>>>>> JEE & OSS Architect, Integration Architect
>> >>>>>>>>>> Apache Software Foundation Member (http://apache.org/)
>> >>>>>>>>>> Apache ServiceMix Committer & PMC Member
>> >>>>>>>>>> (http://servicemix.apache.org/)
>> >>>>>>>>>> Senior Solution Architect @ Capgemini SSC
>> >>>>>>>>>> (http://www.capgeminisoftware.
>> >>>>>>>>>> pl/)
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>> --
>> >>>>>>>> Jean-Baptiste Onofré
>> >>>>>>>> jbonofre@apache.org
>> >>>>>>>> http://blog.nanthrax.net
>> >>>>>>>> Talend - http://www.talend.com
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>
>> >>>>>> --
>> >>>>>> Jean-Baptiste Onofré
>> >>>>>> jbonofre@apache.org
>> >>>>>> http://blog.nanthrax.net
>> >>>>>> Talend - http://www.talend.com
>> >>>>>>
>> >>>>>
>> >>>>
>> >>>
>> >> --
>> >> Jean-Baptiste Onofré
>> >> jbonofre@apache.org
>> >> http://blog.nanthrax.net
>> >> Talend - http://www.talend.com
>> >>
>> >
>> >
>> >
>> > --
>> > ------------------------
>> > Guillaume Nodet
>> > ------------------------
>> > Red Hat, Open Source Integration
>> >
>> > Email: gnodet@redhat.com
>> > Web: http://fusesource.com
>> > Blog: http://gnodet.blogspot.com/
>>
>
>
>
> --
> ------------------------
> Guillaume Nodet
> ------------------------
> Red Hat, Open Source Integration
>
> Email: gnodet@redhat.com
> Web: http://fusesource.com
> Blog: http://gnodet.blogspot.com/
>
>
--
------------------------
Guillaume Nodet
------------------------
Red Hat, Open Source Integration
Email: gnodet@redhat.com
Web: http://fusesource.com
Blog: http://gnodet.blogspot.com/