http://permalink.gmane.org/gmane.comp.java.jsr311.devel hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.comp.java.jsr311.devel/75 <pre>Sorry about this - a kid was on my computer messing around. I just noticed it. Marc Hadley &lt;Marc.Hadley&lt; at &gt;...&gt; writes: above mentioned web container? as I am not on this alias. </pre> John Harby 2011-05-01T05:16:40 http://permalink.gmane.org/gmane.comp.java.jsr311.devel/74 <pre> The JSR review ballot is over: JAX-RS 2.0 was approved with 11 YES votes, 0 NO. See [1] for the full results. Thanks to everyone for the support! We'll now proceed to form the expert group. Please click on the "I would like to join this Expert Group" link on the JSR page [2] and follow the instructions to submit your nomination. [1] http://jcp.org/en/jsr/results?id=5140 [2] http://jcp.org/en/jsr/detail?id=339 Thanks, Roberto </pre> Roberto Chinnici 2011-01-25T18:44:25 http://permalink.gmane.org/gmane.comp.java.jsr311.devel/73 <pre> FYI, the JAX-RS 2.0 JSR was submitted to the JCP and is now live at http://jcp.org/en/jsr/detail?id=339. The ballot closes on January 24. --Roberto </pre> Roberto Chinnici 2011-01-12T00:22:16 http://permalink.gmane.org/gmane.comp.java.jsr311.devel/72 <pre></pre> Edward Bratt 2010-12-10T22:55:38 http://permalink.gmane.org/gmane.comp.java.jsr311.devel/71 <pre></pre> Edward Bratt 2010-12-10T20:40:59 http://permalink.gmane.org/gmane.comp.java.jsr311.devel/69 <pre>Roberto and Paul, I'm supportive. Thanks for preparing this revision; it looks good. Bill de hÓra On Thu, 2010-11-11 at 16:24 -0800, Roberto Chinnici wrote: </pre> Bill de hÓra 2010-11-18T14:30:53 http://permalink.gmane.org/gmane.comp.java.jsr311.devel/68 <pre> I do. I've just witnessed some previews of this &lt; at &gt;devoxx (thx Paul, looking good), thought I drop in some immediate thoughts Haven't considered if it should be in or out scope, open for discussion, I dunno this groups ambition nor time-schedule [client api] * Sounds like these higher-level clients might be not only request-scope but kept live (caching) clients * I also see an obvious relation to JSE here: this aligns with my general concern that JaxRS should keep being implementable on JSE as a whole. Let's not grow the habbit of depending on stuff we don't need. (this relates even somewhat to Jerome's request for the open TCK, obviously a position I'ld like to back) * what about http://hc.apache.org/ ? * about the preview I've seen on the higher level API, one thing we surely we need to be able to inject from outside are the actual http-protocol end-points: if those change I will not want to be recompining my jax-rs code. The &lt; at &gt;Path to external services should therefor be resolved rather </pre> Marc Portier 2010-11-18T12:31:40 http://permalink.gmane.org/gmane.comp.java.jsr311.devel/67 <pre>Hi there, I support it. I've added a few comments/questions here too: RESTful (Representational State Transfer) Web Services in the Java Platform. Does the new JSR need to remain compatible with the previous one? Being completely compatible seems like not a good decision. On the way between those two extremes is the possibility to keep compatibility with the previous version of the spec and only support the new features in the new style of describing your mvc based resources. In this situation, the devs have freedom to implement support in any way and keep compatibility enough so that existing clients can move their resources in a per class basis to the new spec - whenever they desire that resource to use any new feature. Does it make sense for the API to define filtering apis both for the request and response (as in the servlet api, but for each one)? This way any feature written through filters for any JAX-RS implementation would work in any other implementation. Common features are async support, 30</pre> Guilherme Silveira 2010-11-16T23:29:43 http://permalink.gmane.org/gmane.comp.java.jsr311.devel/66 <pre>Hi, I'm not a member of the mailing list, so please let me know if you let this message through. Somehow I stumbled across this thread on markmail tonight and wanted to comment: Bill de hÓra wrote: This issue came up in GlassFish/Jersey in January 2010 and I started a long forum thread about it: http://www.java.net/forum/topic/glassfish/glassfish/jax-rs-error-code-500-glassfish-html-error-page-0 It resulted in changes to both Jersey and GlassFish: https://glassfish.dev.java.net/issues/show_bug.cgi?id=11423 I thought you may be interested in this information when designing the feature. I was developing a GlassFish/Jersey/JAX-RS service for consumption by a BlackBerry app. A separate issue I ran into is that all traffic is proxied through RIM and they totally ruin the headers and error responses. Plus certain HTTP methods are not supported. Maybe look into that a bit more and see if there's anything that can be done so we could design and code the RESTful web service "the right way", bu</pre> Ryan de Laplante 2010-11-16T02:39:05 http://permalink.gmane.org/gmane.comp.java.jsr311.devel/65 <pre>This looks good, some comments I suspect this could take time to do well. Are we looking at an aggressive schedule? ;) One practical problem I've seen is that real world systems don't always return errors in the same format as requested by the client (assuming the app developer requested anything at all, again common). Simple example - tomcat/jetty throwing up html error pages. We can argue this is quality problem with the server but it's ugly on clients when it happens and the entity binding blows up. I'd like to see something that echoes the exception mapper on the server side of JAX-RS. Another possibility is allocating handlers onto response codes. I think I agree, but would like to be more precise on the requirements before starting. Even progressive download can get called 'streaming'. Would we will be abstracting away annoyances liked chunked encoding for developers? Would a Form object as per Jersey, or an &lt; at &gt;Form annotation as per RESTEasy be an option to consider? These are popular extension</pre> Bill de hÓra 2010-11-14T17:08:21 http://permalink.gmane.org/gmane.comp.java.jsr311.devel/64 <pre>Hi Roberto and Paul, Thanks for preparing this revision. This looks like a logical evolution of the current specification and as such I'm supporting it. My main concern is about TCK access for open source projects such as the Restlet Framework (http://www.restlet.org). Despite several requests (including via the JCP scholarship program), we never got access to the TCK. Could you make clear upfront what will be the business/license terms for implementations of JAX-RS 2.0 distributed under open source licenses? Best regards, Jerome -- Restlet ~ Founder and Technical Lead ~ http://www.restlet.o​rg Noelios Technologies ~ http://www.noelios.com -----Message d'origine----- De : Roberto Chinnici [mailto:roberto.chinnici-QHcLZuEGTsvQT0dZR+AlfA&lt; at &gt;public.gmane.org] Envoyé : vendredi 12 novembre 2010 01:24 À : dev-P7RKkg1NjvX6jXh9Kb39G9HuzzzSOjJt&lt; at &gt;public.gmane.org Cc : Paul Sandoz Objet : JSR311: Draft of the JAX-RS 2.0 JSR Experts, Below you'll find a draft of the JAX-RS 2.0 JSR. Since JAX-RS 1.1 closed, </pre> Jerome Louvel 2010-11-14T09:23:00 http://permalink.gmane.org/gmane.comp.java.jsr311.devel/63 <pre>I like this proposal very much and would support it. Stefan Tilkov - sent from a mobile device - On 12.11.2010, at 01:24, Roberto Chinnici &lt;roberto.chinnici-QHcLZuEGTsvQT0dZR+AlfA&lt; at &gt;public.gmane.org&gt; wrote: </pre> Stefan Tilkov 2010-11-12T17:50:07 http://permalink.gmane.org/gmane.comp.java.jsr311.devel/62 <pre> Experts, Below you'll find a draft of the JAX-RS 2.0 JSR. Since JAX-RS 1.1 closed, we've been interacting with many of you in the community, at conferences and across various forums, so hopefully you won't find any surprising items in this draft. Please send us your comments/suggestions in the next couple of weeks. In parallel, we'll be working on filling in the remaining sections marked as TBD, including the schedule and business terms. We'd like to submit the JSR in early December, so as to get it approved by the JCP Executive Committee ahead of the year-end holidays. Please let us know if you'd like to be listed as a supporter of this JSR. Thanks, Roberto &amp; Paul ======== Title: JAX-RS 2.0: The Java(TM) API for RESTful Web Services 2.0 Summary: This JSR will develop the next version of JAX-RS, the API for for RESTful (Representational State Transfer) Web Services in the Java Platform. Section 1: Identification JCP Member submitting this proposal: Oracle Corporation Name of Contact P</pre> Roberto Chinnici 2010-11-12T00:24:09 http://permalink.gmane.org/gmane.comp.java.jsr311.devel/61 <pre>Hi Andrew, First, please accept my sincere apologies for not replying, it was an email management SNAFU on my part. Next time please, metaphorically, poke me in the ribs, with a direct email if i do not reply in a timely fashion! I am not quite sure if JAX-RS currently facilitates all you require but it does have support returning a response built as appropriate, so a generic method can be passed a response builder from which it augments information. JAX-RS has the Request class: https://jsr311.dev.java.net/nonav/releases/1.1/javax/ws/rs/core/Request.html from which pre-conditions can be calculated and thus you can support deep etags. Deep etags require some degree of application integration to say how the etag is calculated (as opposed to shallow etags which can be an MD5 checksum of the bytes of the representation). We discuss this in the JavaOne 2010 presentation Roberto and I presented on JAX- RS. It may be possible to remove some of the code required for deep etag suppor</pre> Paul Sandoz 2010-10-20T08:37:46 http://permalink.gmane.org/gmane.comp.java.jsr311.devel/60 <pre>H Bill, First, please accept my sincere apologies for not replying, it was an email management SNAFU on my part. Next time please, metaphorically, poke me in the ribs, with a direct email if i do not reply in a timely fashion! I agree with your analysis and have logged an issue so we don't forget about it. https://jsr311.dev.java.net/issues/show_bug.cgi?id=105 Paul. On Jul 6, 2010, at 3:39 PM, Bill Burke wrote: </pre> Paul Sandoz 2010-10-20T08:29:10 http://permalink.gmane.org/gmane.comp.java.jsr311.devel/61 <pre>Hi Andrew, First, please accept my sincere apologies for not replying, it was an email management SNAFU on my part. Next time please, metaphorically, poke me in the ribs, with a direct email if i do not reply in a timely fashion! I am not quite sure if JAX-RS currently facilitates all you require but it does have support returning a response built as appropriate, so a generic method can be passed a response builder from which it augments information. JAX-RS has the Request class: https://jsr311.dev.java.net/nonav/releases/1.1/javax/ws/rs/core/Request.html from which pre-conditions can be calculated and thus you can support deep etags. Deep etags require some degree of application integration to say how the etag is calculated (as opposed to shallow etags which can be an MD5 checksum of the bytes of the representation). We discuss this in the JavaOne 2010 presentation Roberto and I presented on JAX- RS. It may be possible to remove some of the code required for deep etag suppor</pre> Paul Sandoz 2010-10-20T08:37:46 http://permalink.gmane.org/gmane.comp.java.jsr311.devel/60 <pre>H Bill, First, please accept my sincere apologies for not replying, it was an email management SNAFU on my part. Next time please, metaphorically, poke me in the ribs, with a direct email if i do not reply in a timely fashion! I agree with your analysis and have logged an issue so we don't forget about it. https://jsr311.dev.java.net/issues/show_bug.cgi?id=105 Paul. On Jul 6, 2010, at 3:39 PM, Bill Burke wrote: </pre> Paul Sandoz 2010-10-20T08:29:10 http://permalink.gmane.org/gmane.comp.java.jsr311.devel/59 <pre> Hi List, I've just written my first RESTful service app using Spring3's &lt; at &gt;RequestMapping and SimpleJDBCTemplate (I didn't find much need for a domain model as the business logic was pretty much expressed via SQL) One of the main challenges I faced in building a fully-fledged app was factoring out common behaviour across the HTTP verbs. QUESTION: Is there anything in the JAX-RS spec, current or planned, that facilitates this? Has anyone found satisying solutions to this in their apps? The following sorts of issues tend to be common per HTTP verb HTTP caching headers and behaviour (I'm sending Etags and returning HTTP304 to conditional requests for GET where appropriate) HTTP Response codes Error handling Appending standard JSON fragments (such as paging information) In order to be able to send all GET through a "genericGet" method, I ended up having to use Java reflection and a Command Pattern in order to dynamically invoke my service methods from my annotated controller methods. This seems i</pre> Andrew Robinson 2010-07-07T12:28:21 http://permalink.gmane.org/gmane.comp.java.jsr311.devel/58 <pre>The spec says: "If an ExceptionMapper for EJBException or subclass is not included with an appliction, then exceptions thrown by an EJB resource class or provider method MUST be treated as an EJB application exception..." An "application exception" in EJB means that the thrown exception will not automatically cause a rollback and should be propagated as-is. Following this JAX-RS/EJBException logic to the letter of the law would make it impossible for EJB applications to throw exceptions that cause transaction rollbacks. The EJB container wraps unchecked (non applicaton) exceptions within EJBException. Unchecked exceptions are required by the EJB specification to trigger a rollback unless they are annotated with &lt; at &gt;ApplicationException or ejb-jar.xml equivalent. The spec should instead just say: "If an ExceptionMapper for EJBException or subclass is not included with an appliction, then EJBException thrown by an EJB resource class or provider method MUST be unwrapped and processed as described </pre> Bill Burke 2010-07-06T13:39:11 http://permalink.gmane.org/gmane.comp.java.jsr311.devel/57 <pre>America has turned into one big prison. There are covert cameras all over the place. People are watching you through the TV in your living room. My intel says it's the Catholic Church although I can only confirm some Marines and a woman named Michelina Di Pace in Poway, CA knowing about it. There are battles being fought all over the place with propaganda and it will probably blow soon with the millenium (Christ was seen as born at 8 AD). There are people who will set your children up with the cops to put them in prison to be sex slaves for the house. It's probably going to blow too, I've heard that here and there. This is definitely not the land of the free and home of the brave, it's more like land of the bug and home of the slave. Thanks, John Harby On Fri, Dec 11, 2009 at 5:53 AM, Marc Hadley &lt;Marc.Hadley-xsfywfwIY+M&lt; at &gt;public.gmane.org&gt; wrote: </pre> John Harby 2010-01-05T12:07:19 http://permalink.gmane.org/gmane.comp.java.jsr311.devel/56 <pre>Please use the users-fknO4uJe+Sr6jXh9Kb39G9HuzzzSOjJt&lt; at &gt;public.gmane.org mailing list for Jersey-specific questions. Thanks, Marc. </pre> Marc Hadley 2009-12-11T13:53:48 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.java.jsr311.devel