safeguard: do we align it on other Microprofile impls?

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

safeguard: do we align it on other Microprofile impls?

Romain Manni-Bucau
There are several discussions about safeguard so i'd like we try to get a dedicated thread about it and see how we move forward this lib.

Personally I'd like to align it on the way other impls are done which concretely means:

1. drop failsafe
2. probably drop the API module which mainly adds builders and definition models to make it part of the implementation and stick to the spec in terms of exposed API
3. merge tck module in the implementation module
4. probably make FailsafeExecutionManager a cdi bean (we can keep it usable programmatically if needed too, this is not one or the other) to let the nested components be injected and overridable one by one instead of having to override them all
5. try to respect CDI model and not use reflections in interceptors (drop AnnotationUtil), this is likely the hardest since the spec does not enables it directly but we did with quite some success in other specs

I did a quick check and once 2 is done the effort for 1 is very doable and 3/4 are quite trivial

Wdyt?

Romain Manni-Bucau
@rmannibucau |  Blog | Old BlogGithub | LinkedIn | Book
Reply | Threaded
Open this post in threaded view
|

Re: safeguard: do we align it on other Microprofile impls?

Bruno Baptista

Hi Romain,

1. Against in the near future. Too much effort, risk and a long time to harden the code without obvious gains.

2. +1

3. why?

4. +0

5. There will be additional changes around the interceptor.

On a general note, I'm more concerned in implementing the MP-FT features than re-write the whole thing and in the end be in the same place were we started.

Cheers.




On 22/11/18 10:57, Romain Manni-Bucau wrote:
There are several discussions about safeguard so i'd like we try to get a dedicated thread about it and see how we move forward this lib.

Personally I'd like to align it on the way other impls are done which concretely means:

1. drop failsafe
2. probably drop the API module which mainly adds builders and definition models to make it part of the implementation and stick to the spec in terms of exposed API
3. merge tck module in the implementation module
4. probably make FailsafeExecutionManager a cdi bean (we can keep it usable programmatically if needed too, this is not one or the other) to let the nested components be injected and overridable one by one instead of having to override them all
5. try to respect CDI model and not use reflections in interceptors (drop AnnotationUtil), this is likely the hardest since the spec does not enables it directly but we did with quite some success in other specs

I did a quick check and once 2 is done the effort for 1 is very doable and 3/4 are quite trivial

Wdyt?

Romain Manni-Bucau
@rmannibucau |  Blog | Old BlogGithub | LinkedIn | Book
Reply | Threaded
Open this post in threaded view
|

Re: safeguard: do we align it on other Microprofile impls?

Romain Manni-Bucau



Le jeu. 22 nov. 2018 à 12:33, Bruno Baptista <[hidden email]> a écrit :

Hi Romain,

1. Against in the near future. Too much effort, risk and a long time to harden the code without obvious gains.


Why? :)

Also note that in tomee this is key to avoid issues since tomee does not want of container/app isolation (for good reasons)
Finally half of the required impl is not in the lib so it is like importing commons-lang to do placeholder handling in an app, likely overkilled.
 

2. +1

3. why?


To not install/deploy a failling module, most of the impl tests are the tck so this is a bad practise to have it tested after it is installed - and can lead to broken deployments.
 

4. +0

5. There will be additional changes around the interceptor.

On a general note, I'm more concerned in implementing the MP-FT features than re-write the whole thing and in the end be in the same place were we started.

Cheers.




On 22/11/18 10:57, Romain Manni-Bucau wrote:
There are several discussions about safeguard so i'd like we try to get a dedicated thread about it and see how we move forward this lib.

Personally I'd like to align it on the way other impls are done which concretely means:

1. drop failsafe
2. probably drop the API module which mainly adds builders and definition models to make it part of the implementation and stick to the spec in terms of exposed API
3. merge tck module in the implementation module
4. probably make FailsafeExecutionManager a cdi bean (we can keep it usable programmatically if needed too, this is not one or the other) to let the nested components be injected and overridable one by one instead of having to override them all
5. try to respect CDI model and not use reflections in interceptors (drop AnnotationUtil), this is likely the hardest since the spec does not enables it directly but we did with quite some success in other specs

I did a quick check and once 2 is done the effort for 1 is very doable and 3/4 are quite trivial

Wdyt?

Romain Manni-Bucau
@rmannibucau |  Blog | Old BlogGithub | LinkedIn | Book
Reply | Threaded
Open this post in threaded view
|

Re: safeguard: do we align it on other Microprofile impls?

Bruno Baptista

Hi Romain,

1. Because Failsafe is a battle tested library. For me it's more important to have a hardened implementation than avoid issues with container isolation. Do you have an example or a test for one of those issues?

2. The TCK are external validation tests. I prefer the current separation. I see your point of fast test feedback but, again, the tests in the implementation should be safegard tests to make the lib as good as possible and then, see if it passes the TCK.

I can live with an installed lib that doesn't pass the TCK. We only need to make sure it's working before we release.

Cheers and thanks for your interest.



On 22/11/18 13:07, Romain Manni-Bucau wrote:



Le jeu. 22 nov. 2018 à 12:33, Bruno Baptista <[hidden email]> a écrit :

Hi Romain,

1. Against in the near future. Too much effort, risk and a long time to harden the code without obvious gains.


Why? :)

Also note that in tomee this is key to avoid issues since tomee does not want of container/app isolation (for good reasons)
Finally half of the required impl is not in the lib so it is like importing commons-lang to do placeholder handling in an app, likely overkilled.
 

2. +1

3. why?


To not install/deploy a failling module, most of the impl tests are the tck so this is a bad practise to have it tested after it is installed - and can lead to broken deployments.
 

4. +0

5. There will be additional changes around the interceptor.

On a general note, I'm more concerned in implementing the MP-FT features than re-write the whole thing and in the end be in the same place were we started.

Cheers.




On 22/11/18 10:57, Romain Manni-Bucau wrote:
There are several discussions about safeguard so i'd like we try to get a dedicated thread about it and see how we move forward this lib.

Personally I'd like to align it on the way other impls are done which concretely means:

1. drop failsafe
2. probably drop the API module which mainly adds builders and definition models to make it part of the implementation and stick to the spec in terms of exposed API
3. merge tck module in the implementation module
4. probably make FailsafeExecutionManager a cdi bean (we can keep it usable programmatically if needed too, this is not one or the other) to let the nested components be injected and overridable one by one instead of having to override them all
5. try to respect CDI model and not use reflections in interceptors (drop AnnotationUtil), this is likely the hardest since the spec does not enables it directly but we did with quite some success in other specs

I did a quick check and once 2 is done the effort for 1 is very doable and 3/4 are quite trivial

Wdyt?

Romain Manni-Bucau
@rmannibucau |  Blog | Old BlogGithub | LinkedIn | Book
Reply | Threaded
Open this post in threaded view
|

Re: safeguard: do we align it on other Microprofile impls?

Romain Manni-Bucau



Le jeu. 22 nov. 2018 à 17:04, Bruno Baptista <[hidden email]> a écrit :

Hi Romain,

1. Because Failsafe is a battle tested library. For me it's more important to have a hardened implementation than avoid issues with container isolation. Do you have an example or a test for one of those issues?


Ok so let's dig this one, failsafe is not that active (since may), has a committer base close of the same magnitude than us so at the end doing it ourself or not is the same game IMHO - you would note the other MP impl don't use failsafe neither.
In terms of example you can take the old ones of tomee where we will either skip failsafe in the webapp to make us work (and break a user) or the opposite in some TCCL cases.
 

2. The TCK are external validation tests. I prefer the current separation. I see your point of fast test feedback but, again, the tests in the implementation should be safegard tests to make the lib as good as possible and then, see if it passes the TCK.


Will not fight much this one but at the end other specs respect that so in the spirit to make it uniform I still see it as having value. That said other points have way more values for end users so not something we need to discuss if we don't agree yet.
 

I can live with an installed lib that doesn't pass the TCK. We only need to make sure it's working before we release.

Cheers and thanks for your interest.



On 22/11/18 13:07, Romain Manni-Bucau wrote:



Le jeu. 22 nov. 2018 à 12:33, Bruno Baptista <[hidden email]> a écrit :

Hi Romain,

1. Against in the near future. Too much effort, risk and a long time to harden the code without obvious gains.


Why? :)

Also note that in tomee this is key to avoid issues since tomee does not want of container/app isolation (for good reasons)
Finally half of the required impl is not in the lib so it is like importing commons-lang to do placeholder handling in an app, likely overkilled.
 

2. +1

3. why?


To not install/deploy a failling module, most of the impl tests are the tck so this is a bad practise to have it tested after it is installed - and can lead to broken deployments.
 

4. +0

5. There will be additional changes around the interceptor.

On a general note, I'm more concerned in implementing the MP-FT features than re-write the whole thing and in the end be in the same place were we started.

Cheers.




On 22/11/18 10:57, Romain Manni-Bucau wrote:
There are several discussions about safeguard so i'd like we try to get a dedicated thread about it and see how we move forward this lib.

Personally I'd like to align it on the way other impls are done which concretely means:

1. drop failsafe
2. probably drop the API module which mainly adds builders and definition models to make it part of the implementation and stick to the spec in terms of exposed API
3. merge tck module in the implementation module
4. probably make FailsafeExecutionManager a cdi bean (we can keep it usable programmatically if needed too, this is not one or the other) to let the nested components be injected and overridable one by one instead of having to override them all
5. try to respect CDI model and not use reflections in interceptors (drop AnnotationUtil), this is likely the hardest since the spec does not enables it directly but we did with quite some success in other specs

I did a quick check and once 2 is done the effort for 1 is very doable and 3/4 are quite trivial

Wdyt?

Romain Manni-Bucau
@rmannibucau |  Blog | Old BlogGithub | LinkedIn | Book
Reply | Threaded
Open this post in threaded view
|

Re: safeguard: do we align it on other Microprofile impls?

Bruno Baptista
Sorry Romain,

I got lost here, without a concrete example I might not be able to
understand what you mean.

Cheers

Bruno Baptista
https://twitter.com/brunobat_


On 22/11/18 16:26, Romain Manni-Bucau wrote:
> skip failsafe in the webapp to make us work (and break a user) or the
> opposite in some TCCL cases.
Reply | Threaded
Open this post in threaded view
|

Re: safeguard: do we align it on other Microprofile impls?

Bruno Baptista
Hi All,

Can someone please release Safeguard 1.0.1?

There are changes we need released before committing the new work.

Cheers

Bruno Baptista
https://twitter.com/brunobat_


On 22/11/18 16:40, Bruno Baptista wrote:

> Sorry Romain,
>
> I got lost here, without a concrete example I might not be able to
> understand what you mean.
>
> Cheers
>
> Bruno Baptista
> https://twitter.com/brunobat_
>
>
> On 22/11/18 16:26, Romain Manni-Bucau wrote:
>> skip failsafe in the webapp to make us work (and break a user) or the
>> opposite in some TCCL cases.
Reply | Threaded
Open this post in threaded view
|

Re: safeguard: do we align it on other Microprofile impls?

Romain Manni-Bucau
In reply to this post by Romain Manni-Bucau
Hello guys,

https://gitbox.apache.org/repos/asf?p=geronimo-safeguard.git;a=shortlog;h=refs/heads/api-cdi-tck-refactoring is now ready and I'd like to move it forward and merge it as our new master. Here is the proposal

1. branch current master in 1.0.x - just to keep the code somewhere
2. merge the branch on master (1.1-SNAPSHOT would likely become 1.1.0-SNAPSHOT at the same time)

I'll be "off" next week so if we can make it this week it is awesome otherwise I can probably do it the week of the 17th and do a Xmas release with other implementations.

Let me know if there is any issue about that plan and it needs some adjustments.

Romain Manni-Bucau
@rmannibucau |  Blog | Old BlogGithub | LinkedIn | Book


Le jeu. 22 nov. 2018 à 11:57, Romain Manni-Bucau <[hidden email]> a écrit :
There are several discussions about safeguard so i'd like we try to get a dedicated thread about it and see how we move forward this lib.

Personally I'd like to align it on the way other impls are done which concretely means:

1. drop failsafe
2. probably drop the API module which mainly adds builders and definition models to make it part of the implementation and stick to the spec in terms of exposed API
3. merge tck module in the implementation module
4. probably make FailsafeExecutionManager a cdi bean (we can keep it usable programmatically if needed too, this is not one or the other) to let the nested components be injected and overridable one by one instead of having to override them all
5. try to respect CDI model and not use reflections in interceptors (drop AnnotationUtil), this is likely the hardest since the spec does not enables it directly but we did with quite some success in other specs

I did a quick check and once 2 is done the effort for 1 is very doable and 3/4 are quite trivial

Wdyt?

Romain Manni-Bucau
@rmannibucau |  Blog | Old BlogGithub | LinkedIn | Book
Reply | Threaded
Open this post in threaded view
|

Re: safeguard: do we align it on other Microprofile impls?

Mark Struberg
+1 to brew our own. Yes Bruno is right that the jodah.failsafe is obviously more battle tested. But by relying on an almost dormant external  lib we loose the ability to quickly fix bugs and add improvements ourselves.
And tbh safeguard is really not that a complex matter.

LieGrue,
Strub

Sent with autocorrect...

On 03.12.2018, at 15:24, Romain Manni-Bucau <[hidden email]> wrote:

Hello guys,

https://gitbox.apache.org/repos/asf?p=geronimo-safeguard.git;a=shortlog;h=refs/heads/api-cdi-tck-refactoring is now ready and I'd like to move it forward and merge it as our new master. Here is the proposal

1. branch current master in 1.0.x - just to keep the code somewhere
2. merge the branch on master (1.1-SNAPSHOT would likely become 1.1.0-SNAPSHOT at the same time)

I'll be "off" next week so if we can make it this week it is awesome otherwise I can probably do it the week of the 17th and do a Xmas release with other implementations.

Let me know if there is any issue about that plan and it needs some adjustments.

Romain Manni-Bucau
@rmannibucau |  Blog | Old BlogGithub | LinkedIn | Book


Le jeu. 22 nov. 2018 à 11:57, Romain Manni-Bucau <[hidden email]> a écrit :
There are several discussions about safeguard so i'd like we try to get a dedicated thread about it and see how we move forward this lib.

Personally I'd like to align it on the way other impls are done which concretely means:

1. drop failsafe
2. probably drop the API module which mainly adds builders and definition models to make it part of the implementation and stick to the spec in terms of exposed API
3. merge tck module in the implementation module
4. probably make FailsafeExecutionManager a cdi bean (we can keep it usable programmatically if needed too, this is not one or the other) to let the nested components be injected and overridable one by one instead of having to override them all
5. try to respect CDI model and not use reflections in interceptors (drop AnnotationUtil), this is likely the hardest since the spec does not enables it directly but we did with quite some success in other specs

I did a quick check and once 2 is done the effort for 1 is very doable and 3/4 are quite trivial

Wdyt?

Romain Manni-Bucau
@rmannibucau |  Blog | Old BlogGithub | LinkedIn | Book
Reply | Threaded
Open this post in threaded view
|

Re: safeguard: do we align it on other Microprofile impls?

Jean-Baptiste Onofré
In reply to this post by Romain Manni-Bucau
+1 to create our own stuff.

I would be more than happy to help on this one !

Regards
JB

On 03/12/2018 15:24, Romain Manni-Bucau wrote:

> Hello guys,
>
> https://gitbox.apache.org/repos/asf?p=geronimo-safeguard.git;a=shortlog;h=refs/heads/api-cdi-tck-refactoring
> is now ready and I'd like to move it forward and merge it as our new
> master. Here is the proposal
>
> 1. branch current master in 1.0.x - just to keep the code somewhere
> 2. merge the branch on master (1.1-SNAPSHOT would likely become
> 1.1.0-SNAPSHOT at the same time)
>
> I'll be "off" next week so if we can make it this week it is awesome
> otherwise I can probably do it the week of the 17th and do a Xmas
> release with other implementations.
>
> Let me know if there is any issue about that plan and it needs some
> adjustments.
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> <https://rmannibucau.metawerx.net/> | Old Blog
> <http://rmannibucau.wordpress.com> | Github
> <https://github.com/rmannibucau> | LinkedIn
> <https://www.linkedin.com/in/rmannibucau> | Book
> <https://www.packtpub.com/application-development/java-ee-8-high-performance>
>
>
> Le jeu. 22 nov. 2018 à 11:57, Romain Manni-Bucau <[hidden email]
> <mailto:[hidden email]>> a écrit :
>
>     There are several discussions about safeguard so i'd like we try to
>     get a dedicated thread about it and see how we move forward this lib.
>
>     Personally I'd like to align it on the way other impls are done
>     which concretely means:
>
>     1. drop failsafe
>     2. probably drop the API module which mainly adds builders and
>     definition models to make it part of the implementation and stick to
>     the spec in terms of exposed API
>     3. merge tck module in the implementation module
>     4. probably make FailsafeExecutionManager a cdi bean (we can keep it
>     usable programmatically if needed too, this is not one or the other)
>     to let the nested components be injected and overridable one by one
>     instead of having to override them all
>     5. try to respect CDI model and not use reflections in interceptors
>     (drop AnnotationUtil), this is likely the hardest since the spec
>     does not enables it directly but we did with quite some success in
>     other specs
>
>     I did a quick check and once 2 is done the effort for 1 is very
>     doable and 3/4 are quite trivial
>
>     Wdyt?
>
>     Romain Manni-Bucau
>     @rmannibucau <https://twitter.com/rmannibucau> |  Blog
>     <https://rmannibucau.metawerx.net/> | Old Blog
>     <http://rmannibucau.wordpress.com> | Github
>     <https://github.com/rmannibucau> | LinkedIn
>     <https://www.linkedin.com/in/rmannibucau> | Book
>     <https://www.packtpub.com/application-development/java-ee-8-high-performance>
>

--
Jean-Baptiste Onofré
[hidden email]
http://blog.nanthrax.net
Talend - http://www.talend.com
Reply | Threaded
Open this post in threaded view
|

Re: safeguard: do we align it on other Microprofile impls?

Romain Manni-Bucau
Will wait a few hours and plan to merge it in beginning of the afternoon on master if nobody voices against

Thanks for your feedback guys

Romain Manni-Bucau
@rmannibucau |  Blog | Old BlogGithub | LinkedIn | Book


Le mer. 5 déc. 2018 à 09:06, Jean-Baptiste Onofré <[hidden email]> a écrit :
+1 to create our own stuff.

I would be more than happy to help on this one !

Regards
JB

On 03/12/2018 15:24, Romain Manni-Bucau wrote:
> Hello guys,
>
> https://gitbox.apache.org/repos/asf?p=geronimo-safeguard.git;a=shortlog;h=refs/heads/api-cdi-tck-refactoring
> is now ready and I'd like to move it forward and merge it as our new
> master. Here is the proposal
>
> 1. branch current master in 1.0.x - just to keep the code somewhere
> 2. merge the branch on master (1.1-SNAPSHOT would likely become
> 1.1.0-SNAPSHOT at the same time)
>
> I'll be "off" next week so if we can make it this week it is awesome
> otherwise I can probably do it the week of the 17th and do a Xmas
> release with other implementations.
>
> Let me know if there is any issue about that plan and it needs some
> adjustments.
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> <https://rmannibucau.metawerx.net/> | Old Blog
> <http://rmannibucau.wordpress.com> | Github
> <https://github.com/rmannibucau> | LinkedIn
> <https://www.linkedin.com/in/rmannibucau> | Book
> <https://www.packtpub.com/application-development/java-ee-8-high-performance>
>
>
> Le jeu. 22 nov. 2018 à 11:57, Romain Manni-Bucau <[hidden email]
> <mailto:[hidden email]>> a écrit :
>
>     There are several discussions about safeguard so i'd like we try to
>     get a dedicated thread about it and see how we move forward this lib.
>
>     Personally I'd like to align it on the way other impls are done
>     which concretely means:
>
>     1. drop failsafe
>     2. probably drop the API module which mainly adds builders and
>     definition models to make it part of the implementation and stick to
>     the spec in terms of exposed API
>     3. merge tck module in the implementation module
>     4. probably make FailsafeExecutionManager a cdi bean (we can keep it
>     usable programmatically if needed too, this is not one or the other)
>     to let the nested components be injected and overridable one by one
>     instead of having to override them all
>     5. try to respect CDI model and not use reflections in interceptors
>     (drop AnnotationUtil), this is likely the hardest since the spec
>     does not enables it directly but we did with quite some success in
>     other specs
>
>     I did a quick check and once 2 is done the effort for 1 is very
>     doable and 3/4 are quite trivial
>
>     Wdyt?
>
>     Romain Manni-Bucau
>     @rmannibucau <https://twitter.com/rmannibucau> |  Blog
>     <https://rmannibucau.metawerx.net/> | Old Blog
>     <http://rmannibucau.wordpress.com> | Github
>     <https://github.com/rmannibucau> | LinkedIn
>     <https://www.linkedin.com/in/rmannibucau> | Book
>     <https://www.packtpub.com/application-development/java-ee-8-high-performance>
>

--
Jean-Baptiste Onofré
[hidden email]
http://blog.nanthrax.net
Talend - http://www.talend.com
Reply | Threaded
Open this post in threaded view
|

Re: safeguard: do we align it on other Microprofile impls?

Romain Manni-Bucau
Done, we can now continue the hacking on master

Romain Manni-Bucau
@rmannibucau |  Blog | Old BlogGithub | LinkedIn | Book


Le mer. 5 déc. 2018 à 09:23, Romain Manni-Bucau <[hidden email]> a écrit :
Will wait a few hours and plan to merge it in beginning of the afternoon on master if nobody voices against

Thanks for your feedback guys

Romain Manni-Bucau
@rmannibucau |  Blog | Old BlogGithub | LinkedIn | Book


Le mer. 5 déc. 2018 à 09:06, Jean-Baptiste Onofré <[hidden email]> a écrit :
+1 to create our own stuff.

I would be more than happy to help on this one !

Regards
JB

On 03/12/2018 15:24, Romain Manni-Bucau wrote:
> Hello guys,
>
> https://gitbox.apache.org/repos/asf?p=geronimo-safeguard.git;a=shortlog;h=refs/heads/api-cdi-tck-refactoring
> is now ready and I'd like to move it forward and merge it as our new
> master. Here is the proposal
>
> 1. branch current master in 1.0.x - just to keep the code somewhere
> 2. merge the branch on master (1.1-SNAPSHOT would likely become
> 1.1.0-SNAPSHOT at the same time)
>
> I'll be "off" next week so if we can make it this week it is awesome
> otherwise I can probably do it the week of the 17th and do a Xmas
> release with other implementations.
>
> Let me know if there is any issue about that plan and it needs some
> adjustments.
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> <https://rmannibucau.metawerx.net/> | Old Blog
> <http://rmannibucau.wordpress.com> | Github
> <https://github.com/rmannibucau> | LinkedIn
> <https://www.linkedin.com/in/rmannibucau> | Book
> <https://www.packtpub.com/application-development/java-ee-8-high-performance>
>
>
> Le jeu. 22 nov. 2018 à 11:57, Romain Manni-Bucau <[hidden email]
> <mailto:[hidden email]>> a écrit :
>
>     There are several discussions about safeguard so i'd like we try to
>     get a dedicated thread about it and see how we move forward this lib.
>
>     Personally I'd like to align it on the way other impls are done
>     which concretely means:
>
>     1. drop failsafe
>     2. probably drop the API module which mainly adds builders and
>     definition models to make it part of the implementation and stick to
>     the spec in terms of exposed API
>     3. merge tck module in the implementation module
>     4. probably make FailsafeExecutionManager a cdi bean (we can keep it
>     usable programmatically if needed too, this is not one or the other)
>     to let the nested components be injected and overridable one by one
>     instead of having to override them all
>     5. try to respect CDI model and not use reflections in interceptors
>     (drop AnnotationUtil), this is likely the hardest since the spec
>     does not enables it directly but we did with quite some success in
>     other specs
>
>     I did a quick check and once 2 is done the effort for 1 is very
>     doable and 3/4 are quite trivial
>
>     Wdyt?
>
>     Romain Manni-Bucau
>     @rmannibucau <https://twitter.com/rmannibucau> |  Blog
>     <https://rmannibucau.metawerx.net/> | Old Blog
>     <http://rmannibucau.wordpress.com> | Github
>     <https://github.com/rmannibucau> | LinkedIn
>     <https://www.linkedin.com/in/rmannibucau> | Book
>     <https://www.packtpub.com/application-development/java-ee-8-high-performance>
>

--
Jean-Baptiste Onofré
[hidden email]
http://blog.nanthrax.net
Talend - http://www.talend.com