> 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 >> >> -- Daniel Kulp [email protected] - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
