Mailing-List: contact dev-help@activemq.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@activemq.apache.org
MIME-Version: 1.0
In-Reply-To: <5576E861.9000808@gmail.com>
References: <BB5B80FB-D066-43E1-B69D-2F76186AAC51@apache.org>
	<CAOqetn__tEpZ2cCe3yxWMbceuJPnNVacme1ZQSLy==VObFS=Bg@mail.gmail.com>
	<DAED87DD-9787-45B0-AB40-FF2258DB684E@apache.org>
	<5576E861.9000808@gmail.com>
Date: Tue, 9 Jun 2015 09:51:21 -0400
Message-ID: 
 <CAKF+bsqqECObHHxUqO9dOvNNfEUL8UR6M3wwD-MASJKvLneLkw@mail.gmail.com>
Subject: Re: Artemis - CXF
From: Clebert Suconic <clebert.suconic@gmail.com>
To: "dev@activemq.apache.org" <dev@activemq.apache.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

@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 <andy.tayls67@gmail.com> wrote:
> The Rest modules were contributed HornetQ but to be honest have never rea=
lly
> been used in anger and there are no devs that have really any knowledge o=
f
> 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 <johndament@apache.org> wrote=
:
>>> Is this a big priority to pick up?
>>
>>
>> It would be my #1 priority, followed closely by OSGi support.  In the
>> whole =E2=80=9Cscratch the itch=E2=80=9D methodology, it=E2=80=99s what =
I=E2=80=99m 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 woul=
d
>>> 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 vario=
us
>> things in statics based on the first implementation that is found.  Thus=
,
>> those containers that provide JAX-RS based on CXF will have potential is=
sues
>> if Resteasy is brought in as well.   Since Resteasy isn=E2=80=99t needed=
, it might
>> as well be made optional.     If Artemis is to provide JMS 2.0 support f=
or
>> 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=E2=80=99t think any of that would necessarily have to change, but =
we=E2=80=99ll find
>> out more as we refactor this.   It=E2=80=99s still JAX-RS, it=E2=80=99s =
just a matter of
>> whether its CXF or RestEasy handling the mapping and unmarshalling and s=
uch.
>>
>> Dan
>>
>>
>>
>>>
>>> On Tue, Jun 9, 2015 at 5:25 AM Daniel Kulp <dkulp@apache.org> wrote:
>>>
>>>>
>>>> I=E2=80=99m 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
>>>> =E2=80=9Ctypes=E2=80=9D of code:
>>>>
>>>> 1) Pure JAX-RS things and the object models for the mappings to/from t=
he
>>>> 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 c=
an
>>>> be
>>>> refactored into (1)
>>>>
>>>> 3) Pure RestEASY bootstrap things
>>>>
>>>> #2 is likely a =E2=80=9Cno brainer=E2=80=9D, 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 convolut=
ed
>>>> though.
>>>>
>>>> I=E2=80=99m not really considering dropping RestEASY entirely for CXF,=
 but I
>>>> suppose that is a path to mention just for completeness.
>>>>
>>>> Thoughts?
>>>>
>>>> --
>>>> Daniel Kulp
>>>> dkulp@apache.org - http://dankulp.com/blog
>>>> Talend Community Coder - http://coders.talend.com
>>>>
>>>>
>>
>


--=20
Clebert Suconic
http://community.jboss.org/people/clebert.suconic@jboss.com
http://clebertsuconic.blogspot.com