You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomee.apache.org by exabrial12 <ex...@gmail.com> on 2018/09/21 17:00:44 UTC

Allow User to Replace Johnzon JSON Providers

https://github.com/apache/tomee/pull/167

Hey Guys, I'd appreciate a review, discussion, and merge! Thanks



--
Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html

Re: Allow User to Replace Johnzon JSON Providers

Posted by exabrial12 <ex...@gmail.com>.
https://github.com/eclipse/eclipselink.runtime/blob/master/moxy/org.eclipse.persistence.moxy/src/org/eclipse/persistence/jaxb/rs/MOXyJsonProvider.java

Its not annontated */*



--
Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html

Re: Allow User to Replace Johnzon JSON Providers

Posted by Romain Manni-Bucau <rm...@gmail.com>.
yes and no. How do you replace tomee EJB implementation? you can't. JPA is
quite particular cause not that portable at the end usage but except JSF
other specs are very portable.

However, keep in mind that in the case of JSON, you can always replace
johnzon implementation since some years. You just need to set both
implementations as inactive (through the .active=false system prop) and add
your custom global ones to the user system property.

So to summarize:

1. you can use any custom json provider from your app
2. you can use any custom provider globally for all apps
3. you can setup any custom provider programmatically through an extension
mecanism if you prefer
4. you can ignore johnzon configuring it as ignored

This is why I'm not really following you and I don't understand what you
are trying to achieve

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 lun. 24 sept. 2018 à 15:44, exabrial12 <ex...@gmail.com> a écrit :

> I think I understand the disconnect. See TomEE plume allows for completely
> removing OpenJPA and replacing it with EclipseLink, because the non-spec
> behavior of EclipseLink (especially their JMS based cache-invalidation and
> ID batch fetching) is very useful. Similarly, we want to completely replace
> Johnzon at the server level because it's non-spec behavior is very useful.
>
> Again, this doesn't modify the default behavior of TomEE and provides a
> useful extension point to developers.
>
>
>
> --
> Sent from:
> http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html
>

Re: Allow User to Replace Johnzon JSON Providers

Posted by exabrial12 <ex...@gmail.com>.
I think I understand the disconnect. See TomEE plume allows for completely
removing OpenJPA and replacing it with EclipseLink, because the non-spec
behavior of EclipseLink (especially their JMS based cache-invalidation and
ID batch fetching) is very useful. Similarly, we want to completely replace
Johnzon at the server level because it's non-spec behavior is very useful. 

Again, this doesn't modify the default behavior of TomEE and provides a
useful extension point to developers.



--
Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html

Re: Allow User to Replace Johnzon JSON Providers

Posted by Romain Manni-Bucau <rm...@gmail.com>.
No, you always can override it as showed in this thread, test it if you
doubt.

Le dim. 23 sept. 2018 23:24, exabrial12 <ex...@gmail.com> a écrit :

> So we're in agreement? Whether it's a specification note or not, the user
> cannot replace Johnzon because it is annotated */* and necessitates an
> option to override the default behavior so the developer can select the
> proper choice for their application?
>
>
>
> --
> Sent from:
> http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html
>

Re: Allow User to Replace Johnzon JSON Providers

Posted by exabrial12 <ex...@gmail.com>.
So we're in agreement? Whether it's a specification note or not, the user
cannot replace Johnzon because it is annotated */* and necessitates an
option to override the default behavior so the developer can select the
proper choice for their application?



--
Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html

Re: Allow User to Replace Johnzon JSON Providers

Posted by Romain Manni-Bucau <rm...@gmail.com>.
Le dim. 23 sept. 2018 21:25, exabrial12 <ex...@gmail.com> a écrit :

> Sorry, posting from my phone, it's not annontated *exclusively* */*, but
> that's my point.


Yes, but both must be used to sort providers properly and it is spec
behavior.


If I never want Johnzon to handle anything, you simply
> can't change the behavior without this patch.
>

Hmm, i explained you how in previous answer. This always work since your
code is bound to the class anyway. If you do it at container level, server
evznts also allow to do it.

Also note it is a tomee choice and not a johnzon one (johnzon types are
different and these ones where adjusted after user requests)


> Keep in mind, this doesn't modify the default behavior of Tomee and
> provides
> an extension point.
>

Which is already there, this is the whole point.


>
>
> --
> Sent from:
> http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html
>

Re: Allow User to Replace Johnzon JSON Providers

Posted by exabrial12 <ex...@gmail.com>.
Sorry, posting from my phone, it's not annontated *exclusively* */*, but
that's my point. If I never want Johnzon to handle anything, you simply
can't change the behavior without this patch.

Keep in mind, this doesn't modify the default behavior of Tomee and provides
an extension point. 



--
Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html

Re: Allow User to Replace Johnzon JSON Providers

Posted by Romain Manni-Bucau <rm...@gmail.com>.
Ok so to clarify:

1. no "bug" in the stack for your case except that you app uses jaxb to
model json objects which is not clearly specified as required (think you
created a jira on that already)
2. you can use moxy if you follow the rules i mentionned - maybe the not
obvious part is cxf compares *all* types and not each one by one so tomee
application/*+json wins over moxy */*. Try to register:

@Produces(MediaType.APPLICATION_JSON)
@Consumes(MediaType.APPLICATION_JSON)
public class Moxy extends MOXyJsonProvider {
}


Le dim. 23 sept. 2018 à 00:47, exabrial12 <ex...@gmail.com> a écrit :

> > Did you think to
>
> You may be are unaware, but that phrasing is rude. Your question can be
> asked without it. I certainly don't know everything, but that's why I'm
> here.
>
>
> > register your provider on the client and ensure it was handling json?
>
> Yes. It's not being called.
> https://github.com/exabrial/johnzon-univited-guest-topart
>
>
> > Johnzon Buggy
>
> We're dealing with a vendor that doesn't understand how json works. We want
> to use our own provider because johnzon won't parse it.
>
>
>
> --
> Sent from:
> http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html
>

Re: Allow User to Replace Johnzon JSON Providers

Posted by exabrial12 <ex...@gmail.com>.
> Did you think to

You may be are unaware, but that phrasing is rude. Your question can be
asked without it. I certainly don't know everything, but that's why I'm
here. 


> register your provider on the client and ensure it was handling json?

Yes. It's not being called.
https://github.com/exabrial/johnzon-univited-guest-topart


> Johnzon Buggy

We're dealing with a vendor that doesn't understand how json works. We want
to use our own provider because johnzon won't parse it.



--
Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html

Re: Allow User to Replace Johnzon JSON Providers

Posted by Romain Manni-Bucau <rm...@gmail.com>.
Le sam. 22 sept. 2018 20:28, exabrial12 <ex...@gmail.com> a écrit :

> Johnzon is buggy :) And the JSON produced by several popular REST APIs in
> the
> real world are also buggy. This patch provides a clean way to deal with
> said
> bugs when the "correct" way fails.
>
> Also, as mentioned, Johnzon cannot be replaced. If you sent a handler for
> JSON on the JAX-RS client, TomEE *always* picks Johnzon.
>

Cxf sorts providers by their priority and between concurrent providers
prefers user ones over bus ones.

So your assumption johnzon cannot be replaced is wrong.

Did you think to register your provider on the client and ensure it was
handling json?

Side note: "is buggy" is useless until you say how. Johnzon is known to
work with jackson, gson, genson, yasson and even jettison produced api.



>
>
> --
> Sent from:
> http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html
>

Re: Allow User to Replace Johnzon JSON Providers

Posted by exabrial12 <ex...@gmail.com>.
Johnzon is buggy :) And the JSON produced by several popular REST APIs in the
real world are also buggy. This patch provides a clean way to deal with said
bugs when the "correct" way fails.

Also, as mentioned, Johnzon cannot be replaced. If you sent a handler for
JSON on the JAX-RS client, TomEE *always* picks Johnzon. 



--
Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html

Re: Allow User to Replace Johnzon JSON Providers

Posted by Romain Manni-Bucau <rm...@gmail.com>.
Hi Jonathan,

I dont understand this need since johnzon is always lower priority than
user providers so it is needed only for buggy providers which can be
wrapped in user code to avoid to configure it on the instance which is not
always possible.


Le ven. 21 sept. 2018 19:00, exabrial12 <ex...@gmail.com> a écrit :

> https://github.com/apache/tomee/pull/167
>
> Hey Guys, I'd appreciate a review, discussion, and merge! Thanks
>
>
>
> --
> Sent from:
> http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html
>