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
