You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@johnzon.apache.org by Clebert Suconic <cl...@gmail.com> on 2021/11/11 17:32:07 UTC
ActiveMQ Artemis: Independent core
As the core implementation is hard coded towards javax.json, Artemis
requires using javax.json libraries as we use
However we have users that require jakarta APIs, and since our server
implementation relies on javax.json, we would need to provide a shaded
version of our server as well.
And this is honestly getting out of hand. We already provide shaded
client libraries.. but now users want the dependency switch optionally
on the server's as well.
Can't we refactor the core implementation to have public
implementations without requiring javax.json or jakarta.json? and then
having a facade on top of the implementation for each binding?
--
Clebert Suconic
Re: ActiveMQ Artemis: Independent core
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Le ven. 12 nov. 2021 à 22:01, Clebert Suconic <cl...@gmail.com> a
écrit :
> Yeah.. I don't need both at the same time...but I have to develop
> artemis clients for Jakarta and for Javax.
>
> so, I'm fixing that by creating my own shading of javax.json on my
> artemis-commons client for now.... which I will remove it in a few
> years when we stop supporting javax. libraries...
>
>
> This javax and jakarta names is a mess... geez!
>
Oh yeah
But you can solve it with boms I guess.
>
> Thanks for the help again
>
> On Fri, Nov 12, 2021 at 1:51 AM Romain Manni-Bucau
> <rm...@gmail.com> wrote:
> >
> > +1
> >
> > The only fuzz johnzon can create as of today is that we relocate javax ->
> > jakarta but not johnzon -> org.apache.johnzon.jakarta (to enable a future
> > transparent transition), but as mentionned, if you use both at the same
> > time it can't work as of today but guess having both at the same time is
> a
> > rare case - even TomEE never has this case.
> >
> > 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. 11 nov. 2021 à 21:49, Clebert Suconic <cl...@gmail.com>
> a
> > écrit :
> >
> > > thing is Spring and Wildfly they are removing all libraries that have
> > > anything to do with javax..... and I'm not sure if I provide a jakarta
> > > library if that would create any fuss..
> > >
> > >
> > > it doesn't make sense to me either. other than users wanting that...
> > >
> > >
> > > let me clear that with some guys on spring and wildfly to see if I
> > > could just use jakarta...
> > >
> > >
> > > thanks for the help... I will figure out this first.
> > >
> > > On Thu, Nov 11, 2021 at 3:21 PM Romain Manni-Bucau
> > > <rm...@gmail.com> wrote:
> > > >
> > > > Le jeu. 11 nov. 2021 à 19:02, Clebert Suconic <
> clebert.suconic@gmail.com>
> > > a
> > > > écrit :
> > > >
> > > > > We provide javax and jakarta libraries for our client libraries.
> > > > >
> > > > > and Johnzon is used internally at some places, but it's not really
> > > > > part of the API.
> > > > >
> > > > > So, certain users when embedding Artemis into their server want to
> use
> > > > > only jakarta libraries.
> > > > >
> > > > > Our server does not need the library to be jakarta, so if we had a
> > > > > org.apache.johzon.api instead, it would make our life easier on my
> own
> > > > > distribution of both libraries.
> > > > >
> > > >
> > > > Have to admit it does not make much sense after some thought+testing
> > > cause
> > > > if so, isnt javax as org.apache.johnzon for a jakarta server (and the
> > > > opposite too)? For servers supporting both it is not an issue too.
> > > >
> > > > So Im quite puzzled to see any case a 3rd distro would help any user
> out
> > > of
> > > > "i dont want javax" which is as arbitrary as "i dont want apache".
> > > >
> > > > What I think we must not do is a facade on top of javax/jakarta in
> our
> > > core
> > > > cause it will be a mess in a few version when well drop javax
> support.
> > > >
> > > > If it is internal for artemis, why not just moving to jakarta? Will
> not
> > > > break javax users until they use johnzon for both and if so, dropping
> > > > yasson for the "other" impl is a workaround until both namespaces are
> > > > merged in jakarta for the app.
> > > >
> > > > Overall my point is that javax is dead so it is just a migration
> step so
> > > we
> > > > shouldnt have a core module abstracting both.
> > > >
> > > > Fine if we do a johnzon-javax-jakarta-abstraction new module we drop
> in
> > > 3-4
> > > > years. Is it what you want? Do you want to PR it? Guess we dont need
> > > > reflection at all using a small reflection check of the provider
> > > > implemented classes and a proxy based impl for interfaces -
> personally i
> > > > would go with asm generation but any impl working for you with a low
> > > > overhead is fine.
> > > >
> > > >
> > > >
> > > > >
> > > > > On Thu, Nov 11, 2021 at 12:54 PM Romain Manni-Bucau
> > > > > <rm...@gmail.com> wrote:
> > > > > >
> > > > > > Hi Clebert,
> > > > > >
> > > > > > What is the goal? Use org.apache.johnzon.api instead of a
> portable
> > > API?
> > > > > I'm
> > > > > > fine doing another shade - as javax/jakarta one - in
> > > > > > org.apache.johnzon.apix or any package helping if it is the idea
> -
> > > but
> > > > > not
> > > > > > sure I fully got the actual issue since from my window artemis
> must
> > > > > provide
> > > > > > a jakarta and a javax version of its impl - as all EE libs - so
> it
> > > could
> > > > > > likely be saner to solve it with a shade of artemis itself -
> thinking
> > > > > loud
> > > > > > to JMS first and JSON* as a consequence more than an issue by
> itself.
> > > > > >
> > > > > > Hope I'm not too off the actual issue.
> > > > > >
> > > > > > 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. 11 nov. 2021 à 18:32, Clebert Suconic <
> > > clebert.suconic@gmail.com>
> > > > > a
> > > > > > écrit :
> > > > > >
> > > > > > > As the core implementation is hard coded towards javax.json,
> > > Artemis
> > > > > > > requires using javax.json libraries as we use
> > > > > > >
> > > > > > > However we have users that require jakarta APIs, and since our
> > > server
> > > > > > > implementation relies on javax.json, we would need to provide a
> > > shaded
> > > > > > > version of our server as well.
> > > > > > >
> > > > > > > And this is honestly getting out of hand. We already provide
> shaded
> > > > > > > client libraries.. but now users want the dependency switch
> > > optionally
> > > > > > > on the server's as well.
> > > > > > >
> > > > > > > Can't we refactor the core implementation to have public
> > > > > > > implementations without requiring javax.json or jakarta.json?
> and
> > > then
> > > > > > > having a facade on top of the implementation for each binding?
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > Clebert Suconic
> > > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Clebert Suconic
> > > > >
> > >
> > >
> > >
> > > --
> > > Clebert Suconic
> > >
>
>
>
> --
> Clebert Suconic
>
Re: ActiveMQ Artemis: Independent core
Posted by Clebert Suconic <cl...@gmail.com>.
Yeah.. I don't need both at the same time...but I have to develop
artemis clients for Jakarta and for Javax.
so, I'm fixing that by creating my own shading of javax.json on my
artemis-commons client for now.... which I will remove it in a few
years when we stop supporting javax. libraries...
This javax and jakarta names is a mess... geez!
Thanks for the help again
On Fri, Nov 12, 2021 at 1:51 AM Romain Manni-Bucau
<rm...@gmail.com> wrote:
>
> +1
>
> The only fuzz johnzon can create as of today is that we relocate javax ->
> jakarta but not johnzon -> org.apache.johnzon.jakarta (to enable a future
> transparent transition), but as mentionned, if you use both at the same
> time it can't work as of today but guess having both at the same time is a
> rare case - even TomEE never has this case.
>
> 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. 11 nov. 2021 à 21:49, Clebert Suconic <cl...@gmail.com> a
> écrit :
>
> > thing is Spring and Wildfly they are removing all libraries that have
> > anything to do with javax..... and I'm not sure if I provide a jakarta
> > library if that would create any fuss..
> >
> >
> > it doesn't make sense to me either. other than users wanting that...
> >
> >
> > let me clear that with some guys on spring and wildfly to see if I
> > could just use jakarta...
> >
> >
> > thanks for the help... I will figure out this first.
> >
> > On Thu, Nov 11, 2021 at 3:21 PM Romain Manni-Bucau
> > <rm...@gmail.com> wrote:
> > >
> > > Le jeu. 11 nov. 2021 à 19:02, Clebert Suconic <cl...@gmail.com>
> > a
> > > écrit :
> > >
> > > > We provide javax and jakarta libraries for our client libraries.
> > > >
> > > > and Johnzon is used internally at some places, but it's not really
> > > > part of the API.
> > > >
> > > > So, certain users when embedding Artemis into their server want to use
> > > > only jakarta libraries.
> > > >
> > > > Our server does not need the library to be jakarta, so if we had a
> > > > org.apache.johzon.api instead, it would make our life easier on my own
> > > > distribution of both libraries.
> > > >
> > >
> > > Have to admit it does not make much sense after some thought+testing
> > cause
> > > if so, isnt javax as org.apache.johnzon for a jakarta server (and the
> > > opposite too)? For servers supporting both it is not an issue too.
> > >
> > > So Im quite puzzled to see any case a 3rd distro would help any user out
> > of
> > > "i dont want javax" which is as arbitrary as "i dont want apache".
> > >
> > > What I think we must not do is a facade on top of javax/jakarta in our
> > core
> > > cause it will be a mess in a few version when well drop javax support.
> > >
> > > If it is internal for artemis, why not just moving to jakarta? Will not
> > > break javax users until they use johnzon for both and if so, dropping
> > > yasson for the "other" impl is a workaround until both namespaces are
> > > merged in jakarta for the app.
> > >
> > > Overall my point is that javax is dead so it is just a migration step so
> > we
> > > shouldnt have a core module abstracting both.
> > >
> > > Fine if we do a johnzon-javax-jakarta-abstraction new module we drop in
> > 3-4
> > > years. Is it what you want? Do you want to PR it? Guess we dont need
> > > reflection at all using a small reflection check of the provider
> > > implemented classes and a proxy based impl for interfaces - personally i
> > > would go with asm generation but any impl working for you with a low
> > > overhead is fine.
> > >
> > >
> > >
> > > >
> > > > On Thu, Nov 11, 2021 at 12:54 PM Romain Manni-Bucau
> > > > <rm...@gmail.com> wrote:
> > > > >
> > > > > Hi Clebert,
> > > > >
> > > > > What is the goal? Use org.apache.johnzon.api instead of a portable
> > API?
> > > > I'm
> > > > > fine doing another shade - as javax/jakarta one - in
> > > > > org.apache.johnzon.apix or any package helping if it is the idea -
> > but
> > > > not
> > > > > sure I fully got the actual issue since from my window artemis must
> > > > provide
> > > > > a jakarta and a javax version of its impl - as all EE libs - so it
> > could
> > > > > likely be saner to solve it with a shade of artemis itself - thinking
> > > > loud
> > > > > to JMS first and JSON* as a consequence more than an issue by itself.
> > > > >
> > > > > Hope I'm not too off the actual issue.
> > > > >
> > > > > 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. 11 nov. 2021 à 18:32, Clebert Suconic <
> > clebert.suconic@gmail.com>
> > > > a
> > > > > écrit :
> > > > >
> > > > > > As the core implementation is hard coded towards javax.json,
> > Artemis
> > > > > > requires using javax.json libraries as we use
> > > > > >
> > > > > > However we have users that require jakarta APIs, and since our
> > server
> > > > > > implementation relies on javax.json, we would need to provide a
> > shaded
> > > > > > version of our server as well.
> > > > > >
> > > > > > And this is honestly getting out of hand. We already provide shaded
> > > > > > client libraries.. but now users want the dependency switch
> > optionally
> > > > > > on the server's as well.
> > > > > >
> > > > > > Can't we refactor the core implementation to have public
> > > > > > implementations without requiring javax.json or jakarta.json? and
> > then
> > > > > > having a facade on top of the implementation for each binding?
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Clebert Suconic
> > > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Clebert Suconic
> > > >
> >
> >
> >
> > --
> > Clebert Suconic
> >
--
Clebert Suconic
Re: ActiveMQ Artemis: Independent core
Posted by Romain Manni-Bucau <rm...@gmail.com>.
+1
The only fuzz johnzon can create as of today is that we relocate javax ->
jakarta but not johnzon -> org.apache.johnzon.jakarta (to enable a future
transparent transition), but as mentionned, if you use both at the same
time it can't work as of today but guess having both at the same time is a
rare case - even TomEE never has this case.
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. 11 nov. 2021 à 21:49, Clebert Suconic <cl...@gmail.com> a
écrit :
> thing is Spring and Wildfly they are removing all libraries that have
> anything to do with javax..... and I'm not sure if I provide a jakarta
> library if that would create any fuss..
>
>
> it doesn't make sense to me either. other than users wanting that...
>
>
> let me clear that with some guys on spring and wildfly to see if I
> could just use jakarta...
>
>
> thanks for the help... I will figure out this first.
>
> On Thu, Nov 11, 2021 at 3:21 PM Romain Manni-Bucau
> <rm...@gmail.com> wrote:
> >
> > Le jeu. 11 nov. 2021 à 19:02, Clebert Suconic <cl...@gmail.com>
> a
> > écrit :
> >
> > > We provide javax and jakarta libraries for our client libraries.
> > >
> > > and Johnzon is used internally at some places, but it's not really
> > > part of the API.
> > >
> > > So, certain users when embedding Artemis into their server want to use
> > > only jakarta libraries.
> > >
> > > Our server does not need the library to be jakarta, so if we had a
> > > org.apache.johzon.api instead, it would make our life easier on my own
> > > distribution of both libraries.
> > >
> >
> > Have to admit it does not make much sense after some thought+testing
> cause
> > if so, isnt javax as org.apache.johnzon for a jakarta server (and the
> > opposite too)? For servers supporting both it is not an issue too.
> >
> > So Im quite puzzled to see any case a 3rd distro would help any user out
> of
> > "i dont want javax" which is as arbitrary as "i dont want apache".
> >
> > What I think we must not do is a facade on top of javax/jakarta in our
> core
> > cause it will be a mess in a few version when well drop javax support.
> >
> > If it is internal for artemis, why not just moving to jakarta? Will not
> > break javax users until they use johnzon for both and if so, dropping
> > yasson for the "other" impl is a workaround until both namespaces are
> > merged in jakarta for the app.
> >
> > Overall my point is that javax is dead so it is just a migration step so
> we
> > shouldnt have a core module abstracting both.
> >
> > Fine if we do a johnzon-javax-jakarta-abstraction new module we drop in
> 3-4
> > years. Is it what you want? Do you want to PR it? Guess we dont need
> > reflection at all using a small reflection check of the provider
> > implemented classes and a proxy based impl for interfaces - personally i
> > would go with asm generation but any impl working for you with a low
> > overhead is fine.
> >
> >
> >
> > >
> > > On Thu, Nov 11, 2021 at 12:54 PM Romain Manni-Bucau
> > > <rm...@gmail.com> wrote:
> > > >
> > > > Hi Clebert,
> > > >
> > > > What is the goal? Use org.apache.johnzon.api instead of a portable
> API?
> > > I'm
> > > > fine doing another shade - as javax/jakarta one - in
> > > > org.apache.johnzon.apix or any package helping if it is the idea -
> but
> > > not
> > > > sure I fully got the actual issue since from my window artemis must
> > > provide
> > > > a jakarta and a javax version of its impl - as all EE libs - so it
> could
> > > > likely be saner to solve it with a shade of artemis itself - thinking
> > > loud
> > > > to JMS first and JSON* as a consequence more than an issue by itself.
> > > >
> > > > Hope I'm not too off the actual issue.
> > > >
> > > > 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. 11 nov. 2021 à 18:32, Clebert Suconic <
> clebert.suconic@gmail.com>
> > > a
> > > > écrit :
> > > >
> > > > > As the core implementation is hard coded towards javax.json,
> Artemis
> > > > > requires using javax.json libraries as we use
> > > > >
> > > > > However we have users that require jakarta APIs, and since our
> server
> > > > > implementation relies on javax.json, we would need to provide a
> shaded
> > > > > version of our server as well.
> > > > >
> > > > > And this is honestly getting out of hand. We already provide shaded
> > > > > client libraries.. but now users want the dependency switch
> optionally
> > > > > on the server's as well.
> > > > >
> > > > > Can't we refactor the core implementation to have public
> > > > > implementations without requiring javax.json or jakarta.json? and
> then
> > > > > having a facade on top of the implementation for each binding?
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Clebert Suconic
> > > > >
> > >
> > >
> > >
> > > --
> > > Clebert Suconic
> > >
>
>
>
> --
> Clebert Suconic
>
Re: ActiveMQ Artemis: Independent core
Posted by Clebert Suconic <cl...@gmail.com>.
thing is Spring and Wildfly they are removing all libraries that have
anything to do with javax..... and I'm not sure if I provide a jakarta
library if that would create any fuss..
it doesn't make sense to me either. other than users wanting that...
let me clear that with some guys on spring and wildfly to see if I
could just use jakarta...
thanks for the help... I will figure out this first.
On Thu, Nov 11, 2021 at 3:21 PM Romain Manni-Bucau
<rm...@gmail.com> wrote:
>
> Le jeu. 11 nov. 2021 à 19:02, Clebert Suconic <cl...@gmail.com> a
> écrit :
>
> > We provide javax and jakarta libraries for our client libraries.
> >
> > and Johnzon is used internally at some places, but it's not really
> > part of the API.
> >
> > So, certain users when embedding Artemis into their server want to use
> > only jakarta libraries.
> >
> > Our server does not need the library to be jakarta, so if we had a
> > org.apache.johzon.api instead, it would make our life easier on my own
> > distribution of both libraries.
> >
>
> Have to admit it does not make much sense after some thought+testing cause
> if so, isnt javax as org.apache.johnzon for a jakarta server (and the
> opposite too)? For servers supporting both it is not an issue too.
>
> So Im quite puzzled to see any case a 3rd distro would help any user out of
> "i dont want javax" which is as arbitrary as "i dont want apache".
>
> What I think we must not do is a facade on top of javax/jakarta in our core
> cause it will be a mess in a few version when well drop javax support.
>
> If it is internal for artemis, why not just moving to jakarta? Will not
> break javax users until they use johnzon for both and if so, dropping
> yasson for the "other" impl is a workaround until both namespaces are
> merged in jakarta for the app.
>
> Overall my point is that javax is dead so it is just a migration step so we
> shouldnt have a core module abstracting both.
>
> Fine if we do a johnzon-javax-jakarta-abstraction new module we drop in 3-4
> years. Is it what you want? Do you want to PR it? Guess we dont need
> reflection at all using a small reflection check of the provider
> implemented classes and a proxy based impl for interfaces - personally i
> would go with asm generation but any impl working for you with a low
> overhead is fine.
>
>
>
> >
> > On Thu, Nov 11, 2021 at 12:54 PM Romain Manni-Bucau
> > <rm...@gmail.com> wrote:
> > >
> > > Hi Clebert,
> > >
> > > What is the goal? Use org.apache.johnzon.api instead of a portable API?
> > I'm
> > > fine doing another shade - as javax/jakarta one - in
> > > org.apache.johnzon.apix or any package helping if it is the idea - but
> > not
> > > sure I fully got the actual issue since from my window artemis must
> > provide
> > > a jakarta and a javax version of its impl - as all EE libs - so it could
> > > likely be saner to solve it with a shade of artemis itself - thinking
> > loud
> > > to JMS first and JSON* as a consequence more than an issue by itself.
> > >
> > > Hope I'm not too off the actual issue.
> > >
> > > 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. 11 nov. 2021 à 18:32, Clebert Suconic <cl...@gmail.com>
> > a
> > > écrit :
> > >
> > > > As the core implementation is hard coded towards javax.json, Artemis
> > > > requires using javax.json libraries as we use
> > > >
> > > > However we have users that require jakarta APIs, and since our server
> > > > implementation relies on javax.json, we would need to provide a shaded
> > > > version of our server as well.
> > > >
> > > > And this is honestly getting out of hand. We already provide shaded
> > > > client libraries.. but now users want the dependency switch optionally
> > > > on the server's as well.
> > > >
> > > > Can't we refactor the core implementation to have public
> > > > implementations without requiring javax.json or jakarta.json? and then
> > > > having a facade on top of the implementation for each binding?
> > > >
> > > >
> > > >
> > > > --
> > > > Clebert Suconic
> > > >
> >
> >
> >
> > --
> > Clebert Suconic
> >
--
Clebert Suconic
Re: ActiveMQ Artemis: Independent core
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Le jeu. 11 nov. 2021 à 19:02, Clebert Suconic <cl...@gmail.com> a
écrit :
> We provide javax and jakarta libraries for our client libraries.
>
> and Johnzon is used internally at some places, but it's not really
> part of the API.
>
> So, certain users when embedding Artemis into their server want to use
> only jakarta libraries.
>
> Our server does not need the library to be jakarta, so if we had a
> org.apache.johzon.api instead, it would make our life easier on my own
> distribution of both libraries.
>
Have to admit it does not make much sense after some thought+testing cause
if so, isnt javax as org.apache.johnzon for a jakarta server (and the
opposite too)? For servers supporting both it is not an issue too.
So Im quite puzzled to see any case a 3rd distro would help any user out of
"i dont want javax" which is as arbitrary as "i dont want apache".
What I think we must not do is a facade on top of javax/jakarta in our core
cause it will be a mess in a few version when well drop javax support.
If it is internal for artemis, why not just moving to jakarta? Will not
break javax users until they use johnzon for both and if so, dropping
yasson for the "other" impl is a workaround until both namespaces are
merged in jakarta for the app.
Overall my point is that javax is dead so it is just a migration step so we
shouldnt have a core module abstracting both.
Fine if we do a johnzon-javax-jakarta-abstraction new module we drop in 3-4
years. Is it what you want? Do you want to PR it? Guess we dont need
reflection at all using a small reflection check of the provider
implemented classes and a proxy based impl for interfaces - personally i
would go with asm generation but any impl working for you with a low
overhead is fine.
>
> On Thu, Nov 11, 2021 at 12:54 PM Romain Manni-Bucau
> <rm...@gmail.com> wrote:
> >
> > Hi Clebert,
> >
> > What is the goal? Use org.apache.johnzon.api instead of a portable API?
> I'm
> > fine doing another shade - as javax/jakarta one - in
> > org.apache.johnzon.apix or any package helping if it is the idea - but
> not
> > sure I fully got the actual issue since from my window artemis must
> provide
> > a jakarta and a javax version of its impl - as all EE libs - so it could
> > likely be saner to solve it with a shade of artemis itself - thinking
> loud
> > to JMS first and JSON* as a consequence more than an issue by itself.
> >
> > Hope I'm not too off the actual issue.
> >
> > 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. 11 nov. 2021 à 18:32, Clebert Suconic <cl...@gmail.com>
> a
> > écrit :
> >
> > > As the core implementation is hard coded towards javax.json, Artemis
> > > requires using javax.json libraries as we use
> > >
> > > However we have users that require jakarta APIs, and since our server
> > > implementation relies on javax.json, we would need to provide a shaded
> > > version of our server as well.
> > >
> > > And this is honestly getting out of hand. We already provide shaded
> > > client libraries.. but now users want the dependency switch optionally
> > > on the server's as well.
> > >
> > > Can't we refactor the core implementation to have public
> > > implementations without requiring javax.json or jakarta.json? and then
> > > having a facade on top of the implementation for each binding?
> > >
> > >
> > >
> > > --
> > > Clebert Suconic
> > >
>
>
>
> --
> Clebert Suconic
>
Re: ActiveMQ Artemis: Independent core
Posted by Clebert Suconic <cl...@gmail.com>.
We provide javax and jakarta libraries for our client libraries.
and Johnzon is used internally at some places, but it's not really
part of the API.
So, certain users when embedding Artemis into their server want to use
only jakarta libraries.
Our server does not need the library to be jakarta, so if we had a
org.apache.johzon.api instead, it would make our life easier on my own
distribution of both libraries.
On Thu, Nov 11, 2021 at 12:54 PM Romain Manni-Bucau
<rm...@gmail.com> wrote:
>
> Hi Clebert,
>
> What is the goal? Use org.apache.johnzon.api instead of a portable API? I'm
> fine doing another shade - as javax/jakarta one - in
> org.apache.johnzon.apix or any package helping if it is the idea - but not
> sure I fully got the actual issue since from my window artemis must provide
> a jakarta and a javax version of its impl - as all EE libs - so it could
> likely be saner to solve it with a shade of artemis itself - thinking loud
> to JMS first and JSON* as a consequence more than an issue by itself.
>
> Hope I'm not too off the actual issue.
>
> 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. 11 nov. 2021 à 18:32, Clebert Suconic <cl...@gmail.com> a
> écrit :
>
> > As the core implementation is hard coded towards javax.json, Artemis
> > requires using javax.json libraries as we use
> >
> > However we have users that require jakarta APIs, and since our server
> > implementation relies on javax.json, we would need to provide a shaded
> > version of our server as well.
> >
> > And this is honestly getting out of hand. We already provide shaded
> > client libraries.. but now users want the dependency switch optionally
> > on the server's as well.
> >
> > Can't we refactor the core implementation to have public
> > implementations without requiring javax.json or jakarta.json? and then
> > having a facade on top of the implementation for each binding?
> >
> >
> >
> > --
> > Clebert Suconic
> >
--
Clebert Suconic
Re: ActiveMQ Artemis: Independent core
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Hi Clebert,
What is the goal? Use org.apache.johnzon.api instead of a portable API? I'm
fine doing another shade - as javax/jakarta one - in
org.apache.johnzon.apix or any package helping if it is the idea - but not
sure I fully got the actual issue since from my window artemis must provide
a jakarta and a javax version of its impl - as all EE libs - so it could
likely be saner to solve it with a shade of artemis itself - thinking loud
to JMS first and JSON* as a consequence more than an issue by itself.
Hope I'm not too off the actual issue.
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. 11 nov. 2021 à 18:32, Clebert Suconic <cl...@gmail.com> a
écrit :
> As the core implementation is hard coded towards javax.json, Artemis
> requires using javax.json libraries as we use
>
> However we have users that require jakarta APIs, and since our server
> implementation relies on javax.json, we would need to provide a shaded
> version of our server as well.
>
> And this is honestly getting out of hand. We already provide shaded
> client libraries.. but now users want the dependency switch optionally
> on the server's as well.
>
> Can't we refactor the core implementation to have public
> implementations without requiring javax.json or jakarta.json? and then
> having a facade on top of the implementation for each binding?
>
>
>
> --
> Clebert Suconic
>