activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Clebert Suconic <>
Subject Re: Artemis - CXF
Date Tue, 09 Jun 2015 13:51:21 GMT
@Andy +1

The current Rest module would need to be revamped anyways. For
instance it's using an older version of Rest-Easy, the new one has a
newer API and some dependencies we didn't want (would need to update
the version for that).

@Daniel +1 Go ahead. Change whatever you need.

On Tue, Jun 9, 2015 at 9:21 AM, Andy Taylor <> wrote:
> The Rest modules were contributed HornetQ but to be honest have never really
> been used in anger and there are no devs that have really any knowledge of
> it, in fact you are probably the most knowledgeable already Daniel :).
> Personally I see no issues with making it optional and changing what ever
> API's you need to.
> Andy
> On 09/06/15 14:13, Daniel Kulp wrote:
>>> On Jun 9, 2015, at 8:48 AM, John D. Ament <> wrote:
>>> Is this a big priority to pick up?
>> It would be my #1 priority, followed closely by OSGi support.  In the
>> whole “scratch the itch” methodology, it’s what I’m planning on working on.
>>> Resteasy is already Apache V2 licensed,
>>> so it doesn't cause a licensing conflict, though I agree being able to
>>> leverage the rest api in containers that aren't deploying resteasy would
>>> be
>>> beneficial.
>> The problem is parts of the JAX-RS APIs end up having problems if there
>> are multiple JAX-RS implementations available.   It holds onto the various
>> things in statics based on the first implementation that is found.  Thus,
>> those containers that provide JAX-RS based on CXF will have potential issues
>> if Resteasy is brought in as well.   Since Resteasy isn’t needed, it might
>> as well be made optional.     If Artemis is to provide JMS 2.0 support for
>> TomEE or ServiceMix, we need to get CXF support working.
>>> The bootstrap code is resteasy specific, but it seems to be used mostly
>>> during tests.  it seems like some of these changes would put pretty big
>>> overheads on how the rest api works.  The current rest api just takes
>>> whatever body came along and converts it to a message, and provides
>>> messages back with the streams directly.
>> I don’t think any of that would necessarily have to change, but we’ll find
>> out more as we refactor this.   It’s still JAX-RS, it’s just a matter of
>> whether its CXF or RestEasy handling the mapping and unmarshalling and such.
>> Dan
>>> On Tue, Jun 9, 2015 at 5:25 AM Daniel Kulp <> wrote:
>>>> I’m going to start working on replacing RestEASY with CXF for the
>>>> Artemis
>>>> REST stuff but wanted to start a quick discussion first about how we
>>>> should
>>>> do this.   Looking through the code briefly, I think there are three
>>>> “types” of code:
>>>> 1) Pure JAX-RS things and the object models for the mappings to/from the
>>>> rest<->JMS
>>>> 2) Some RestEASY things that could be refactored into (1).  There are a
>>>> bunch of client things (even using deprecated RestEASY classes) that can
>>>> be
>>>> refactored into (1)
>>>> 3) Pure RestEASY bootstrap things
>>>> #2 is likely a “no brainer”, IMO.   So the question is what to do about
>>>> 3?   Should we split the current artemis-rest into three modules?   On
>>>> that
>>>> would contain all the non-implementation specific things and one
>>>> specific
>>>> for CXF and one for RestEASY?    Would that be
>>>> artemis-rest-common/artemis-rest-cxf/artemis-rest-resteasy?
>>>> The other option is to try and put the CXF and RestEASY code both into
>>>> artemis-rest and declare all the deps optional+provided and try to
>>>> determine the impl that is available at runtime and do something smart.
>>>> (might be able to detect jersey as well).    That seems a bit convoluted
>>>> though.
>>>> I’m not really considering dropping RestEASY entirely for CXF, but I
>>>> suppose that is a path to mention just for completeness.
>>>> Thoughts?
>>>> --
>>>> Daniel Kulp
>>>> -
>>>> Talend Community Coder -

Clebert Suconic

View raw message