@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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 >>>> [email protected] - http://dankulp.com/blog >>>> Talend Community Coder - http://coders.talend.com >>>> >>>> >> > -- Clebert Suconic http://community.jboss.org/people/[email protected] http://clebertsuconic.blogspot.com
