Comments for Marek Potociar's Blog http://marek.potociar.net Tue, 22 Nov 2011 20:23:06 +0000 hourly 1 http://wordpress.org/?v=3.1.3 Comment on On JAX-RS 2.0 from Devoxx by javajoe http://marek.potociar.net/2011/11/17/on-jax-rs-2-0-from-devoxx/comment-page-1/#comment-448 javajoe Tue, 22 Nov 2011 20:23:06 +0000 http://marek.potociar.net/?p=287#comment-448 I would argue that what you just said is largely what 90% of these MVC frameworks do. They are just controllers that can integrate with various view technologies. In some cases a pure JavaScript front end. So yes I believe there is still a need for that. Large organizations like the one I work for (PAYING ORACLE CUSTOMERS) are forced to shop around for "YET another" framework to provide this functionality. FYI - we did not need "YET another" IOC container but we did it anyway with EE 1.6. I would argue that what you just said is largely what 90% of these MVC frameworks do. They are just controllers that can integrate with various view technologies. In some cases a pure JavaScript front end. So yes I believe there is still a need for that. Large organizations like the one I work for (PAYING ORACLE CUSTOMERS) are forced to shop around for “YET another” framework to provide this functionality.

FYI – we did not need “YET another” IOC container but we did it anyway with EE 1.6.

]]> Comment on On JAX-RS 2.0 from Devoxx by Marek Potociar http://marek.potociar.net/2011/11/17/on-jax-rs-2-0-from-devoxx/comment-page-1/#comment-446 Marek Potociar Tue, 22 Nov 2011 19:05:35 +0000 http://marek.potociar.net/?p=287#comment-446 Not sure what you expected from the MVC support in JAX-RS, but if you expected JAX-RS to evolve into yet another presentation framework, that was actually never our goal. The idea was to look at JAX-RS resources as controllers and provide a direct integration layer for view frameworks, starting with JSP, but enabling others as well. Look at the original proposal: http://jcp.org/en/jsr/detail?id=339 From that perspective we are not adding any magic to make life of developers easier, but we certainly do not prevent developers from using a presentation framework of their choice. And again, coming up with an alternative to JSF was never our goal. Not sure what you expected from the MVC support in JAX-RS, but if you expected JAX-RS to evolve into yet another presentation framework, that was actually never our goal. The idea was to look at JAX-RS resources as controllers and provide a direct integration layer for view frameworks, starting with JSP, but enabling others as well. Look at the original proposal: http://jcp.org/en/jsr/detail?id=339

From that perspective we are not adding any magic to make life of developers easier, but we certainly do not prevent developers from using a presentation framework of their choice. And again, coming up with an alternative to JSF was never our goal.

]]> Comment on On JAX-RS 2.0 from Devoxx by Marek Potociar http://marek.potociar.net/2011/11/17/on-jax-rs-2-0-from-devoxx/comment-page-1/#comment-445 Marek Potociar Tue, 22 Nov 2011 18:54:27 +0000 http://marek.potociar.net/?p=287#comment-445 I would argue that the new client API is more accurate. But it's definitely a matter of taste. Also, the JAX-RS API is about half-size in terms of classes. That said, we're still in the EDR phase, so thinks can still get renamed and updated to optimise. Feel free to send concrete suggestions to the JAX-RS-SPEC users mailing list. I would argue that the new client API is more accurate. But it’s definitely a matter of taste. Also, the JAX-RS API is about half-size in terms of classes. That said, we’re still in the EDR phase, so thinks can still get renamed and updated to optimise. Feel free to send concrete suggestions to the JAX-RS-SPEC users mailing list.

]]> Comment on On JAX-RS 2.0 from Devoxx by javajoe http://marek.potociar.net/2011/11/17/on-jax-rs-2-0-from-devoxx/comment-page-1/#comment-444 javajoe Tue, 22 Nov 2011 18:29:54 +0000 http://marek.potociar.net/?p=287#comment-444 And that's the problem. Lets give a conservative estimate that 60% of projects will NOT choose JSF as there preferred web framework. Instead, we now have to go and download say Spring to use its MVC framework. The one stop shop (Java EE 1.6/1.7) is no longer a one stop shop. Now that we have Spring in our project should we just forget about JAX-RS and use the Spring's Rest support ? The same problem occurred when we needed a simple IOC container. If we were using Java EE 1.5 and wanted descent IOC we had to use Spring. Now that we have CDI we no longer have to use Spring. But wait, we do .... because we can't stand JSF and using a Servlet and JSP solution is rather antiquated. Ok, lets just bring in Spring and it's million dependencies. We are back to square one. Even worse should we use EE or Spring since EE does not provide the things we are looking for. And that’s the problem. Lets give a conservative estimate that 60% of projects will NOT choose JSF as there preferred web framework. Instead, we now have to go and download say Spring to use its MVC framework. The one stop shop (Java EE 1.6/1.7) is no longer a one stop shop. Now that we have Spring in our project should we just forget about JAX-RS and use the Spring’s Rest support ? The same problem occurred when we needed a simple IOC container. If we were using Java EE 1.5 and wanted descent IOC we had to use Spring. Now that we have CDI we no longer have to use Spring. But wait, we do …. because we can’t stand JSF and using a Servlet and JSP solution is rather antiquated. Ok, lets just bring in Spring and it’s million dependencies. We are back to square one. Even worse should we use EE or Spring since EE does not provide the things we are looking for.

]]> Comment on On JAX-RS 2.0 from Devoxx by amsellem yves http://marek.potociar.net/2011/11/17/on-jax-rs-2-0-from-devoxx/comment-page-1/#comment-442 amsellem yves Tue, 22 Nov 2011 18:09:08 +0000 http://marek.potociar.net/?p=287#comment-442 The client API seems more complicated than Jersey's existing one: ClientFactory.newClient().target(location).request(mediatype).post(body, result) seems less accurate than Client.create().resource(location).type(mediatype).post(result, body). Your post() arguments seem right – the body before – but request() to set the mediatype is very confusing and target to set the endpoint do not seems as accurate as location() or resource(). Besides, there's something not clear to me about Transition Links/Structural Links. Can you please explain where those Transition Links will be set? The HTTP body can have a structure with transitions IMO. Thanks a lot. The client API seems more complicated than Jersey’s existing one: ClientFactory.newClient().target(location).request(mediatype).post(body, result) seems less accurate than Client.create().resource(location).type(mediatype).post(result, body). Your post() arguments seem right – the body before – but request() to set the mediatype is very confusing and target to set the endpoint do not seems as accurate as location() or resource().

Besides, there’s something not clear to me about Transition Links/Structural Links. Can you please explain where those Transition Links will be set? The HTTP body can have a structure with transitions IMO.

Thanks a lot.

]]> Comment on On JAX-RS 2.0 from Devoxx by amsellem yves http://marek.potociar.net/2011/11/17/on-jax-rs-2-0-from-devoxx/comment-page-1/#comment-441 amsellem yves Tue, 22 Nov 2011 17:43:17 +0000 http://marek.potociar.net/?p=287#comment-441 Those are great news and I'm glad you look deeper into adding links to the HTTP body. Without them, HATEOAS will still be Fielding's foolish dream: but it deserves more. Navigating through links helps hiding most of the resources which uncouple clients from server. With HATEOAS, REST APIs can be reduce in the same fashion your experts reduce the number of JAX-RS 2 API classes to 14. Those are great news and I’m glad you look deeper into adding links to the HTTP body. Without them, HATEOAS will still be Fielding’s foolish dream: but it deserves more. Navigating through links helps hiding most of the resources which uncouple clients from server. With HATEOAS, REST APIs can be reduce in the same fashion your experts reduce the number of JAX-RS 2 API classes to 14.

]]> Comment on On JAX-RS 2.0 from Devoxx by Marek Potociar http://marek.potociar.net/2011/11/17/on-jax-rs-2-0-from-devoxx/comment-page-1/#comment-439 Marek Potociar Mon, 21 Nov 2011 09:23:46 +0000 http://marek.potociar.net/?p=287#comment-439 While I understand that you may not find it ideal, dropping MVC from JAX-RS means only we are not going to standardise anything as part of the spec (at the moment). It does not however preclude any proprietary extensions or integrations with any other existing MVC frameworks out there. While I understand that you may not find it ideal, dropping MVC from JAX-RS means only we are not going to standardise anything as part of the spec (at the moment). It does not however preclude any proprietary extensions or integrations with any other existing MVC frameworks out there.

]]> Comment on On JAX-RS 2.0 from Devoxx by javajoe http://marek.potociar.net/2011/11/17/on-jax-rs-2-0-from-devoxx/comment-page-1/#comment-434 javajoe Sat, 19 Nov 2011 16:17:11 +0000 http://marek.potociar.net/?p=287#comment-434 really disappointed to see you dropping the MVC support for JAX-RS 2.0. Other platforms like .net have both component based web framework (webforms) and action based framework like ASP.NET mvc. We need to keep up with our competitors. JSF is not a once size fits all web framework. We need a mvc framework that tightly integrates with all the javascript frameworks of the day. really disappointed to see you dropping the MVC support for JAX-RS 2.0. Other platforms like .net have both component based web framework (webforms) and action based framework like ASP.NET mvc. We need to keep up with our competitors. JSF is not a once size fits all web framework. We need a mvc framework that tightly integrates with all the javascript frameworks of the day.

]]> Comment on GlassFish 3.1 with Metro 2.1 is out! by greg http://marek.potociar.net/2011/03/01/glassfish-3-1-with-metro-2-1-is-out/comment-page-1/#comment-429 greg Fri, 23 Sep 2011 07:06:50 +0000 http://marek.potociar.net/?p=245#comment-429 Hi, is there any documentation how provide WS-Security using Metro/WSIT? greg Hi,
is there any documentation how provide WS-Security using Metro/WSIT?
greg

]]> Comment on GlassFish 3.1 with Metro 2.1 is out! by greg http://marek.potociar.net/2011/03/01/glassfish-3-1-with-metro-2-1-is-out/comment-page-1/#comment-428 greg Thu, 22 Sep 2011 18:10:27 +0000 http://marek.potociar.net/?p=245#comment-428 Hi, is there any documentation of workflow how provide WS-Secuirty using Metro/WSIT? How for exapmle GlassFish is doing it or others Web Applications? Hi,
is there any documentation of workflow how provide WS-Secuirty using Metro/WSIT?
How for exapmle GlassFish is doing it or others Web Applications?

]]>