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 jus
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
No, you always can override it as showed in this thread, test it if you
doubt.
Le dim. 23 sept. 2018 23:24, exabrial12 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 overri
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.
Le dim. 23 sept. 2018 21:25, exabrial12 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
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.
--
Sen
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
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 *
> 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/exabri
Le sam. 22 sept. 2018 20:28, exabrial12 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 repla
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 *
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 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
13 matches
Mail list logo
