On Thu, Jul 5, 2018 at 4:45 AM, Toni Menzel <[email protected]> wrote:

> Thanks, Ray!
> Yeah, coordination is probably the hardest part. It took me a while to
> stick together a (reliably) working but still minimal set to be usable in
> Karaf in this case.
> The viral nature of CXF and Karaf Features in general make adopting a
> rather simple usecase (in my opinion) a bad experience. But this is the
> Aries List, and the JaxRS Whiteboard implementations works very well right
> now. Thanks btw!
>
> As of PRs, well for one I resurrected the aforementioned Johnzon based
> wrapper (was called ..jsonb) and placed it into its own repo, and started
> adding support for adapter registration, which was missing at that point.
> Yes, the issue with Johnzon i found, too. Currently its best do handle it
> all embedded (as in this case).
> You think the JSONB Provider will be part of Johnzon or you see that in
> Aries JaxRS Whiteboard?
>

I think we have enough buy-in from the right people to probably be able to
make a good portion of the changes on those upstream projects. However,
since we want to add a pretty significant level of configuration to the
providers it may be best to keep that code in Aries. We'll see.



> In any case we'll need better documentation and sample projects.
>

For certain!

Sincerely,
- Ray


>
> Toni
>
> On Thu, Jul 5, 2018 at 3:19 AM, Raymond Auge <[email protected]>
> wrote:
>
>> The goal was simply to reduce the number of moving parts for the first
>> release to satisfy the RI requirements.
>>
>> Now that it's out we can proceed with additional features which weren't
>> required by the spec, such as a good JSONP & JSONB support.
>>
>> The steps I'd personally like to see will require some coordination
>> across a few related projects (none of which is hard, mostly cleaning up
>> some loose ends):
>> - the spec jars from Apache Geronimo for JSONP (javax.json 1.1) and JSONB
>> (javax.json.bind 1.0) get released with Service Loader Mediator and
>> Portable Java Contracts metadata in place
>> - some fixes to Apache Johnzon to resolve a conflict in the OSGi metadata
>> which makes their JSONP & JSONB jaxrs providers not deployable together
>> - and lastly some thin, configurable, prototype scope wrappers around
>> those providers for really flexible coordination and configuration
>>
>> PRs are always welcome :)
>>
>> - Ray
>>
>> On Wed, Jul 4, 2018 at 5:20 PM, Toni Menzel <[email protected]>
>> wrote:
>>
>>> Hi,
>>>
>>> I was using snapshots of the JaxRS Whiteboard implementation together
>>> with the johnzon based jax-rs.jsonb quite happily before it got nuked in
>>> [1].
>>>
>>> There is probably a story behind this and it happened to a pre-release
>>> (<1.0) codebase, so there is nothing to complain. But: Is there a
>>> replacement for this? Why was it removed?
>>>
>>> A potential alternative is org.apache.aries.jax.rs.jaxb.json
>>> <http://search.maven.org/#search%7Cga%7C1%7Ca%3A%22org.apache.aries.jax.rs.jaxb.json%22>
>>>  which
>>> looks.. like i can use that instead.
>>> Now, this depends on cxf being present, whereas other parts of cxf are
>>> embedded into the whiteboard bundle. So i am a little confused if you want
>>> people to use it without a visible cxf dependency?
>>> Interestingly you use a (probably worthwhile) fragement bundle in
>>> integration tests with all that cxf stuff hidden. But thats not part of the
>>> released 1.0.0 bundle-set.
>>>
>>> Can someone shed some light on this?
>>> Or, maybe i am somewhat blind?
>>>
>>> Thanks,
>>> Toni
>>>
>>> [1] https://github.com/apache/aries-jax-rs-whiteboard/commit
>>> /55cb9600054f7756e04a57362facefdde99c904e
>>>
>>> * What is Developer Ergonomics <https://medium.com/rebaze>**? *
>>>
>>>
>>>
>>> *www.rebaze.de <http://www.rebaze.de/> | www.rebaze.com
>>> <http://www.rebaze.com/> | @rebazeio <https://twitter.com/rebazeio>*
>>>
>>
>>
>>
>> --
>> *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
>>  (@rotty3000)
>> Senior Software Architect *Liferay, Inc.* <http://www.liferay.com>
>>  (@Liferay)
>> Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org>
>> (@OSGiAlliance)
>>
>
>


-- 
*Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
 (@rotty3000)
Senior Software Architect *Liferay, Inc.* <http://www.liferay.com>
 (@Liferay)
Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org> (@OSGiAlliance)

Reply via email to