Comments on: Jersey/JAX-RS Mule Connector http://netzooid.com/blog/2008/03/06/jerseyjax-rs-mule-connector/ gettin all zoidal on ya Sat, 24 Jul 2010 09:48:52 +0000 hourly 1 http://wordpress.org/?v=3.2.1 By: Re viagra cello. http://netzooid.com/blog/2008/03/06/jerseyjax-rs-mule-connector/comment-page-1/#comment-94652 Re viagra cello. Thu, 12 Mar 2009 09:26:44 +0000 http://netzooid.com/blog/2008/03/06/jerseyjax-rs-mule-connector/#comment-94652 <strong>Buy cheap viagra online uk....</strong> Viagra patent. Viagra. Buy viagra online. Viagra side effects. The new viagra. Viagra uk medix plus forum.... Buy cheap viagra online uk….

Viagra patent. Viagra. Buy viagra online. Viagra side effects. The new viagra. Viagra uk medix plus forum….

]]> By: Bruno Pereira http://netzooid.com/blog/2008/03/06/jerseyjax-rs-mule-connector/comment-page-1/#comment-35254 Bruno Pereira Tue, 11 Mar 2008 04:08:37 +0000 http://netzooid.com/blog/2008/03/06/jerseyjax-rs-mule-connector/#comment-35254 By the way, just to leave my thoughts on embedding Jersey. I think this should be the default options for most tools supporting JSR-311. I haven't used Jersey yet for production code, but from what I could see so far, they're doing a very good job. The parts of the JSR regarding the URI mappings (into classes and methods) and the support to multiple content-types is very helpful, and I wouldn't like to reimplement this. I developed some URI mapping logic with custom annotations before i got to know Jersey, and I definitely prefer to have it as a container feature than to implement it myself. Developing support for multiple content-type would be even greater trouble, and I will definitely skip doing this :) This seems to me as much effort as developing Hibernate Database Dialects. Why not contributing to Jersey in features they might not address very well? Just my 2 cents ;) By the way, just to leave my thoughts on embedding Jersey. I think this should be the default options for most tools supporting JSR-311. I haven’t used Jersey yet for production code, but from what I could see so far, they’re doing a very good job.

The parts of the JSR regarding the URI mappings (into classes and methods) and the support to multiple content-types is very helpful, and I wouldn’t like to reimplement this. I developed some URI mapping logic with custom annotations before i got to know Jersey, and I definitely prefer to have it as a container feature than to implement it myself.

Developing support for multiple content-type would be even greater trouble, and I will definitely skip doing this :) This seems to me as much effort as developing Hibernate Database Dialects.

Why not contributing to Jersey in features they might not address very well?

Just my 2 cents ;)

]]> By: Bruno Pereira http://netzooid.com/blog/2008/03/06/jerseyjax-rs-mule-connector/comment-page-1/#comment-35252 Bruno Pereira Tue, 11 Mar 2008 04:00:18 +0000 http://netzooid.com/blog/2008/03/06/jerseyjax-rs-mule-connector/#comment-35252 Hi Dan, i just looked this HTTP Polling Component, and I think it might help me. In the next few days we're going to discuss the queue implementation and processing, and then i'll analyse the possible options, Mule among them. Thanks again for the help. Hi Dan, i just looked this HTTP Polling Component, and I think it might help me. In the next few days we’re going to discuss the queue implementation and processing, and then i’ll analyse the possible options, Mule among them.

Thanks again for the help.

]]> By: Dan Diephouse http://netzooid.com/blog/2008/03/06/jerseyjax-rs-mule-connector/comment-page-1/#comment-35245 Dan Diephouse Tue, 11 Mar 2008 03:06:24 +0000 http://netzooid.com/blog/2008/03/06/jerseyjax-rs-mule-connector/#comment-35245 Bruno: if I understand, you're trying to find the best way to consume restful queues via Mule? All Jersey does really is make it easy to build RESTful interfaces. You could use the HTTP polling component inside Mule though to poll for new things on the queue. This configuration is a little out of date (it'll be updated by next week when our RC3 release is out), but you may want to look at this: http://www.mulesource.org/display/ABDERA/Cookbook The PollingHttpReceiver understands ETags out of the box as well. Bruno: if I understand, you’re trying to find the best way to consume restful queues via Mule?

All Jersey does really is make it easy to build RESTful interfaces. You could use the HTTP polling component inside Mule though to poll for new things on the queue. This configuration is a little out of date (it’ll be updated by next week when our RC3 release is out), but you may want to look at this:

http://www.mulesource.org/display/ABDERA/Cookbook

The PollingHttpReceiver understands ETags out of the box as well.

]]> By: Dan Diephouse http://netzooid.com/blog/2008/03/06/jerseyjax-rs-mule-connector/comment-page-1/#comment-35207 Dan Diephouse Mon, 10 Mar 2008 20:55:49 +0000 http://netzooid.com/blog/2008/03/06/jerseyjax-rs-mule-connector/#comment-35207 I'm not trying to say that CXF currently doesn't add value - it does do some cool things. Its just that in retrospect, given the quality of the RI now, it may have been better to all just work on one thing. Given Sun's past though, the RI would not have been a safe bet to make and it did suck for quite a while. I’m not trying to say that CXF currently doesn’t add value – it does do some cool things. Its just that in retrospect, given the quality of the RI now, it may have been better to all just work on one thing. Given Sun’s past though, the RI would not have been a safe bet to make and it did suck for quite a while.

]]> By: Dan Diephouse http://netzooid.com/blog/2008/03/06/jerseyjax-rs-mule-connector/comment-page-1/#comment-35205 Dan Diephouse Mon, 10 Mar 2008 20:45:33 +0000 http://netzooid.com/blog/2008/03/06/jerseyjax-rs-mule-connector/#comment-35205 Re: JAX-WS - I'm beginning to think so, yes. Companies like BEA are now completely on the JAX-WS RI band wagon because it simply doesn't make sense to invest in all these alternate solutions. JBoss is in the same boat. If Sun had approached the whole RI differently and in a more open source manner, there is a good chance I would have advocated a move to Metro instead of founding CXF. That aside, where is this value and why can't it be done by reusing the existing implementation out there? I asked this same question to Bill Burke of JBoss but never got a satisfactory reply. While the tools and services do make a difference, Jersey doesn't suck, they accept contributions/feedback quite readily. Same for the Metro team. The only thing the Metro team has done wrong IMO is broken API backward compatibility from 2.0 to 2.1. Re: JAX-WS – I’m beginning to think so, yes. Companies like BEA are now completely on the JAX-WS RI band wagon because it simply doesn’t make sense to invest in all these alternate solutions. JBoss is in the same boat. If Sun had approached the whole RI differently and in a more open source manner, there is a good chance I would have advocated a move to Metro instead of founding CXF.

That aside, where is this value and why can’t it be done by reusing the existing implementation out there? I asked this same question to Bill Burke of JBoss but never got a satisfactory reply.

While the tools and services do make a difference, Jersey doesn’t suck, they accept contributions/feedback quite readily. Same for the Metro team. The only thing the Metro team has done wrong IMO is broken API backward compatibility from 2.0 to 2.1.

]]> By: Sergey Beryozkin http://netzooid.com/blog/2008/03/06/jerseyjax-rs-mule-connector/comment-page-1/#comment-35203 Sergey Beryozkin Mon, 10 Mar 2008 19:45:30 +0000 http://netzooid.com/blog/2008/03/06/jerseyjax-rs-mule-connector/#comment-35203 Should we take it to the CXF-DEV list :-) ? That said, a couple of comments. Lets take JAXB. Everyone has it embedded, right ? I believe there's very little space fro innovation there. It's a low-level activity (dealing with schema and (un)marshalling). JAX-RS is different, this is where services are provided and there's more space for the innovation there and eventually for some healthy competition. As you'd likely agree, JAX-RS alone is not of much value, it's the combination of tools and services provided by the containers which make the difference. So I'm not quite ready to agree that CXF JAX-RS is redundant even though integrating with Jersey is an option. What would you say of at least two other non-Sun JAX-RS implementations ? Is CXF JAXWS redundant given that a good quality JAXWS reference impl is available from Sun ? Should we take it to the CXF-DEV list :-) ?
That said, a couple of comments.
Lets take JAXB. Everyone has it embedded, right ? I believe there’s very little space fro innovation there. It’s a low-level activity (dealing with schema and (un)marshalling). JAX-RS is different, this is where services are provided and there’s more space for the innovation there and eventually for some healthy competition. As you’d likely agree, JAX-RS alone is not of much value, it’s the combination of tools and services provided by the containers which make the difference.

So I’m not quite ready to agree that CXF JAX-RS is redundant even though integrating with Jersey is an option. What would you say of at least two other non-Sun JAX-RS implementations ? Is CXF JAXWS redundant given that a good quality JAXWS reference impl is available from Sun ?

]]> By: Dan Diephouse http://netzooid.com/blog/2008/03/06/jerseyjax-rs-mule-connector/comment-page-1/#comment-35030 Dan Diephouse Sun, 09 Mar 2008 18:49:34 +0000 http://netzooid.com/blog/2008/03/06/jerseyjax-rs-mule-connector/#comment-35030 I see the CXF JAX-RS implementation as kind of redundant. Why not just embed the Jersey JAX-RS implementation? Its quite emedddable... I see the CXF JAX-RS implementation as kind of redundant. Why not just embed the Jersey JAX-RS implementation? Its quite emedddable…

]]> By: Sergey Beryozkin http://netzooid.com/blog/2008/03/06/jerseyjax-rs-mule-connector/comment-page-1/#comment-34973 Sergey Beryozkin Sun, 09 Mar 2008 14:06:38 +0000 http://netzooid.com/blog/2008/03/06/jerseyjax-rs-mule-connector/#comment-34973 I'd rather see you contributing to a CXF JAX-RS implementation to make it as good or even better as Jersey :-) I’d rather see you contributing to a CXF JAX-RS implementation to make it as good or even better as Jersey :-)

]]> By: Bruno Pereira http://netzooid.com/blog/2008/03/06/jerseyjax-rs-mule-connector/comment-page-1/#comment-34878 Bruno Pereira Sat, 08 Mar 2008 17:59:03 +0000 http://netzooid.com/blog/2008/03/06/jerseyjax-rs-mule-connector/#comment-34878 Hi Dan, nice to know this Jersey connector is ready. I'd like to know something. I'm currently implementing some asynchronous operations that populate a queue that will be processed with some batch instances. We're thinking about using an Atom Feed for this queue, but haven't decided yet how we're gonna do the batch processing. The component that populates the queue exposes RESTful interfaces that manipulate plain XML (not using Atom). Does Mule have support for batch processing such content? The XMLs and the queue are not very complex. If Mule offers a nice way of processing such a queue, then I'd certainly consider using it, perhaps refactoring our RESTful interfaces to use this Jersey connector. Hi Dan, nice to know this Jersey connector is ready. I’d like to know something.

I’m currently implementing some asynchronous operations that populate a queue that will be processed with some batch instances. We’re thinking about using an Atom Feed for this queue, but haven’t decided yet how we’re gonna do the batch processing.

The component that populates the queue exposes RESTful interfaces that manipulate plain XML (not using Atom). Does Mule have support for batch processing such content? The XMLs and the queue are not very complex. If Mule offers a nice way of processing such a queue, then I’d certainly consider using it, perhaps refactoring our RESTful interfaces to use this Jersey connector.

]]>