You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Romain Manni-Bucau <rm...@gmail.com> on 2022/04/01 06:27:33 UTC
Re: TomEE MicroProfile and Jakarta
The risk for TomEE (IMHO indeed) is that, using smallrye, you break the
core value "apache" or at least "owned by apache" and break the other core
value "lightweight" since it comes with a tons of uneeded stuff and
implementation is not even JAXRS friendly (it breaks literally jaxrs and
cdi at multiple levels) so it can mean contributing to smallrye which means
at the end asking mircoprofile to not be a spec but just an implementation
and TomEE to stick to a dedicated MP distro (not in all others) to not kill
itself - not saying it does not makes sense but it is what it means
concretely.
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. 31 mars 2022 à 21:36, David Blevins <da...@gmail.com> a
écrit :
> It would be great to see us have compliant MicroProfile implementations
> somewhere in Apache; Geronimo, TomEE, CXF. It's still my personal
> preference -- It makes very little sense to go through the effort to
> create a spec and tck to enable multiple implementations that can
> compete/innovate and then wind up with just one implementation in the
> industry.
>
> That said, from a TomEE perspective we're struggling to keep up with all
> specs, Jakarta EE and MicroProfile. Part of that is we do try to uniquely
> implement specs, while everyone else just uses the exact same
> implementation. We're not really playing the same game. We would need
> more resources than the competition to compete in the way we have been
> attempting. However, because we're behind, we end up with fewer resources
> and larger gaps between implementations and over time our goals becomes
> harder, not easier.
>
> I wonder if we should switch to the SmallRye implementations where
> needed. Not because we've given up hope of having Apache implementations,
> but because if we assume our desire to do the implementation work here is a
> constant and we know the time to get there will some number of months and
> that will likely be after complete our Jakarta EE spec work, which is also
> some number of months... we're basically talking sometime 2023. The
> question then becomes, how do we want to spend our time till then? Do we
> want to spend it in a compliant state or a non-compliant state?
>
> If we spend the next year and change in a compliant state, using the
> SmallRye impls where needed until we've created compliant Apache versions,
> then we are competitive and will gain resources. The date on which we
> would have resources to create those Apache implementations would likely be
> sooner. If we spend the next year and change still not in a compliant
> state (as we've been since 2020), then we'l continue to take a resource hit
> and the date on which we would have resources to create those Apache
> implementations would likely be later. There are also other risks with
> this approach.
>
> So though it may seem backwards my gut says, unless we get a dramatic
> influx of resources from nowhere, we should use SmallRye where we need
> until we have the time to dedicate to the Apache implementations.
>
>
> -David
>
>
> > On Mar 31, 2022, at 12:44 AM, Jean-Louis Monteiro <
> jlmonteiro@tomitribe.com> wrote:
> >
> > Hi,
> >
> > Small update regarding jakarta namespace switch and MicroProfile. Adding
> > Geronimo dev@list because we are using most of the Geronimo
> implementations
> >
> > In order to migrate, we have created a shaded version of all MicroProfile
> > APIs to relocate all javax to jakarta. It worked but it's causing some
> > issues with TCK. They are not relocated so of course, all TCK are
> failing.
> >
> > I wanted to see how far we are regarding our implementations, so I went
> > ahead and updated all TCK to the latest version (and compatible with the
> > Jakarta namespace).
> >
> > The other option would be to grab all the TCK and create their equivalent
> > in jakarta namespace using the same approach as for the APIs.
> >
> > What are your thoughts?
> >
> > --
> > Jean-Louis Monteiro
> > http://twitter.com/jlouismonteiro
> > http://www.tomitribe.com
>
>
Re: TomEE MicroProfile and Jakarta
Posted by David Blevins <da...@gmail.com>.
Thank you for all the work you're doing on this, Jean-Louis!
> On Apr 15, 2022, at 4:09 AM, Jean-Louis Monteiro <jl...@tomitribe.com> wrote:
>
> Unfortunately, SmallRye isn't like Geronimo so adding the libraries does
> not make anything happen. We were failing in all specifications. It's just
> a base set of libraries you can rely on, but ultimately, you need to write
> some integration code.
Anecdotally, I've suspected that the MicroProfile stuff we added that primarily used CDI Extensions to do integration caused our startup time to increase. A few years ago I did an analysis of our cold start from a testing perspective. i.e. how long does it take to pack and start a TomEE server as Arquillian does.
Here's that full email, but the most interesting graph is the second link:
- https://lists.apache.org/thread/bg8v05lksfwskxkm0y8zdg0yn17mwsfc
- https://issues.apache.org/jira/secure/attachment/12969800/startup-times.png
What I note on that is the TomE 7.0.x binaries are towards the top of the list in good performance and there is a strong trend to slower performance as we get into 8.0 and some in 7.1. Here are just the 7 and 8 startup times:
- https://gist.githubusercontent.com/dblevins/5ed7ce26e480f34db3ea3b6fc818eb3e/raw/d86824f28ae10f86ae5d898f457ddcfa4c7814e1/startup-times-7-and-8.txt
>
> Did most of the integration for Config, Metrics, Health, JWT and
> Rest-Client. Haven't started Fault-Tolerance and OpenAPI.
>
> - Config: we have 3 failures to look at. It might need some more code to
> address edge cases.
> - JWT: 22 failures and 12 not executed. Mainly a key issue.
> - Metrics: all green, yeah
> - Health: a few failures I'm working on now
> - Rest Client: half failing or maybe more - tck setup or missing bits to
> start with
> - OpenAPI, Fault-tolerance: all failing or almost - no TCK setup or
> integration code
>
> I'd appreciate some help as I feel like I'm not seeing the end of the
> tunnel lol
It'll likely be 2 weeks before I can dig in, but the place I'd probably dive in first would be the JWT tests as I know that spec and worked on our impl.
-David
Re: Key parsing in MP JWT code (Re: TomEE MicroProfile and Jakarta)
Posted by David Blevins <da...@gmail.com>.
> On Apr 15, 2022, at 2:25 PM, David Blevins <da...@gmail.com> wrote:
>
>> On Apr 15, 2022, at 1:10 PM, Jean-Louis Monteiro <jl...@tomitribe.com> wrote:
>>
>> David, yes I figured you'd want to work on JWT. I looked and it seems our
>> setup needs some love. Some additional tests with EC based algorithms and a
>> couple of other endpoints need to be updated.
>
> On the note of EC keys, I wonder what people think about potentially using this key parsing library I wrote:
>
> - https://github.com/tomitribe/churchkey
>
> It does parse EC keys in several different formats, supports 100+ curves and has 1450 unit tests. If you have a public or private key in a handful of PEM formats, OpenSSH format, SSH2 format, JWT format or plain binary DIR format it will parse the key.
>
> The very significant con is that it would be the first time we adding a library from that org to our server. It's something I've deliberately avoided. I've always preferred to keep lines clean. I'm not sure how I feel about adding such a dependency and potentially opening a can of worms.
>
> I'd like to hear some thoughts from others. Perhaps I'm being overly cautious.
I thought about this for a few weeks and came to the conclusion I'm not being overly cautious. I don't think we want corporate names of any kind being imported in our source or visible in our Maven dependencies of the server itself. Tools are ok, but the actual thing people are downloading and putting in production.
My first thought was to fork it all over, but that would create a maintenance headache. I checked and there was a good domain name available so I repackaged all the code and maven groupId to the following completely neutral names:
package: io.churchkey
groupId: io.churchkey
It's already been released and is in Maven Central. Our key parsing will get a serious upgrade shortly.
-David
Key parsing in MP JWT code (Re: TomEE MicroProfile and Jakarta)
Posted by David Blevins <da...@gmail.com>.
> On Apr 15, 2022, at 1:10 PM, Jean-Louis Monteiro <jl...@tomitribe.com> wrote:
>
> David, yes I figured you'd want to work on JWT. I looked and it seems our
> setup needs some love. Some additional tests with EC based algorithms and a
> couple of other endpoints need to be updated.
On the note of EC keys, I wonder what people think about potentially using this key parsing library I wrote:
- https://github.com/tomitribe/churchkey
It does parse EC keys in several different formats, supports 100+ curves and has 1450 unit tests. If you have a public or private key in a handful of PEM formats, OpenSSH format, SSH2 format, JWT format or plain binary DIR format it will parse the key.
The very significant con is that it would be the first time we adding a library from that org to our server. It's something I've deliberately avoided. I've always preferred to keep lines clean. I'm not sure how I feel about adding such a dependency and potentially opening a can of worms.
I'd like to hear some thoughts from others. Perhaps I'm being overly cautious.
-David
Re: TomEE MicroProfile and Jakarta
Posted by Jean-Louis Monteiro <jl...@tomitribe.com>.
Thanks guys.
Some days are more productive than others. Today I was able to get a green
TCK run for health and just pushed also for Rest Client. We should also be
compliant in the 2.
Integration code probably needs to be hardened but good start if we are
green on Metrics, Health and Rest Client. Only 3 failures on Config.
David, yes I figured you'd want to work on JWT. I looked and it seems our
setup needs some love. Some additional tests with EC based algorithms and a
couple of other endpoints need to be updated.
Side note, I removed TCK for Fault Tolerance and OpenAPI. The first one
does have a lot of timeout and therefore get the build to last way longer
than needed. Until we work on them and we get the rest to be stable and
green, at least we get faster results.
--
Jean-Louis Monteiro
http://twitter.com/jlouismonteiro
http://www.tomitribe.com
On Fri, Apr 15, 2022 at 9:11 PM David Blevins <da...@gmail.com>
wrote:
> > On Apr 15, 2022, at 8:08 AM, Daniel Cunha <da...@apache.org> wrote:
> >
> > if I understood correctly, we are working to provide TomEE with SmallRye
> implementation. Have you shared some branches? Where is the code that you
> are working on? Not sure if I can help too much, but I could spend some
> time and put my eyes on it as well.
>
> That's great, Dani!
>
> It looks like it's all in the master branch as of today.
>
>
> -David
>
> >
> > Em sex., 15 de abr. de 2022 às 08:09, Jean-Louis Monteiro <
> jlmonteiro@tomitribe.com> escreveu:
> > Hi,
> >
> > Following our discussion I went ahead and did the following
> > - yank all Geronimo MicroProfile implementations until we can update them
> > - update MicroProfile APIs to their latest and jakarta compatible
> versions
> > - add SmallRye implementations for Config, Fault-Tolerance, OpenAPI,
> OpenTracing, Health and Metrics.
> > - Kept our JWT microprofile implementation
> > - Used CXF shaded and relocated version of the Rest Client
> >
> > Now, where are we?
> > Doing all that worked but does not make TomEE to now be MicroProfile
> compliant.
> > I went ahead and also updated all TCK to use the latest TCK and jakarta
> compatible version of MicroProfile.
> >
> > Unfortunately, SmallRye isn't like Geronimo so adding the libraries does
> not make anything happen. We were failing in all specifications. It's just
> a base set of libraries you can rely on, but ultimately, you need to write
> some integration code.
> >
> > Did most of the integration for Config, Metrics, Health, JWT and
> Rest-Client. Haven't started Fault-Tolerance and OpenAPI.
> >
> > - Config: we have 3 failures to look at. It might need some more code to
> address edge cases.
> > - JWT: 22 failures and 12 not executed. Mainly a key issue.
> > - Metrics: all green, yeah
> > - Health: a few failures I'm working on now
> > - Rest Client: half failing or maybe more - tck setup or missing bits to
> start with
> > - OpenAPI, Fault-tolerance: all failing or almost - no TCK setup or
> integration code
> >
> > I'd appreciate some help as I feel like I'm not seeing the end of the
> tunnel lol
> >
> > Hope it helps
> >
> >
> >
> >
> >
> >
> >
> > --
> > Jean-Louis Monteiro
> > http://twitter.com/jlouismonteiro
> > http://www.tomitribe.com
> >
> >
> > On Sat, Apr 2, 2022 at 11:13 AM Jean-Louis Monteiro <
> jlmonteiro@tomitribe.com> wrote:
> > Great discussion. Thanks everyone.
> >
> > I'll look at Sallrye over the weekend and see how hard it is to replace
> our Apache libraries.
> >
> > --
> > Jean-Louis Monteiro
> > http://twitter.com/jlouismonteiro
> > http://www.tomitribe.com
> >
> >
> > On Fri, Apr 1, 2022 at 12:48 PM David Blevins <db...@tomitribe.com>
> wrote:
> > This is very close. The dangers of A are not quite captured.
> Completely agree with the dangers of B.
> >
> > > On Apr 1, 2022, at 1:13 AM, Zowalla, Richard <
> richard.zowalla@hs-heilbronn.de> wrote:
> > >
> > > So we basically have to options (if I understand the discussion
> > > correctly):
> > >
> > > (A) Put some effort / resources into upgrade our MP impls to the latest
> > > versions to fully support Jakarta namespace. From my understanding
> > > maintaining these impls is a bit PITA as MP tends to break its API
> > > every few months, right? It will take some time, effort and resources
> > > to catch up.
> >
> > The danger here is that we - due to lack of time / resources - will
> continue to not be seen as a viable MicroProfile implementation.
> >
> > MicroProfile is approximately 70 months old. We were able to keep up
> for only 1.5 months out of that 70. It was with TomEE 7.1, released with
> MicroProfile 2.0 support in September of 2018, outdated by MicroProfile 2.1
> in October 2018. We were 27 months late to getting our first and only
> MicroProfile version implemented, which is now 41 months out of date.
> >
> > >
> > > (B) Use existing MP impls to make "fast" progress on the TomEE 9.x
> > > side, which breaks the "we use apache impls"-credo but enables a faster
> > > move forward. I see the danger here that we - due to lack of time /
> > > resources - will not find the way back to our own Apache
> > > implementations and will stick with smallrye for a long (?) time
> > > perhaps.
> >
> > Correct. And as mentioned, not finding our way back to our own Apache
> implementations has already been the status quo.
> >
> > > People are eager to use EE9 / Jakarta namespace and TomEE isn't really
> > > ready for it, yet. With the latest M7 version, users cannot start new
> > > projects as testing possibilities are super limited.
> > >
> > > Btw.: I am unsure, if we are still using Hibernate Validation in the
> > > current TomEE 9-M8 Snapshot. But if we do, we already broke the
> > > "everything from apache"-credo for the sake of getting the
> > > certifaction.
> >
> > Our certified distribution (Plume) used EclipseLink instead of OpenJPA,
> Mojarra instead of MyFaces and Hibernate Bean Validation instead of BVal.
> >
> >
> > -David
> >
> >
> >
> > --
> > Daniel Cunha
> > https://github.com/danielsoro
> > https://twitter.com/danielvlcunha
> > https://www.linkedin.com/in/danielvlcunha/
>
>
Re: TomEE MicroProfile and Jakarta
Posted by David Blevins <da...@gmail.com>.
> On Apr 15, 2022, at 8:08 AM, Daniel Cunha <da...@apache.org> wrote:
>
> if I understood correctly, we are working to provide TomEE with SmallRye implementation. Have you shared some branches? Where is the code that you are working on? Not sure if I can help too much, but I could spend some time and put my eyes on it as well.
That's great, Dani!
It looks like it's all in the master branch as of today.
-David
>
> Em sex., 15 de abr. de 2022 às 08:09, Jean-Louis Monteiro <jl...@tomitribe.com> escreveu:
> Hi,
>
> Following our discussion I went ahead and did the following
> - yank all Geronimo MicroProfile implementations until we can update them
> - update MicroProfile APIs to their latest and jakarta compatible versions
> - add SmallRye implementations for Config, Fault-Tolerance, OpenAPI, OpenTracing, Health and Metrics.
> - Kept our JWT microprofile implementation
> - Used CXF shaded and relocated version of the Rest Client
>
> Now, where are we?
> Doing all that worked but does not make TomEE to now be MicroProfile compliant.
> I went ahead and also updated all TCK to use the latest TCK and jakarta compatible version of MicroProfile.
>
> Unfortunately, SmallRye isn't like Geronimo so adding the libraries does not make anything happen. We were failing in all specifications. It's just a base set of libraries you can rely on, but ultimately, you need to write some integration code.
>
> Did most of the integration for Config, Metrics, Health, JWT and Rest-Client. Haven't started Fault-Tolerance and OpenAPI.
>
> - Config: we have 3 failures to look at. It might need some more code to address edge cases.
> - JWT: 22 failures and 12 not executed. Mainly a key issue.
> - Metrics: all green, yeah
> - Health: a few failures I'm working on now
> - Rest Client: half failing or maybe more - tck setup or missing bits to start with
> - OpenAPI, Fault-tolerance: all failing or almost - no TCK setup or integration code
>
> I'd appreciate some help as I feel like I'm not seeing the end of the tunnel lol
>
> Hope it helps
>
>
>
>
>
>
>
> --
> Jean-Louis Monteiro
> http://twitter.com/jlouismonteiro
> http://www.tomitribe.com
>
>
> On Sat, Apr 2, 2022 at 11:13 AM Jean-Louis Monteiro <jl...@tomitribe.com> wrote:
> Great discussion. Thanks everyone.
>
> I'll look at Sallrye over the weekend and see how hard it is to replace our Apache libraries.
>
> --
> Jean-Louis Monteiro
> http://twitter.com/jlouismonteiro
> http://www.tomitribe.com
>
>
> On Fri, Apr 1, 2022 at 12:48 PM David Blevins <db...@tomitribe.com> wrote:
> This is very close. The dangers of A are not quite captured. Completely agree with the dangers of B.
>
> > On Apr 1, 2022, at 1:13 AM, Zowalla, Richard <ri...@hs-heilbronn.de> wrote:
> >
> > So we basically have to options (if I understand the discussion
> > correctly):
> >
> > (A) Put some effort / resources into upgrade our MP impls to the latest
> > versions to fully support Jakarta namespace. From my understanding
> > maintaining these impls is a bit PITA as MP tends to break its API
> > every few months, right? It will take some time, effort and resources
> > to catch up.
>
> The danger here is that we - due to lack of time / resources - will continue to not be seen as a viable MicroProfile implementation.
>
> MicroProfile is approximately 70 months old. We were able to keep up for only 1.5 months out of that 70. It was with TomEE 7.1, released with MicroProfile 2.0 support in September of 2018, outdated by MicroProfile 2.1 in October 2018. We were 27 months late to getting our first and only MicroProfile version implemented, which is now 41 months out of date.
>
> >
> > (B) Use existing MP impls to make "fast" progress on the TomEE 9.x
> > side, which breaks the "we use apache impls"-credo but enables a faster
> > move forward. I see the danger here that we - due to lack of time /
> > resources - will not find the way back to our own Apache
> > implementations and will stick with smallrye for a long (?) time
> > perhaps.
>
> Correct. And as mentioned, not finding our way back to our own Apache implementations has already been the status quo.
>
> > People are eager to use EE9 / Jakarta namespace and TomEE isn't really
> > ready for it, yet. With the latest M7 version, users cannot start new
> > projects as testing possibilities are super limited.
> >
> > Btw.: I am unsure, if we are still using Hibernate Validation in the
> > current TomEE 9-M8 Snapshot. But if we do, we already broke the
> > "everything from apache"-credo for the sake of getting the
> > certifaction.
>
> Our certified distribution (Plume) used EclipseLink instead of OpenJPA, Mojarra instead of MyFaces and Hibernate Bean Validation instead of BVal.
>
>
> -David
>
>
>
> --
> Daniel Cunha
> https://github.com/danielsoro
> https://twitter.com/danielvlcunha
> https://www.linkedin.com/in/danielvlcunha/
Re: TomEE MicroProfile and Jakarta
Posted by Daniel Cunha <da...@apache.org>.
Hey Jean-Louis,
if I understood correctly, we are working to provide TomEE with SmallRye
implementation. Have you shared some branches? Where is the code that you
are working on? Not sure if I can help too much, but I could spend some
time and put my eyes on it as well.
Thank you!
Em sex., 15 de abr. de 2022 às 08:09, Jean-Louis Monteiro <
jlmonteiro@tomitribe.com> escreveu:
> Hi,
>
> Following our discussion I went ahead and did the following
> - yank all Geronimo MicroProfile implementations until we can update them
> - update MicroProfile APIs to their latest and jakarta compatible versions
> - add SmallRye implementations for Config, Fault-Tolerance, OpenAPI,
> OpenTracing, Health and Metrics.
> - Kept our JWT microprofile implementation
> - Used CXF shaded and relocated version of the Rest Client
>
> Now, where are we?
> Doing all that worked but does not make TomEE to now be MicroProfile
> compliant.
> I went ahead and also updated all TCK to use the latest TCK and jakarta
> compatible version of MicroProfile.
>
> Unfortunately, SmallRye isn't like Geronimo so adding the libraries does
> not make anything happen. We were failing in all specifications. It's just
> a base set of libraries you can rely on, but ultimately, you need to write
> some integration code.
>
> Did most of the integration for Config, Metrics, Health, JWT and
> Rest-Client. Haven't started Fault-Tolerance and OpenAPI.
>
> - Config: we have 3 failures to look at. It might need some more code to
> address edge cases.
> - JWT: 22 failures and 12 not executed. Mainly a key issue.
> - Metrics: all green, yeah
> - Health: a few failures I'm working on now
> - Rest Client: half failing or maybe more - tck setup or missing bits to
> start with
> - OpenAPI, Fault-tolerance: all failing or almost - no TCK setup or
> integration code
>
> I'd appreciate some help as I feel like I'm not seeing the end of the
> tunnel lol
>
> Hope it helps
>
>
>
>
>
>
>
> --
> Jean-Louis Monteiro
> http://twitter.com/jlouismonteiro
> http://www.tomitribe.com
>
>
> On Sat, Apr 2, 2022 at 11:13 AM Jean-Louis Monteiro <
> jlmonteiro@tomitribe.com> wrote:
>
>> Great discussion. Thanks everyone.
>>
>> I'll look at Sallrye over the weekend and see how hard it is to replace
>> our Apache libraries.
>>
>> --
>> Jean-Louis Monteiro
>> http://twitter.com/jlouismonteiro
>> http://www.tomitribe.com
>>
>>
>> On Fri, Apr 1, 2022 at 12:48 PM David Blevins <db...@tomitribe.com>
>> wrote:
>>
>>> This is very close. The dangers of A are not quite captured.
>>> Completely agree with the dangers of B.
>>>
>>> > On Apr 1, 2022, at 1:13 AM, Zowalla, Richard <
>>> richard.zowalla@hs-heilbronn.de> wrote:
>>> >
>>> > So we basically have to options (if I understand the discussion
>>> > correctly):
>>> >
>>> > (A) Put some effort / resources into upgrade our MP impls to the latest
>>> > versions to fully support Jakarta namespace. From my understanding
>>> > maintaining these impls is a bit PITA as MP tends to break its API
>>> > every few months, right? It will take some time, effort and resources
>>> > to catch up.
>>>
>>> The danger here is that we - due to lack of time / resources - will
>>> continue to not be seen as a viable MicroProfile implementation.
>>>
>>> MicroProfile is approximately 70 months old. We were able to keep up
>>> for only 1.5 months out of that 70. It was with TomEE 7.1, released with
>>> MicroProfile 2.0 support in September of 2018, outdated by MicroProfile 2.1
>>> in October 2018. We were 27 months late to getting our first and only
>>> MicroProfile version implemented, which is now 41 months out of date.
>>>
>>> >
>>> > (B) Use existing MP impls to make "fast" progress on the TomEE 9.x
>>> > side, which breaks the "we use apache impls"-credo but enables a faster
>>> > move forward. I see the danger here that we - due to lack of time /
>>> > resources - will not find the way back to our own Apache
>>> > implementations and will stick with smallrye for a long (?) time
>>> > perhaps.
>>>
>>> Correct. And as mentioned, not finding our way back to our own Apache
>>> implementations has already been the status quo.
>>>
>>> > People are eager to use EE9 / Jakarta namespace and TomEE isn't really
>>> > ready for it, yet. With the latest M7 version, users cannot start new
>>> > projects as testing possibilities are super limited.
>>> >
>>> > Btw.: I am unsure, if we are still using Hibernate Validation in the
>>> > current TomEE 9-M8 Snapshot. But if we do, we already broke the
>>> > "everything from apache"-credo for the sake of getting the
>>> > certifaction.
>>>
>>> Our certified distribution (Plume) used EclipseLink instead of OpenJPA,
>>> Mojarra instead of MyFaces and Hibernate Bean Validation instead of BVal.
>>>
>>>
>>> -David
>>>
>>>
--
Daniel Cunha
https://github.com/danielsoro
https://twitter.com/danielvlcunha
https://www.linkedin.com/in/danielvlcunha/
Re: TomEE MicroProfile and Jakarta
Posted by Daniel Cunha <da...@apache.org>.
Hey Jean-Louis,
if I understood correctly, we are working to provide TomEE with SmallRye
implementation. Have you shared some branches? Where is the code that you
are working on? Not sure if I can help too much, but I could spend some
time and put my eyes on it as well.
Thank you!
Em sex., 15 de abr. de 2022 às 08:09, Jean-Louis Monteiro <
jlmonteiro@tomitribe.com> escreveu:
> Hi,
>
> Following our discussion I went ahead and did the following
> - yank all Geronimo MicroProfile implementations until we can update them
> - update MicroProfile APIs to their latest and jakarta compatible versions
> - add SmallRye implementations for Config, Fault-Tolerance, OpenAPI,
> OpenTracing, Health and Metrics.
> - Kept our JWT microprofile implementation
> - Used CXF shaded and relocated version of the Rest Client
>
> Now, where are we?
> Doing all that worked but does not make TomEE to now be MicroProfile
> compliant.
> I went ahead and also updated all TCK to use the latest TCK and jakarta
> compatible version of MicroProfile.
>
> Unfortunately, SmallRye isn't like Geronimo so adding the libraries does
> not make anything happen. We were failing in all specifications. It's just
> a base set of libraries you can rely on, but ultimately, you need to write
> some integration code.
>
> Did most of the integration for Config, Metrics, Health, JWT and
> Rest-Client. Haven't started Fault-Tolerance and OpenAPI.
>
> - Config: we have 3 failures to look at. It might need some more code to
> address edge cases.
> - JWT: 22 failures and 12 not executed. Mainly a key issue.
> - Metrics: all green, yeah
> - Health: a few failures I'm working on now
> - Rest Client: half failing or maybe more - tck setup or missing bits to
> start with
> - OpenAPI, Fault-tolerance: all failing or almost - no TCK setup or
> integration code
>
> I'd appreciate some help as I feel like I'm not seeing the end of the
> tunnel lol
>
> Hope it helps
>
>
>
>
>
>
>
> --
> Jean-Louis Monteiro
> http://twitter.com/jlouismonteiro
> http://www.tomitribe.com
>
>
> On Sat, Apr 2, 2022 at 11:13 AM Jean-Louis Monteiro <
> jlmonteiro@tomitribe.com> wrote:
>
>> Great discussion. Thanks everyone.
>>
>> I'll look at Sallrye over the weekend and see how hard it is to replace
>> our Apache libraries.
>>
>> --
>> Jean-Louis Monteiro
>> http://twitter.com/jlouismonteiro
>> http://www.tomitribe.com
>>
>>
>> On Fri, Apr 1, 2022 at 12:48 PM David Blevins <db...@tomitribe.com>
>> wrote:
>>
>>> This is very close. The dangers of A are not quite captured.
>>> Completely agree with the dangers of B.
>>>
>>> > On Apr 1, 2022, at 1:13 AM, Zowalla, Richard <
>>> richard.zowalla@hs-heilbronn.de> wrote:
>>> >
>>> > So we basically have to options (if I understand the discussion
>>> > correctly):
>>> >
>>> > (A) Put some effort / resources into upgrade our MP impls to the latest
>>> > versions to fully support Jakarta namespace. From my understanding
>>> > maintaining these impls is a bit PITA as MP tends to break its API
>>> > every few months, right? It will take some time, effort and resources
>>> > to catch up.
>>>
>>> The danger here is that we - due to lack of time / resources - will
>>> continue to not be seen as a viable MicroProfile implementation.
>>>
>>> MicroProfile is approximately 70 months old. We were able to keep up
>>> for only 1.5 months out of that 70. It was with TomEE 7.1, released with
>>> MicroProfile 2.0 support in September of 2018, outdated by MicroProfile 2.1
>>> in October 2018. We were 27 months late to getting our first and only
>>> MicroProfile version implemented, which is now 41 months out of date.
>>>
>>> >
>>> > (B) Use existing MP impls to make "fast" progress on the TomEE 9.x
>>> > side, which breaks the "we use apache impls"-credo but enables a faster
>>> > move forward. I see the danger here that we - due to lack of time /
>>> > resources - will not find the way back to our own Apache
>>> > implementations and will stick with smallrye for a long (?) time
>>> > perhaps.
>>>
>>> Correct. And as mentioned, not finding our way back to our own Apache
>>> implementations has already been the status quo.
>>>
>>> > People are eager to use EE9 / Jakarta namespace and TomEE isn't really
>>> > ready for it, yet. With the latest M7 version, users cannot start new
>>> > projects as testing possibilities are super limited.
>>> >
>>> > Btw.: I am unsure, if we are still using Hibernate Validation in the
>>> > current TomEE 9-M8 Snapshot. But if we do, we already broke the
>>> > "everything from apache"-credo for the sake of getting the
>>> > certifaction.
>>>
>>> Our certified distribution (Plume) used EclipseLink instead of OpenJPA,
>>> Mojarra instead of MyFaces and Hibernate Bean Validation instead of BVal.
>>>
>>>
>>> -David
>>>
>>>
--
Daniel Cunha
https://github.com/danielsoro
https://twitter.com/danielvlcunha
https://www.linkedin.com/in/danielvlcunha/
Re: TomEE MicroProfile and Jakarta
Posted by Jean-Louis Monteiro <jl...@tomitribe.com>.
Hi,
Following our discussion I went ahead and did the following
- yank all Geronimo MicroProfile implementations until we can update them
- update MicroProfile APIs to their latest and jakarta compatible versions
- add SmallRye implementations for Config, Fault-Tolerance, OpenAPI,
OpenTracing, Health and Metrics.
- Kept our JWT microprofile implementation
- Used CXF shaded and relocated version of the Rest Client
Now, where are we?
Doing all that worked but does not make TomEE to now be MicroProfile
compliant.
I went ahead and also updated all TCK to use the latest TCK and jakarta
compatible version of MicroProfile.
Unfortunately, SmallRye isn't like Geronimo so adding the libraries does
not make anything happen. We were failing in all specifications. It's just
a base set of libraries you can rely on, but ultimately, you need to write
some integration code.
Did most of the integration for Config, Metrics, Health, JWT and
Rest-Client. Haven't started Fault-Tolerance and OpenAPI.
- Config: we have 3 failures to look at. It might need some more code to
address edge cases.
- JWT: 22 failures and 12 not executed. Mainly a key issue.
- Metrics: all green, yeah
- Health: a few failures I'm working on now
- Rest Client: half failing or maybe more - tck setup or missing bits to
start with
- OpenAPI, Fault-tolerance: all failing or almost - no TCK setup or
integration code
I'd appreciate some help as I feel like I'm not seeing the end of the
tunnel lol
Hope it helps
--
Jean-Louis Monteiro
http://twitter.com/jlouismonteiro
http://www.tomitribe.com
On Sat, Apr 2, 2022 at 11:13 AM Jean-Louis Monteiro <
jlmonteiro@tomitribe.com> wrote:
> Great discussion. Thanks everyone.
>
> I'll look at Sallrye over the weekend and see how hard it is to replace
> our Apache libraries.
>
> --
> Jean-Louis Monteiro
> http://twitter.com/jlouismonteiro
> http://www.tomitribe.com
>
>
> On Fri, Apr 1, 2022 at 12:48 PM David Blevins <db...@tomitribe.com>
> wrote:
>
>> This is very close. The dangers of A are not quite captured. Completely
>> agree with the dangers of B.
>>
>> > On Apr 1, 2022, at 1:13 AM, Zowalla, Richard <
>> richard.zowalla@hs-heilbronn.de> wrote:
>> >
>> > So we basically have to options (if I understand the discussion
>> > correctly):
>> >
>> > (A) Put some effort / resources into upgrade our MP impls to the latest
>> > versions to fully support Jakarta namespace. From my understanding
>> > maintaining these impls is a bit PITA as MP tends to break its API
>> > every few months, right? It will take some time, effort and resources
>> > to catch up.
>>
>> The danger here is that we - due to lack of time / resources - will
>> continue to not be seen as a viable MicroProfile implementation.
>>
>> MicroProfile is approximately 70 months old. We were able to keep up for
>> only 1.5 months out of that 70. It was with TomEE 7.1, released with
>> MicroProfile 2.0 support in September of 2018, outdated by MicroProfile 2.1
>> in October 2018. We were 27 months late to getting our first and only
>> MicroProfile version implemented, which is now 41 months out of date.
>>
>> >
>> > (B) Use existing MP impls to make "fast" progress on the TomEE 9.x
>> > side, which breaks the "we use apache impls"-credo but enables a faster
>> > move forward. I see the danger here that we - due to lack of time /
>> > resources - will not find the way back to our own Apache
>> > implementations and will stick with smallrye for a long (?) time
>> > perhaps.
>>
>> Correct. And as mentioned, not finding our way back to our own Apache
>> implementations has already been the status quo.
>>
>> > People are eager to use EE9 / Jakarta namespace and TomEE isn't really
>> > ready for it, yet. With the latest M7 version, users cannot start new
>> > projects as testing possibilities are super limited.
>> >
>> > Btw.: I am unsure, if we are still using Hibernate Validation in the
>> > current TomEE 9-M8 Snapshot. But if we do, we already broke the
>> > "everything from apache"-credo for the sake of getting the
>> > certifaction.
>>
>> Our certified distribution (Plume) used EclipseLink instead of OpenJPA,
>> Mojarra instead of MyFaces and Hibernate Bean Validation instead of BVal.
>>
>>
>> -David
>>
>>
Re: TomEE MicroProfile and Jakarta
Posted by Jean-Louis Monteiro <jl...@tomitribe.com>.
Hi,
Following our discussion I went ahead and did the following
- yank all Geronimo MicroProfile implementations until we can update them
- update MicroProfile APIs to their latest and jakarta compatible versions
- add SmallRye implementations for Config, Fault-Tolerance, OpenAPI,
OpenTracing, Health and Metrics.
- Kept our JWT microprofile implementation
- Used CXF shaded and relocated version of the Rest Client
Now, where are we?
Doing all that worked but does not make TomEE to now be MicroProfile
compliant.
I went ahead and also updated all TCK to use the latest TCK and jakarta
compatible version of MicroProfile.
Unfortunately, SmallRye isn't like Geronimo so adding the libraries does
not make anything happen. We were failing in all specifications. It's just
a base set of libraries you can rely on, but ultimately, you need to write
some integration code.
Did most of the integration for Config, Metrics, Health, JWT and
Rest-Client. Haven't started Fault-Tolerance and OpenAPI.
- Config: we have 3 failures to look at. It might need some more code to
address edge cases.
- JWT: 22 failures and 12 not executed. Mainly a key issue.
- Metrics: all green, yeah
- Health: a few failures I'm working on now
- Rest Client: half failing or maybe more - tck setup or missing bits to
start with
- OpenAPI, Fault-tolerance: all failing or almost - no TCK setup or
integration code
I'd appreciate some help as I feel like I'm not seeing the end of the
tunnel lol
Hope it helps
--
Jean-Louis Monteiro
http://twitter.com/jlouismonteiro
http://www.tomitribe.com
On Sat, Apr 2, 2022 at 11:13 AM Jean-Louis Monteiro <
jlmonteiro@tomitribe.com> wrote:
> Great discussion. Thanks everyone.
>
> I'll look at Sallrye over the weekend and see how hard it is to replace
> our Apache libraries.
>
> --
> Jean-Louis Monteiro
> http://twitter.com/jlouismonteiro
> http://www.tomitribe.com
>
>
> On Fri, Apr 1, 2022 at 12:48 PM David Blevins <db...@tomitribe.com>
> wrote:
>
>> This is very close. The dangers of A are not quite captured. Completely
>> agree with the dangers of B.
>>
>> > On Apr 1, 2022, at 1:13 AM, Zowalla, Richard <
>> richard.zowalla@hs-heilbronn.de> wrote:
>> >
>> > So we basically have to options (if I understand the discussion
>> > correctly):
>> >
>> > (A) Put some effort / resources into upgrade our MP impls to the latest
>> > versions to fully support Jakarta namespace. From my understanding
>> > maintaining these impls is a bit PITA as MP tends to break its API
>> > every few months, right? It will take some time, effort and resources
>> > to catch up.
>>
>> The danger here is that we - due to lack of time / resources - will
>> continue to not be seen as a viable MicroProfile implementation.
>>
>> MicroProfile is approximately 70 months old. We were able to keep up for
>> only 1.5 months out of that 70. It was with TomEE 7.1, released with
>> MicroProfile 2.0 support in September of 2018, outdated by MicroProfile 2.1
>> in October 2018. We were 27 months late to getting our first and only
>> MicroProfile version implemented, which is now 41 months out of date.
>>
>> >
>> > (B) Use existing MP impls to make "fast" progress on the TomEE 9.x
>> > side, which breaks the "we use apache impls"-credo but enables a faster
>> > move forward. I see the danger here that we - due to lack of time /
>> > resources - will not find the way back to our own Apache
>> > implementations and will stick with smallrye for a long (?) time
>> > perhaps.
>>
>> Correct. And as mentioned, not finding our way back to our own Apache
>> implementations has already been the status quo.
>>
>> > People are eager to use EE9 / Jakarta namespace and TomEE isn't really
>> > ready for it, yet. With the latest M7 version, users cannot start new
>> > projects as testing possibilities are super limited.
>> >
>> > Btw.: I am unsure, if we are still using Hibernate Validation in the
>> > current TomEE 9-M8 Snapshot. But if we do, we already broke the
>> > "everything from apache"-credo for the sake of getting the
>> > certifaction.
>>
>> Our certified distribution (Plume) used EclipseLink instead of OpenJPA,
>> Mojarra instead of MyFaces and Hibernate Bean Validation instead of BVal.
>>
>>
>> -David
>>
>>
Re: TomEE MicroProfile and Jakarta
Posted by Jean-Louis Monteiro <jl...@tomitribe.com>.
Great discussion. Thanks everyone.
I'll look at Sallrye over the weekend and see how hard it is to replace our
Apache libraries.
--
Jean-Louis Monteiro
http://twitter.com/jlouismonteiro
http://www.tomitribe.com
On Fri, Apr 1, 2022 at 12:48 PM David Blevins <db...@tomitribe.com>
wrote:
> This is very close. The dangers of A are not quite captured. Completely
> agree with the dangers of B.
>
> > On Apr 1, 2022, at 1:13 AM, Zowalla, Richard <
> richard.zowalla@hs-heilbronn.de> wrote:
> >
> > So we basically have to options (if I understand the discussion
> > correctly):
> >
> > (A) Put some effort / resources into upgrade our MP impls to the latest
> > versions to fully support Jakarta namespace. From my understanding
> > maintaining these impls is a bit PITA as MP tends to break its API
> > every few months, right? It will take some time, effort and resources
> > to catch up.
>
> The danger here is that we - due to lack of time / resources - will
> continue to not be seen as a viable MicroProfile implementation.
>
> MicroProfile is approximately 70 months old. We were able to keep up for
> only 1.5 months out of that 70. It was with TomEE 7.1, released with
> MicroProfile 2.0 support in September of 2018, outdated by MicroProfile 2.1
> in October 2018. We were 27 months late to getting our first and only
> MicroProfile version implemented, which is now 41 months out of date.
>
> >
> > (B) Use existing MP impls to make "fast" progress on the TomEE 9.x
> > side, which breaks the "we use apache impls"-credo but enables a faster
> > move forward. I see the danger here that we - due to lack of time /
> > resources - will not find the way back to our own Apache
> > implementations and will stick with smallrye for a long (?) time
> > perhaps.
>
> Correct. And as mentioned, not finding our way back to our own Apache
> implementations has already been the status quo.
>
> > People are eager to use EE9 / Jakarta namespace and TomEE isn't really
> > ready for it, yet. With the latest M7 version, users cannot start new
> > projects as testing possibilities are super limited.
> >
> > Btw.: I am unsure, if we are still using Hibernate Validation in the
> > current TomEE 9-M8 Snapshot. But if we do, we already broke the
> > "everything from apache"-credo for the sake of getting the
> > certifaction.
>
> Our certified distribution (Plume) used EclipseLink instead of OpenJPA,
> Mojarra instead of MyFaces and Hibernate Bean Validation instead of BVal.
>
>
> -David
>
>
Re: TomEE MicroProfile and Jakarta
Posted by Jean-Louis Monteiro <jl...@tomitribe.com>.
Great discussion. Thanks everyone.
I'll look at Sallrye over the weekend and see how hard it is to replace our
Apache libraries.
--
Jean-Louis Monteiro
http://twitter.com/jlouismonteiro
http://www.tomitribe.com
On Fri, Apr 1, 2022 at 12:48 PM David Blevins <db...@tomitribe.com>
wrote:
> This is very close. The dangers of A are not quite captured. Completely
> agree with the dangers of B.
>
> > On Apr 1, 2022, at 1:13 AM, Zowalla, Richard <
> richard.zowalla@hs-heilbronn.de> wrote:
> >
> > So we basically have to options (if I understand the discussion
> > correctly):
> >
> > (A) Put some effort / resources into upgrade our MP impls to the latest
> > versions to fully support Jakarta namespace. From my understanding
> > maintaining these impls is a bit PITA as MP tends to break its API
> > every few months, right? It will take some time, effort and resources
> > to catch up.
>
> The danger here is that we - due to lack of time / resources - will
> continue to not be seen as a viable MicroProfile implementation.
>
> MicroProfile is approximately 70 months old. We were able to keep up for
> only 1.5 months out of that 70. It was with TomEE 7.1, released with
> MicroProfile 2.0 support in September of 2018, outdated by MicroProfile 2.1
> in October 2018. We were 27 months late to getting our first and only
> MicroProfile version implemented, which is now 41 months out of date.
>
> >
> > (B) Use existing MP impls to make "fast" progress on the TomEE 9.x
> > side, which breaks the "we use apache impls"-credo but enables a faster
> > move forward. I see the danger here that we - due to lack of time /
> > resources - will not find the way back to our own Apache
> > implementations and will stick with smallrye for a long (?) time
> > perhaps.
>
> Correct. And as mentioned, not finding our way back to our own Apache
> implementations has already been the status quo.
>
> > People are eager to use EE9 / Jakarta namespace and TomEE isn't really
> > ready for it, yet. With the latest M7 version, users cannot start new
> > projects as testing possibilities are super limited.
> >
> > Btw.: I am unsure, if we are still using Hibernate Validation in the
> > current TomEE 9-M8 Snapshot. But if we do, we already broke the
> > "everything from apache"-credo for the sake of getting the
> > certifaction.
>
> Our certified distribution (Plume) used EclipseLink instead of OpenJPA,
> Mojarra instead of MyFaces and Hibernate Bean Validation instead of BVal.
>
>
> -David
>
>
Re: TomEE MicroProfile and Jakarta
Posted by David Blevins <db...@tomitribe.com>.
This is very close. The dangers of A are not quite captured. Completely agree with the dangers of B.
> On Apr 1, 2022, at 1:13 AM, Zowalla, Richard <ri...@hs-heilbronn.de> wrote:
>
> So we basically have to options (if I understand the discussion
> correctly):
>
> (A) Put some effort / resources into upgrade our MP impls to the latest
> versions to fully support Jakarta namespace. From my understanding
> maintaining these impls is a bit PITA as MP tends to break its API
> every few months, right? It will take some time, effort and resources
> to catch up.
The danger here is that we - due to lack of time / resources - will continue to not be seen as a viable MicroProfile implementation.
MicroProfile is approximately 70 months old. We were able to keep up for only 1.5 months out of that 70. It was with TomEE 7.1, released with MicroProfile 2.0 support in September of 2018, outdated by MicroProfile 2.1 in October 2018. We were 27 months late to getting our first and only MicroProfile version implemented, which is now 41 months out of date.
>
> (B) Use existing MP impls to make "fast" progress on the TomEE 9.x
> side, which breaks the "we use apache impls"-credo but enables a faster
> move forward. I see the danger here that we - due to lack of time /
> resources - will not find the way back to our own Apache
> implementations and will stick with smallrye for a long (?) time
> perhaps.
Correct. And as mentioned, not finding our way back to our own Apache implementations has already been the status quo.
> People are eager to use EE9 / Jakarta namespace and TomEE isn't really
> ready for it, yet. With the latest M7 version, users cannot start new
> projects as testing possibilities are super limited.
>
> Btw.: I am unsure, if we are still using Hibernate Validation in the
> current TomEE 9-M8 Snapshot. But if we do, we already broke the
> "everything from apache"-credo for the sake of getting the
> certifaction.
Our certified distribution (Plume) used EclipseLink instead of OpenJPA, Mojarra instead of MyFaces and Hibernate Bean Validation instead of BVal.
-David
Re: TomEE MicroProfile and Jakarta
Posted by David Blevins <db...@tomitribe.com>.
This is very close. The dangers of A are not quite captured. Completely agree with the dangers of B.
> On Apr 1, 2022, at 1:13 AM, Zowalla, Richard <ri...@hs-heilbronn.de> wrote:
>
> So we basically have to options (if I understand the discussion
> correctly):
>
> (A) Put some effort / resources into upgrade our MP impls to the latest
> versions to fully support Jakarta namespace. From my understanding
> maintaining these impls is a bit PITA as MP tends to break its API
> every few months, right? It will take some time, effort and resources
> to catch up.
The danger here is that we - due to lack of time / resources - will continue to not be seen as a viable MicroProfile implementation.
MicroProfile is approximately 70 months old. We were able to keep up for only 1.5 months out of that 70. It was with TomEE 7.1, released with MicroProfile 2.0 support in September of 2018, outdated by MicroProfile 2.1 in October 2018. We were 27 months late to getting our first and only MicroProfile version implemented, which is now 41 months out of date.
>
> (B) Use existing MP impls to make "fast" progress on the TomEE 9.x
> side, which breaks the "we use apache impls"-credo but enables a faster
> move forward. I see the danger here that we - due to lack of time /
> resources - will not find the way back to our own Apache
> implementations and will stick with smallrye for a long (?) time
> perhaps.
Correct. And as mentioned, not finding our way back to our own Apache implementations has already been the status quo.
> People are eager to use EE9 / Jakarta namespace and TomEE isn't really
> ready for it, yet. With the latest M7 version, users cannot start new
> projects as testing possibilities are super limited.
>
> Btw.: I am unsure, if we are still using Hibernate Validation in the
> current TomEE 9-M8 Snapshot. But if we do, we already broke the
> "everything from apache"-credo for the sake of getting the
> certifaction.
Our certified distribution (Plume) used EclipseLink instead of OpenJPA, Mojarra instead of MyFaces and Hibernate Bean Validation instead of BVal.
-David
Re: TomEE MicroProfile and Jakarta
Posted by "Zowalla, Richard" <ri...@hs-heilbronn.de>.
So we basically have to options (if I understand the discussion
correctly):
(A) Put some effort / resources into upgrade our MP impls to the latest
versions to fully support Jakarta namespace. From my understanding
maintaining these impls is a bit PITA as MP tends to break its API
every few months, right? It will take some time, effort and resources
to catch up.
(B) Use existing MP impls to make "fast" progress on the TomEE 9.x
side, which breaks the "we use apache impls"-credo but enables a faster
move forward. I see the danger here that we - due to lack of time /
resources - will not find the way back to our own Apache
implementations and will stick with smallrye for a long (?) time
perhaps.
People are eager to use EE9 / Jakarta namespace and TomEE isn't really
ready for it, yet. With the latest M7 version, users cannot start new
projects as testing possibilities are super limited.
Btw.: I am unsure, if we are still using Hibernate Validation in the
current TomEE 9-M8 Snapshot. But if we do, we already broke the
"everything from apache"-credo for the sake of getting the
certifaction.
As I am too new to the whole context / strategy thing, I read this
discussion with great interest but do not have a strong opinion
regarding (A) or (B).
Gruß
Richard
Am Freitag, dem 01.04.2022 um 08:27 +0200 schrieb Romain Manni-Bucau:
> The risk for TomEE (IMHO indeed) is that, using smallrye, you break
> the
> core value "apache" or at least "owned by apache" and break the other
> core
> value "lightweight" since it comes with a tons of uneeded stuff and
> implementation is not even JAXRS friendly (it breaks literally jaxrs
> and
> cdi at multiple levels) so it can mean contributing to smallrye which
> means
> at the end asking mircoprofile to not be a spec but just an
> implementation
> and TomEE to stick to a dedicated MP distro (not in all others) to
> not kill
> itself - not saying it does not makes sense but it is what it means
> concretely.
>
> 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. 31 mars 2022 à 21:36, David Blevins <da...@gmail.com>
> a
> écrit :
>
> > It would be great to see us have compliant MicroProfile
> > implementations
> > somewhere in Apache; Geronimo, TomEE, CXF. It's still my personal
> > preference -- It makes very little sense to go through the effort
> > to
> > create a spec and tck to enable multiple implementations that can
> > compete/innovate and then wind up with just one implementation in
> > the
> > industry.
> >
> > That said, from a TomEE perspective we're struggling to keep up
> > with all
> > specs, Jakarta EE and MicroProfile. Part of that is we do try to
> > uniquely
> > implement specs, while everyone else just uses the exact same
> > implementation. We're not really playing the same game. We would
> > need
> > more resources than the competition to compete in the way we have
> > been
> > attempting. However, because we're behind, we end up with fewer
> > resources
> > and larger gaps between implementations and over time our goals
> > becomes
> > harder, not easier.
> >
> > I wonder if we should switch to the SmallRye implementations where
> > needed. Not because we've given up hope of having Apache
> > implementations,
> > but because if we assume our desire to do the implementation work
> > here is a
> > constant and we know the time to get there will some number of
> > months and
> > that will likely be after complete our Jakarta EE spec work, which
> > is also
> > some number of months... we're basically talking sometime
> > 2023. The
> > question then becomes, how do we want to spend our time till
> > then? Do we
> > want to spend it in a compliant state or a non-compliant state?
> >
> > If we spend the next year and change in a compliant state, using
> > the
> > SmallRye impls where needed until we've created compliant Apache
> > versions,
> > then we are competitive and will gain resources. The date on which
> > we
> > would have resources to create those Apache implementations would
> > likely be
> > sooner. If we spend the next year and change still not in a
> > compliant
> > state (as we've been since 2020), then we'l continue to take a
> > resource hit
> > and the date on which we would have resources to create those
> > Apache
> > implementations would likely be later. There are also other risks
> > with
> > this approach.
> >
> > So though it may seem backwards my gut says, unless we get a
> > dramatic
> > influx of resources from nowhere, we should use SmallRye where we
> > need
> > until we have the time to dedicate to the Apache implementations.
> >
> >
> > -David
> >
> >
> > > On Mar 31, 2022, at 12:44 AM, Jean-Louis Monteiro <
> > jlmonteiro@tomitribe.com> wrote:
> > > Hi,
> > >
> > > Small update regarding jakarta namespace switch and MicroProfile.
> > > Adding
> > > Geronimo dev@list because we are using most of the Geronimo
> > implementations
> > > In order to migrate, we have created a shaded version of all
> > > MicroProfile
> > > APIs to relocate all javax to jakarta. It worked but it's causing
> > > some
> > > issues with TCK. They are not relocated so of course, all TCK are
> > failing.
> > > I wanted to see how far we are regarding our implementations, so
> > > I went
> > > ahead and updated all TCK to the latest version (and compatible
> > > with the
> > > Jakarta namespace).
> > >
> > > The other option would be to grab all the TCK and create their
> > > equivalent
> > > in jakarta namespace using the same approach as for the APIs.
> > >
> > > What are your thoughts?
> > >
> > > --
> > > Jean-Louis Monteiro
> > > http://twitter.com/jlouismonteiro
> > > http://www.tomitribe.com
Re: TomEE MicroProfile and Jakarta
Posted by "Zowalla, Richard" <ri...@hs-heilbronn.de>.
So we basically have to options (if I understand the discussion
correctly):
(A) Put some effort / resources into upgrade our MP impls to the latest
versions to fully support Jakarta namespace. From my understanding
maintaining these impls is a bit PITA as MP tends to break its API
every few months, right? It will take some time, effort and resources
to catch up.
(B) Use existing MP impls to make "fast" progress on the TomEE 9.x
side, which breaks the "we use apache impls"-credo but enables a faster
move forward. I see the danger here that we - due to lack of time /
resources - will not find the way back to our own Apache
implementations and will stick with smallrye for a long (?) time
perhaps.
People are eager to use EE9 / Jakarta namespace and TomEE isn't really
ready for it, yet. With the latest M7 version, users cannot start new
projects as testing possibilities are super limited.
Btw.: I am unsure, if we are still using Hibernate Validation in the
current TomEE 9-M8 Snapshot. But if we do, we already broke the
"everything from apache"-credo for the sake of getting the
certifaction.
As I am too new to the whole context / strategy thing, I read this
discussion with great interest but do not have a strong opinion
regarding (A) or (B).
Gruß
Richard
Am Freitag, dem 01.04.2022 um 08:27 +0200 schrieb Romain Manni-Bucau:
> The risk for TomEE (IMHO indeed) is that, using smallrye, you break
> the
> core value "apache" or at least "owned by apache" and break the other
> core
> value "lightweight" since it comes with a tons of uneeded stuff and
> implementation is not even JAXRS friendly (it breaks literally jaxrs
> and
> cdi at multiple levels) so it can mean contributing to smallrye which
> means
> at the end asking mircoprofile to not be a spec but just an
> implementation
> and TomEE to stick to a dedicated MP distro (not in all others) to
> not kill
> itself - not saying it does not makes sense but it is what it means
> concretely.
>
> 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. 31 mars 2022 à 21:36, David Blevins <da...@gmail.com>
> a
> écrit :
>
> > It would be great to see us have compliant MicroProfile
> > implementations
> > somewhere in Apache; Geronimo, TomEE, CXF. It's still my personal
> > preference -- It makes very little sense to go through the effort
> > to
> > create a spec and tck to enable multiple implementations that can
> > compete/innovate and then wind up with just one implementation in
> > the
> > industry.
> >
> > That said, from a TomEE perspective we're struggling to keep up
> > with all
> > specs, Jakarta EE and MicroProfile. Part of that is we do try to
> > uniquely
> > implement specs, while everyone else just uses the exact same
> > implementation. We're not really playing the same game. We would
> > need
> > more resources than the competition to compete in the way we have
> > been
> > attempting. However, because we're behind, we end up with fewer
> > resources
> > and larger gaps between implementations and over time our goals
> > becomes
> > harder, not easier.
> >
> > I wonder if we should switch to the SmallRye implementations where
> > needed. Not because we've given up hope of having Apache
> > implementations,
> > but because if we assume our desire to do the implementation work
> > here is a
> > constant and we know the time to get there will some number of
> > months and
> > that will likely be after complete our Jakarta EE spec work, which
> > is also
> > some number of months... we're basically talking sometime
> > 2023. The
> > question then becomes, how do we want to spend our time till
> > then? Do we
> > want to spend it in a compliant state or a non-compliant state?
> >
> > If we spend the next year and change in a compliant state, using
> > the
> > SmallRye impls where needed until we've created compliant Apache
> > versions,
> > then we are competitive and will gain resources. The date on which
> > we
> > would have resources to create those Apache implementations would
> > likely be
> > sooner. If we spend the next year and change still not in a
> > compliant
> > state (as we've been since 2020), then we'l continue to take a
> > resource hit
> > and the date on which we would have resources to create those
> > Apache
> > implementations would likely be later. There are also other risks
> > with
> > this approach.
> >
> > So though it may seem backwards my gut says, unless we get a
> > dramatic
> > influx of resources from nowhere, we should use SmallRye where we
> > need
> > until we have the time to dedicate to the Apache implementations.
> >
> >
> > -David
> >
> >
> > > On Mar 31, 2022, at 12:44 AM, Jean-Louis Monteiro <
> > jlmonteiro@tomitribe.com> wrote:
> > > Hi,
> > >
> > > Small update regarding jakarta namespace switch and MicroProfile.
> > > Adding
> > > Geronimo dev@list because we are using most of the Geronimo
> > implementations
> > > In order to migrate, we have created a shaded version of all
> > > MicroProfile
> > > APIs to relocate all javax to jakarta. It worked but it's causing
> > > some
> > > issues with TCK. They are not relocated so of course, all TCK are
> > failing.
> > > I wanted to see how far we are regarding our implementations, so
> > > I went
> > > ahead and updated all TCK to the latest version (and compatible
> > > with the
> > > Jakarta namespace).
> > >
> > > The other option would be to grab all the TCK and create their
> > > equivalent
> > > in jakarta namespace using the same approach as for the APIs.
> > >
> > > What are your thoughts?
> > >
> > > --
> > > Jean-Louis Monteiro
> > > http://twitter.com/jlouismonteiro
> > > http://www.tomitribe.com