johnzon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Romain Manni-Bucau <rmannibu...@gmail.com>
Subject Re: Remove JAX-RS provider from jsonb jar?
Date Sat, 24 Jun 2017 12:33:11 GMT
Ok so to expose clearly my point of view (/!\ doesnt mean we cant change
things, just want it to be explicit): there are 2 philosophies in term of
packagings, the one you reference with "sing resp pcp" - you would note
that this is semantically wrong since we would need to explode the config,
reading, writing .... features to respect it ;) - and the "user entry
point" one I used for jsonb module. Concretely this one tries to avoids to
users to dig into docs just to activate a single feature. Constraint in the
framework is "how much does it cost in term of stack and additional code".
For jaxrs integration the code is trivial and small and fully optional
since it needs jsonb but jsonb doesnt need it. That is why it was
integrated. Extracting it means creating a module of 1 class with 100 lines
of code which doesnt help user experience from what I saw on years on tomee
side. In particular when you thing jsonb will first be used for jaxrs.

JAXRS being provided it shouldnt hurt end users too. Is it just about
MANIFEST.MF?


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://blog-rmannibucau.rhcloud.com> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>

2017-06-24 13:51 GMT+02:00 James Carman <james@carmanconsulting.com>:

> Well, my primary issue is that the dependency for JAX-RS is marked as
> required currently (JIRA/PR submitted).  However, I'm a big fan of the
> single responsibility principle.  The JSON-B jar should merely implement
> the JSON-B spec (IMHO).  I realize moving things around in jar files breaks
> folks, so I get why we wouldn't want to move it in 1.1.2, but we should
> consider it when we can break things.
>
> On Sat, Jun 24, 2017 at 3:19 AM Romain Manni-Bucau <rmannibucau@gmail.com>
> wrote:
>
> > Hi James
> >
> > Not sure i get what you ask. The provider is here but the api is not -
> > shouldnt be at least - mandatory normally.
> >
> > On 1.1 we can move it back to jaxrs module cause we dont have the java
> > version constraint as for 1.0 branch - which is partially why it was
> here.
> > That said we will miss jsonb in jaxrs and you can have the same complaint
> > then.
> >
> > Idea was also not to have to import 2 dependencies for it to work - just
> > import jsonb - and you can also disable it in servers so not fully sure
> > what is the actual issue :s.
> >
> >
> >
> > Le 24 juin 2017 08:45, "James Carman" <james@carmanconsulting.com> a
> > écrit :
> >
> > > While it is a common use case that folks would use JSON-B for JAX-RS
> > > payload serialization/deserialization, it is not the only use case.
> > > Perhaps we can move this provider class out of the jsonb jar and remove
> > the
> > > dependency?
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message