resteasy-developers — The main list for RESTEasy developers to discuss project development

Re: [Resteasy-developers] JSAPI does not include methods from inherited classes

[Weinan Li <we...@re...>]

It's here: https://issues.jboss.org/browse/RESTEASY-789

I've also added Selenium tests to automate the testing process of JSAPI :-)

Cheers,
- Weinan

On Nov 12, 2012, at 5:43 PM, Stef Epardaud <st...@ep...> wrote:

> Haha, excellent :)
> 
> On Mon, Nov 12, 2012 at 10:27:25AM +0100, Gregor Jarisch wrote:
>> Already filled out an issue - and already has been fixed (by Weinan) :-)
>> 
>> On 12.11.2012 10:15, Stef Epardaud wrote:
>>> Hi,
>>> 
>>> You should file an issue so we won't forget to fix this.
>>> 
>>> Thanks.
>>> 
>>> On Mon, Oct 22, 2012 at 03:26:37PM +0200, Gregor Jarisch wrote:
>>>> Hi,
>>>> 
>>>> we just encountered a problem with JSAPI Servlet and it's generated code.
>>>> 
>>>> We having two interfaces.
>>>> 
>>>> public interface IRestVersionInfo {
>>>>    @GET
>>>>    @Path("/{id}/currentversion")
>>>>    Integer getCurrentVersion(@PathParam("id") String id);
>>>> }
>>>> 
>>>> @Path("/store/units")
>>>> public interface IRestStore extends IRestVersionInfo {
>>>>    @GET
>>>>    @GZIP
>>>>    @Path("/{id}")
>>>>    @Produces(MediaType.APPLICATION_JSON)
>>>>    public UnitConfiguration readUnit(@PathParam("id") String id,
>>>> @QueryParam("version") Integer version) throws Exception;
>>>> }
>>>> 
>>>> calling "/store/units/12345/currentversion" from an rest client works
>>>> just fine.
>>>> Looking in the generated JSAPI file coming from the server, it's like that:
>>>> 
>>>> Instead of generating getCurrentVersion on IRestStore, it's generating
>>>> it to IRestVersionInfo.
>>>> We have several Interfaces inherting from IRestVersionInfo.
>>>> All generated Snipplets are IRestVersionInfo.getCurrentVersion, instead
>>>> of the inherited class itself.
>>>> Correct would be IRestStore.getCurrentVersion
>>>> 
>>>> Weinan, I assume it's your task?! :-)
>>>> Can you fix this?
>>>> 
>>>> Thanks, Gregor
>>>> 
>>>> -- 
>>>> Ing. Gregor Jarisch
>>>> entrepreneurship & development
>>>> 
>>>> 
>>>> ------------------------------------------------------------------------------
>>>> Everyone hates slow websites. So do we.
>>>> Make your web apps faster with AppDynamics
>>>> Download AppDynamics Lite for free today:
>>>> http://p.sf.net/sfu/appdyn_sfd2d_oct
>>>> _______________________________________________
>>>> Resteasy-developers mailing list
>>>> Res...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/resteasy-developers
>> 
>> 
>> -- 
>> Ing. Gregor Jarisch
>> entrepreneurship & development
> 
> -- 
> Stéphane Epardaud
> 
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_d2d_nov
> _______________________________________________
> Resteasy-developers mailing list
> Res...@li...
> https://lists.sourceforge.net/lists/listinfo/resteasy-developers

Re: [Resteasy-developers] JSAPI does not include methods from inherited classes

[Stef E. <st...@ep...>]

Haha, excellent :)

On Mon, Nov 12, 2012 at 10:27:25AM +0100, Gregor Jarisch wrote:
> Already filled out an issue - and already has been fixed (by Weinan) :-)
> 
> On 12.11.2012 10:15, Stef Epardaud wrote:
> > Hi,
> >
> > You should file an issue so we won't forget to fix this.
> >
> > Thanks.
> >
> > On Mon, Oct 22, 2012 at 03:26:37PM +0200, Gregor Jarisch wrote:
> >> Hi,
> >>
> >> we just encountered a problem with JSAPI Servlet and it's generated code.
> >>
> >> We having two interfaces.
> >>
> >> public interface IRestVersionInfo {
> >>     @GET
> >>     @Path("/{id}/currentversion")
> >>     Integer getCurrentVersion(@PathParam("id") String id);
> >> }
> >>
> >> @Path("/store/units")
> >> public interface IRestStore extends IRestVersionInfo {
> >>     @GET
> >>     @GZIP
> >>     @Path("/{id}")
> >>     @Produces(MediaType.APPLICATION_JSON)
> >>     public UnitConfiguration readUnit(@PathParam("id") String id,
> >> @QueryParam("version") Integer version) throws Exception;
> >> }
> >>
> >> calling "/store/units/12345/currentversion" from an rest client works
> >> just fine.
> >> Looking in the generated JSAPI file coming from the server, it's like that:
> >>
> >> Instead of generating getCurrentVersion on IRestStore, it's generating
> >> it to IRestVersionInfo.
> >> We have several Interfaces inherting from IRestVersionInfo.
> >> All generated Snipplets are IRestVersionInfo.getCurrentVersion, instead
> >> of the inherited class itself.
> >> Correct would be IRestStore.getCurrentVersion
> >>
> >> Weinan, I assume it's your task?! :-)
> >> Can you fix this?
> >>
> >> Thanks, Gregor
> >>
> >> -- 
> >> Ing. Gregor Jarisch
> >> entrepreneurship & development
> >>
> >>
> >> ------------------------------------------------------------------------------
> >> Everyone hates slow websites. So do we.
> >> Make your web apps faster with AppDynamics
> >> Download AppDynamics Lite for free today:
> >> http://p.sf.net/sfu/appdyn_sfd2d_oct
> >> _______________________________________________
> >> Resteasy-developers mailing list
> >> Res...@li...
> >> https://lists.sourceforge.net/lists/listinfo/resteasy-developers
> 
> 
> -- 
> Ing. Gregor Jarisch
> entrepreneurship & development

-- 
Stéphane Epardaud

Re: [Resteasy-developers] Programmatic Endpoint Configuration

[Stef E. <st...@ep...>]

This is very import IMO because in the past I've had to write code that produces bytecode
with javassist just for this use-case of being able to add endpoints dynamically, which
is just absurd.
Being able to configure jax-rs resources at run time is very useful for ror-like frameworks
and generally services that are dynamic by nature, such as auto-generated CRUD services for
entities (which is what I worked on). Granted, a similar thing could have been done at
compile-time with APT, but that's not always available (Play Framework doesn't support it).
-- 
Stéphane Epardaud

Re: [Resteasy-developers] JSAPI does not include methods from inherited classes

[Stef E. <st...@ep...>]

Hi,

You should file an issue so we won't forget to fix this.

Thanks.

On Mon, Oct 22, 2012 at 03:26:37PM +0200, Gregor Jarisch wrote:
> Hi,
> 
> we just encountered a problem with JSAPI Servlet and it's generated code.
> 
> We having two interfaces.
> 
> public interface IRestVersionInfo {
>     @GET
>     @Path("/{id}/currentversion")
>     Integer getCurrentVersion(@PathParam("id") String id);
> }
> 
> @Path("/store/units")
> public interface IRestStore extends IRestVersionInfo {
>     @GET
>     @GZIP
>     @Path("/{id}")
>     @Produces(MediaType.APPLICATION_JSON)
>     public UnitConfiguration readUnit(@PathParam("id") String id,
> @QueryParam("version") Integer version) throws Exception;
> }
> 
> calling "/store/units/12345/currentversion" from an rest client works
> just fine.
> Looking in the generated JSAPI file coming from the server, it's like that:
> 
> Instead of generating getCurrentVersion on IRestStore, it's generating
> it to IRestVersionInfo.
> We have several Interfaces inherting from IRestVersionInfo.
> All generated Snipplets are IRestVersionInfo.getCurrentVersion, instead
> of the inherited class itself.
> Correct would be IRestStore.getCurrentVersion
> 
> Weinan, I assume it's your task?! :-)
> Can you fix this?
> 
> Thanks, Gregor
> 
> -- 
> Ing. Gregor Jarisch
> entrepreneurship & development
> 
> 
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_sfd2d_oct
> _______________________________________________
> Resteasy-developers mailing list
> Res...@li...
> https://lists.sourceforge.net/lists/listinfo/resteasy-developers

-- 
Stéphane Epardaud

Re: [Resteasy-developers] JSAPI does not include methods from inherited classes

[Gregor J. <gr...@ja...>]

Already filled out an issue - and already has been fixed (by Weinan) :-)

On 12.11.2012 10:15, Stef Epardaud wrote:
> Hi,
>
> You should file an issue so we won't forget to fix this.
>
> Thanks.
>
> On Mon, Oct 22, 2012 at 03:26:37PM +0200, Gregor Jarisch wrote:
>> Hi,
>>
>> we just encountered a problem with JSAPI Servlet and it's generated code.
>>
>> We having two interfaces.
>>
>> public interface IRestVersionInfo {
>>     @GET
>>     @Path("/{id}/currentversion")
>>     Integer getCurrentVersion(@PathParam("id") String id);
>> }
>>
>> @Path("/store/units")
>> public interface IRestStore extends IRestVersionInfo {
>>     @GET
>>     @GZIP
>>     @Path("/{id}")
>>     @Produces(MediaType.APPLICATION_JSON)
>>     public UnitConfiguration readUnit(@PathParam("id") String id,
>> @QueryParam("version") Integer version) throws Exception;
>> }
>>
>> calling "/store/units/12345/currentversion" from an rest client works
>> just fine.
>> Looking in the generated JSAPI file coming from the server, it's like that:
>>
>> Instead of generating getCurrentVersion on IRestStore, it's generating
>> it to IRestVersionInfo.
>> We have several Interfaces inherting from IRestVersionInfo.
>> All generated Snipplets are IRestVersionInfo.getCurrentVersion, instead
>> of the inherited class itself.
>> Correct would be IRestStore.getCurrentVersion
>>
>> Weinan, I assume it's your task?! :-)
>> Can you fix this?
>>
>> Thanks, Gregor
>>
>> -- 
>> Ing. Gregor Jarisch
>> entrepreneurship & development
>>
>>
>> ------------------------------------------------------------------------------
>> Everyone hates slow websites. So do we.
>> Make your web apps faster with AppDynamics
>> Download AppDynamics Lite for free today:
>> http://p.sf.net/sfu/appdyn_sfd2d_oct
>> _______________________________________________
>> Resteasy-developers mailing list
>> Res...@li...
>> https://lists.sourceforge.net/lists/listinfo/resteasy-developers


-- 
Ing. Gregor Jarisch
entrepreneurship & development

[Resteasy-developers] PTO Mon and Tue this week

[Weinan Li <we...@re...>]

Hi Team,

	I ate bad food in the weekend and become sick. I will be back Wednesday.

Cheers,
- Weinan

Re: [Resteasy-developers] be careful of backward compatibility

[Weinan L. <we...@re...>]

-- 
Weinan Li
JBoss, Red Hat


On Tuesday, November 6, 2012 at 10:07 PM, Bill Burke wrote:

> If you are submitting a pull request to Branch_2_3, it has to be 
> backward compatible. So, if you make a change, sit back and think a bit 
> on whether it would adversely effect existing applications. I will not 
> accept pull requests on Branch_2_3 that break backward compatibility.
> 
> Now, on 3.0, I will accept breakages in backward compatibility, but only 
> after they are discussed on this list.
> 
> Thanks all and thanks for all your hard work.

Get it :-) And thanks for taking care of RESTEASY-795 Bill! 
> 
> 
> -- 
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> 
> ------------------------------------------------------------------------------
> LogMeIn Central: Instant, anywhere, Remote PC access and management.
> Stay in control, update software, and manage PCs from one command center
> Diagnose problems and improve visibility into emerging IT issues
> Automate, monitor and manage. Do more in less time with Central
> http://p.sf.net/sfu/logmein12331_d2d
> _______________________________________________
> Resteasy-developers mailing list
> Res...@li... (mailto:Res...@li...)
> https://lists.sourceforge.net/lists/listinfo/resteasy-developers
> 
> 

Re: [Resteasy-developers] Bug regarding Resteasy and CDI Decorators

[Bill B. <bb...@re...>]

You'll have to bug the CDI guys.  Resteasy's integration with CDI is 
simple, it just delegates resource class creation to CDI.


On 11/6/2012 9:15 AM, Daniel Sachse wrote:
> Hey guys,
>
> I possibly discovered a bug in the Resteasy implementation provided with
> JBoss 7.1.1.Final.
> I was playing around with Errai and JAX-RS and I discovered that when I
> add the JAX-RS annotations to the interface this works as expected.
> As soon as I start to use a CDI Decorator with the JAX-RS interface, i
> start getting the following error:
>
> /"org.jboss.weld.exceptions.UnproxyableResolutionException: WELD-001306
> Attempting to inject an unproxyable normal scoped bean Decorator….."/
> /
> /
> If I then put the JAX-RS annotations back at the implementation,
> everything works fine. Unfortunately this behavior is not working for
> me, because Errai needs the annotations at the interface to create
> client code.
>
> As I was unsure if this only happened with Errai on the classpath, I
> created a very little demo project, which exactly shows the bug I
> mentioned: https://github.com/w0mbat/RESTTest
>
> Hope you guys can confirm this as a bug and fix it soon ;)
>
> Regards,
>
> Daniel
>
>
> ------------------------------------------------------------------------------
> LogMeIn Central: Instant, anywhere, Remote PC access and management.
> Stay in control, update software, and manage PCs from one command center
> Diagnose problems and improve visibility into emerging IT issues
> Automate, monitor and manage. Do more in less time with Central
> http://p.sf.net/sfu/logmein12331_d2d
>
>
>
> _______________________________________________
> Resteasy-developers mailing list
> Res...@li...
> https://lists.sourceforge.net/lists/listinfo/resteasy-developers
>

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

[Resteasy-developers] Bug regarding Resteasy and CDI Decorators

[Daniel S. <sac...@gm...>]

Hey guys,

I possibly discovered a bug in the Resteasy implementation provided with JBoss 7.1.1.Final.
I was playing around with Errai and JAX-RS and I discovered that when I add the JAX-RS annotations to the interface this works as expected.
As soon as I start to use a CDI Decorator with the JAX-RS interface, i start getting the following error:

"org.jboss.weld.exceptions.UnproxyableResolutionException: WELD-001306 Attempting to inject an unproxyable normal scoped bean Decorator….."

If I then put the JAX-RS annotations back at the implementation, everything works fine. Unfortunately this behavior is not working for me, because Errai needs the annotations at the interface to create client code.

As I was unsure if this only happened with Errai on the classpath, I created a very little demo project, which exactly shows the bug I mentioned: https://github.com/w0mbat/RESTTest

Hope you guys can confirm this as a bug and fix it soon ;)

Regards,

Daniel

[Resteasy-developers] be careful of backward compatibility

[Bill B. <bb...@re...>]

If you are submitting a pull request to Branch_2_3, it has to be 
backward compatible.  So, if you make a change, sit back and think a bit 
on whether it would adversely effect existing applications.  I will not 
accept pull requests on Branch_2_3 that break backward compatibility.

Now, on 3.0, I will accept breakages in backward compatibility, but only 
after they are discussed on this list.

Thanks all and thanks for all your hard work.


-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

[Resteasy-developers] PTO Nov 4-5

[Weinan L. <we...@re...>]

Hi Team, 

My father is sick and I need to take care of him Monday and Tuesday. If there are anything urgent, please send me email. I'll stay at home and check email regularly. 

-- 
Weinan Li
JBoss, Red Hat

Re: [Resteasy-developers] resteasy-jackson-provider question

[Michael P. <mpa...@re...>]

thanks a lot Weinan.

On 10/31/2012 11:42 AM, Weinan Li wrote:
> I've created RESTEasy-795
> 
> And here is the patch: https://github.com/liweinan/Resteasy/compare/resteasy:Branch_2_3...liweinan:RESTEASY-795
> 
> I've added test cases in this patch and seems now RESTEasy Jackson provider could handle JAXB annotations correctly. I'll request this patch to be pulled in Branch_2_3 and
> trunk.
> 
> -- 
> Weinan Li
> JBoss, Red Hat
> 
> On Wednesday, October 31, 2012 at 10:19 AM, Weinan Li wrote:
> 
>> Hi Michael,
>>
>> I've created a showcase that could fulfill your request, could you please give a try:
>>
>>
>> git clone git://github.com/liweinan/try-resteasy.git <http://github.com/liweinan/try-resteasy.git>
>>
>> git checkout -b jackson remotes/origin/jackson
>>
>> In TestXmlResource.java I could marshal JAXB annotated class correctly using Jackson's JAXB module:
>>
>> ...
>> ObjectMapper mapper = new ObjectMapper();
>> mapper.setAnnotationIntrospector(new JaxbAnnotationIntrospector());
>>  …
>>
>> I could add this support to RESTEasy's Jackson provider by patching ResteasyJacksonProvider. I'll let you know my progress.
>>
>>
>> -- 
>> Weinan Li
>> JBoss, Red Hat
>>
>> On Tuesday, October 30, 2012 at 11:20 PM, Weinan Li wrote:
>>
>>> Hi Michael,
>>>
>>> Sorry for the long delay on this issue as I'm busy on some other issues these day. I've reproduced your problem with following code:
>>>
>>> https://gist.github.com/3980877
>>>
>>> Currently RESTEasy doesn't have a Jackson+JAXB provider, but I think it won't be difficult to create one. I'll report my progress on this. btw, could you please help to
>>> create an JIRA issue for this one: https://issues.jboss.org/browse/RESTEASY
>>> Thanks!
>>>
>>> -- 
>>> Weinan Li
>>> JBoss, Red Hat
>>>
>>> On Sunday, October 21, 2012 at 4:41 PM, Michael Pasternak wrote:
>>>
>>>>
>>>> Hi Weinan,
>>>>
>>>> On 10/21/2012 10:23 AM, Weinan Li wrote:
>>>>> Hi Michael,
>>>>>
>>>>> Could you please provide more details on your requirements?
>>>>
>>>> We model our api in the xsd, then generating java code from it,
>>>> the problem is when we create java from the schema, jaxb using java naming
>>>> convention when creating fields, but applying @XmlElement annotations to
>>>> preserve the original names, later when:
>>>>
>>>> - xml generated, it uses @XmlElement annotation names
>>>> - when json generated it uses field names
>>>>
>>>> what is creating naming inconsistency between xml and json representations.
>>>>
>>>> <dependency>
>>>> <groupId>org.jboss.resteasy</groupId>
>>>> <artifactId>resteasy-jackson-provider</artifactId>
>>>> <version>${resteasy.version}</version>
>>>>
>>>>
>>>> <resteasy.version>2.3.2.Final</resteasy.version>
>>>> <maven-jaxb22-plugin.version>0.8.1</maven-jaxb22-plugin.version>
>>>>
>>>>
>>>>>
>>>>> -- 
>>>>> Weinan Li
>>>>> JBoss, Red Hat
>>>>>
>>>>> On Sunday, October 21, 2012 at 3:47 PM, Michael Pasternak wrote:
>>>>>
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> Is there any way making jackson-provider using @XmlElement names
>>>>>> rather than field's?
>>>>>>
>>>>>> -- 
>>>>>>
>>>>>> Michael Pasternak
>>>>>> RedHat, ENG-Virtualization R&D
>>>>>>
>>>>>> ------------------------------------------------------------------------------
>>>>>> Everyone hates slow websites. So do we.
>>>>>> Make your web apps faster with AppDynamics
>>>>>> Download AppDynamics Lite for free today:
>>>>>> http://p.sf.net/sfu/appdyn_sfd2d_oct
>>>>>> _______________________________________________
>>>>>> Resteasy-developers mailing list
>>>>>> Res...@li... <mailto:Res...@li...> <mailto:Res...@li...>
>>>>>> https://lists.sourceforge.net/lists/listinfo/resteasy-developers
>>>>
>>>>
>>>> -- 
>>>>
>>>> Michael Pasternak
>>>> RedHat, ENG-Virtualization R&D
>>>
>>
>> ------------------------------------------------------------------------------
>> Everyone hates slow websites. So do we.
>> Make your web apps faster with AppDynamics
>> Download AppDynamics Lite for free today:
>> http://p.sf.net/sfu/appdyn_sfd2d_oct
>> _______________________________________________
>> Resteasy-developers mailing list
>> Res...@li... <mailto:Res...@li...>
>> https://lists.sourceforge.net/lists/listinfo/resteasy-developers
> 


-- 

Michael Pasternak
RedHat, ENG-Virtualization R&D

Re: [Resteasy-developers] resteasy-jackson-provider question

[Weinan L. <we...@re...>]

I've created RESTEasy-795  

And here is the patch: https://github.com/liweinan/Resteasy/compare/resteasy:Branch_2_3...liweinan:RESTEASY-795

I've added test cases in this patch and seems now RESTEasy Jackson provider could handle JAXB annotations correctly. I'll request this patch to be pulled in Branch_2_3 and trunk.  

--  
Weinan Li
JBoss, Red Hat


On Wednesday, October 31, 2012 at 10:19 AM, Weinan Li wrote:

> Hi Michael,  
>  
> I've created a showcase that could fulfill your request, could you please give a try:
>  
>  
> git clone git://github.com/liweinan/try-resteasy.git (http://github.com/liweinan/try-resteasy.git)
>  
> git checkout -b jackson remotes/origin/jackson
>  
> In TestXmlResource.java I could marshal JAXB annotated class correctly using Jackson's JAXB module:
>  
> ...
> ObjectMapper mapper = new ObjectMapper();
> mapper.setAnnotationIntrospector(new JaxbAnnotationIntrospector());
>   …
>  
> I could add this support to RESTEasy's Jackson provider by patching ResteasyJacksonProvider. I'll let you know my progress.
>  
>  
> --  
> Weinan Li
> JBoss, Red Hat
>  
>  
> On Tuesday, October 30, 2012 at 11:20 PM, Weinan Li wrote:
>  
> > Hi Michael,  
> >  
> > Sorry for the long delay on this issue as I'm busy on some other issues these day. I've reproduced your problem with following code:
> >  
> > https://gist.github.com/3980877
> >  
> > Currently RESTEasy doesn't have a Jackson+JAXB provider, but I think it won't be difficult to create one. I'll report my progress on this. btw, could you please help to create an JIRA issue for this one: https://issues.jboss.org/browse/RESTEASY
> >  
> > Thanks!
> >  
> > --  
> > Weinan Li
> > JBoss, Red Hat
> >  
> >  
> > On Sunday, October 21, 2012 at 4:41 PM, Michael Pasternak wrote:
> >  
> > >  
> > > Hi Weinan,
> > >  
> > > On 10/21/2012 10:23 AM, Weinan Li wrote:
> > > > Hi Michael,  
> > > >  
> > > > Could you please provide more details on your requirements?
> > >  
> > > We model our api in the xsd, then generating java code from it,
> > > the problem is when we create java from the schema, jaxb using java naming
> > > convention when creating fields, but applying @XmlElement annotations to
> > > preserve the original names, later when:
> > >  
> > > - xml generated, it uses @XmlElement annotation names
> > > - when json generated it uses field names
> > >  
> > > what is creating naming inconsistency between xml and json representations.
> > >  
> > > <dependency>
> > > <groupId>org.jboss.resteasy</groupId>
> > > <artifactId>resteasy-jackson-provider</artifactId>
> > > <version>${resteasy.version}</version>
> > >  
> > >  
> > > <resteasy.version>2.3.2.Final</resteasy.version>
> > > <maven-jaxb22-plugin.version>0.8.1</maven-jaxb22-plugin.version>
> > >  
> > >  
> > > >  
> > > > --  
> > > > Weinan Li
> > > > JBoss, Red Hat
> > > >  
> > > > On Sunday, October 21, 2012 at 3:47 PM, Michael Pasternak wrote:
> > > >  
> > > > >  
> > > > > Hi,
> > > > >  
> > > > > Is there any way making jackson-provider using @XmlElement names
> > > > > rather than field's?
> > > > >  
> > > > > --  
> > > > >  
> > > > > Michael Pasternak
> > > > > RedHat, ENG-Virtualization R&D
> > > > >  
> > > > > ------------------------------------------------------------------------------
> > > > > Everyone hates slow websites. So do we.
> > > > > Make your web apps faster with AppDynamics
> > > > > Download AppDynamics Lite for free today:
> > > > > http://p.sf.net/sfu/appdyn_sfd2d_oct
> > > > > _______________________________________________
> > > > > Resteasy-developers mailing list
> > > > > Res...@li... (mailto:Res...@li...) <mailto:Res...@li...>
> > > > > https://lists.sourceforge.net/lists/listinfo/resteasy-developers
> > > > >  
> > > >  
> > > >  
> > >  
> > >  
> > >  
> > > --  
> > >  
> > > Michael Pasternak
> > > RedHat, ENG-Virtualization R&D
> > >  
> > >  
> > >  
> >  
> >  
>  
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_sfd2d_oct
>  
> _______________________________________________
> Resteasy-developers mailing list
> Res...@li... (mailto:Res...@li...)
> https://lists.sourceforge.net/lists/listinfo/resteasy-developers
>  
>  

Re: [Resteasy-developers] resteasy-jackson-provider question

[Weinan L. <we...@re...>]

Hi Michael,  

I've created a showcase that could fulfill your request, could you please give a try:


git clone git://github.com/liweinan/try-resteasy.git

git checkout -b jackson remotes/origin/jackson

In TestXmlResource.java I could marshal JAXB annotated class correctly using Jackson's JAXB module:

...
ObjectMapper mapper = new ObjectMapper();
mapper.setAnnotationIntrospector(new JaxbAnnotationIntrospector());
  …

I could add this support to RESTEasy's Jackson provider by patching ResteasyJacksonProvider. I'll let you know my progress.


--  
Weinan Li
JBoss, Red Hat


On Tuesday, October 30, 2012 at 11:20 PM, Weinan Li wrote:

> Hi Michael,  
>  
> Sorry for the long delay on this issue as I'm busy on some other issues these day. I've reproduced your problem with following code:
>  
> https://gist.github.com/3980877
>  
> Currently RESTEasy doesn't have a Jackson+JAXB provider, but I think it won't be difficult to create one. I'll report my progress on this. btw, could you please help to create an JIRA issue for this one: https://issues.jboss.org/browse/RESTEASY
>  
> Thanks!
>  
> --  
> Weinan Li
> JBoss, Red Hat
>  
>  
> On Sunday, October 21, 2012 at 4:41 PM, Michael Pasternak wrote:
>  
> >  
> > Hi Weinan,
> >  
> > On 10/21/2012 10:23 AM, Weinan Li wrote:
> > > Hi Michael,  
> > >  
> > > Could you please provide more details on your requirements?
> >  
> > We model our api in the xsd, then generating java code from it,
> > the problem is when we create java from the schema, jaxb using java naming
> > convention when creating fields, but applying @XmlElement annotations to
> > preserve the original names, later when:
> >  
> > - xml generated, it uses @XmlElement annotation names
> > - when json generated it uses field names
> >  
> > what is creating naming inconsistency between xml and json representations.
> >  
> > <dependency>
> > <groupId>org.jboss.resteasy</groupId>
> > <artifactId>resteasy-jackson-provider</artifactId>
> > <version>${resteasy.version}</version>
> >  
> >  
> > <resteasy.version>2.3.2.Final</resteasy.version>
> > <maven-jaxb22-plugin.version>0.8.1</maven-jaxb22-plugin.version>
> >  
> >  
> > >  
> > > --  
> > > Weinan Li
> > > JBoss, Red Hat
> > >  
> > > On Sunday, October 21, 2012 at 3:47 PM, Michael Pasternak wrote:
> > >  
> > > >  
> > > > Hi,
> > > >  
> > > > Is there any way making jackson-provider using @XmlElement names
> > > > rather than field's?
> > > >  
> > > > --  
> > > >  
> > > > Michael Pasternak
> > > > RedHat, ENG-Virtualization R&D
> > > >  
> > > > ------------------------------------------------------------------------------
> > > > Everyone hates slow websites. So do we.
> > > > Make your web apps faster with AppDynamics
> > > > Download AppDynamics Lite for free today:
> > > > http://p.sf.net/sfu/appdyn_sfd2d_oct
> > > > _______________________________________________
> > > > Resteasy-developers mailing list
> > > > Res...@li... (mailto:Res...@li...) <mailto:Res...@li...>
> > > > https://lists.sourceforge.net/lists/listinfo/resteasy-developers
> > > >  
> > >  
> > >  
> >  
> >  
> >  
> > --  
> >  
> > Michael Pasternak
> > RedHat, ENG-Virtualization R&D
> >  
> >  
> >  
>  
>  

[Resteasy-developers] Resteasy 3.0-beta-1 available

[Bill B. <bb...@re...>]

JAX-RS 2.0 preview.  See more details here:

http://bill.burkecentral.com/2012/10/30/resteasy-3-0-beta-1-jax-rs-2-0-preview/

I've also submitted an Intro to JAX-RS 2.0 article to dzone, i'll let 
you know when its up.

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

Re: [Resteasy-developers] using the netty support

[Bill B. <bb...@re...>]

I haven't tried to do this yet.  You can try using the 
SpringBeanProcessor (its a BeanProcessor) and initialize it with the 
dispatcher/factory that is created by Netty adapter.

I'm in the middle of a few things this week (one of them being the 
hurricane and intermitent power outages), but I think the tools are 
there for you to use.  I can write something up later when I get the 
time.  If you can't wait, then I suggest looking at the above.  please 
post here if u figure something out.

On 10/30/2012 2:56 PM, Claudio Bantaloukas wrote:
> Hi all,
> I'd like to use the recently added netty support in resteasy to create a
> standalone web service jar. Dependencies are minimal, the documentation
> seems pretty good and I was able to produce some interesting prototypes
> in no time.
>
> However I feel stuck by lack of documentation on how to inject
> dependencies to the service handling objects.
> Where are these instantiated?
> Can I access them with spring somehow?
> Should I simply use a singleton to capture the necessary objects from
> the spring context, defeat the purpose of using spring in the first
> place and get stuff done(TM)?
> Or is there a proper way to do this?
>
> Thanks
> Claudio Bantaloukas
>
>
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_sfd2d_oct
> _______________________________________________
> Resteasy-developers mailing list
> Res...@li...
> https://lists.sourceforge.net/lists/listinfo/resteasy-developers
>

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

[Resteasy-developers] using the netty support

[Claudio B. <roc...@gm...>]

Hi all,
I'd like to use the recently added netty support in resteasy to create a 
standalone web service jar. Dependencies are minimal, the documentation 
seems pretty good and I was able to produce some interesting prototypes 
in no time.

However I feel stuck by lack of documentation on how to inject 
dependencies to the service handling objects.
Where are these instantiated?
Can I access them with spring somehow?
Should I simply use a singleton to capture the necessary objects from 
the spring context, defeat the purpose of using spring in the first 
place and get stuff done(TM)?
Or is there a proper way to do this?

Thanks
Claudio Bantaloukas

Re: [Resteasy-developers] resteasy-jackson-provider question

[Weinan L. <we...@re...>]

Hi Michael, 

Sorry for the long delay on this issue as I'm busy on some other issues these day. I've reproduced your problem with following code:

https://gist.github.com/3980877

Currently RESTEasy doesn't have a Jackson+JAXB provider, but I think it won't be difficult to create one. I'll report my progress on this. btw, could you please help to create an JIRA issue for this one: https://issues.jboss.org/browse/RESTEASY

Thanks!

-- 
Weinan Li
JBoss, Red Hat


On Sunday, October 21, 2012 at 4:41 PM, Michael Pasternak wrote:

> 
> Hi Weinan,
> 
> On 10/21/2012 10:23 AM, Weinan Li wrote:
> > Hi Michael, 
> > 
> > Could you please provide more details on your requirements?
> 
> We model our api in the xsd, then generating java code from it,
> the problem is when we create java from the schema, jaxb using java naming
> convention when creating fields, but applying @XmlElement annotations to
> preserve the original names, later when:
> 
> - xml generated, it uses @XmlElement annotation names
> - when json generated it uses field names
> 
> what is creating naming inconsistency between xml and json representations.
> 
> <dependency>
> <groupId>org.jboss.resteasy</groupId>
> <artifactId>resteasy-jackson-provider</artifactId>
> <version>${resteasy.version}</version>
> 
> 
> <resteasy.version>2.3.2.Final</resteasy.version>
> <maven-jaxb22-plugin.version>0.8.1</maven-jaxb22-plugin.version>
> 
> 
> > 
> > -- 
> > Weinan Li
> > JBoss, Red Hat
> > 
> > On Sunday, October 21, 2012 at 3:47 PM, Michael Pasternak wrote:
> > 
> > > 
> > > Hi,
> > > 
> > > Is there any way making jackson-provider using @XmlElement names
> > > rather than field's?
> > > 
> > > -- 
> > > 
> > > Michael Pasternak
> > > RedHat, ENG-Virtualization R&D
> > > 
> > > ------------------------------------------------------------------------------
> > > Everyone hates slow websites. So do we.
> > > Make your web apps faster with AppDynamics
> > > Download AppDynamics Lite for free today:
> > > http://p.sf.net/sfu/appdyn_sfd2d_oct
> > > _______________________________________________
> > > Resteasy-developers mailing list
> > > Res...@li... <mailto:Res...@li...>
> > > https://lists.sourceforge.net/lists/listinfo/resteasy-developers
> > > 
> > 
> > 
> 
> 
> 
> -- 
> 
> Michael Pasternak
> RedHat, ENG-Virtualization R&D
> 
> 

Re: [Resteasy-developers] Rest-Easy Client-side interceptors

[Ori L. <ol...@re...>]

Thanks, I looked into that but the API method in ExceptionMapper interface is: 

   Response toResponse(E exception);      //(E extends Throwable)

So I only have access to the exception. I can determine that it's a SAXParseException, and even dig in and find the text: "Premature end of file", but that's not enough to establish that the exception was thrown due to an empty request body (as opposed to a malformed xml).

So I think it's still not good enough.



----- Original Message -----
From: "Weinan Li" <we...@re...>
To: "Ori Liel" <ol...@re...>
Cc: res...@li...
Sent: Monday, October 29, 2012 2:25:35 PM
Subject: Re: [Resteasy-developers] Rest-Easy Client-side interceptors


Hi Ori, 


Maybe you could try to use Exception Mapper: http://docs.jboss.org/resteasy/docs/2.3.4.Final/userguide/html_single/#ExceptionHandling 



-- 
Weinan Li 
JBoss, Red Hat 



On Monday, October 29, 2012 at 5:22 PM, Ori Liel wrote: 




Hi, 


I have a small problem I could use some help with. 


When a user POSTs a request with an empty body, he gets 400 Bad Request with "SAXParseException; Premature end of file..." (since POST expects body). I'd like to show a friendlier message in the response body, something like: "POST request may not have empty body". 


Question 1: I'm looking for an interception point that will enable me to check if the user POSTed a request with an empty body. 


I tried using MessageBodyReaderInterceptor, but it appears that I don't have access to the Request object from the MessageBodyReaderContext object (am I wrong?) Then I noticed that ClientExecutionInterceptor seems to fit my needs, and wrote an interceptor that implements it - but the flow never reached it. 


Question 2: What are resteasy client interceptors, and how are they invoked? 


I'll elaborate a bit on the second question. Basically I'm not clear who is the 'client'. I always thought of client as the browser (or 'curl') making the http request, and resteasy runs server-side and handles the requests. So what does 'client' interceptor mean? When is a client interceptor invoked, and where does it run? Can I see it when debugging the server? Sorry for the very open question, but I'm missing something fundamental here... 


Thanks, 


Ori. 


------------------------------------------------------------------------------ 
The Windows 8 Center - In partnership with Sourceforge 
Your idea - your app - 30 days. 
Get started! 
http://windows8center.sourceforge.net / 
what-html-developers-need-to-know-about-coding-windows-8-metro-style-apps/ 
_______________________________________________ 
Resteasy-developers mailing list 
Res...@li... 
https://lists.sourceforge.net/lists/listinfo/resteasy-developers 

Re: [Resteasy-developers] Rest-Easy Client-side interceptors

[Weinan L. <we...@re...>]

Hi Ori, 

Maybe you could try to use Exception Mapper: http://docs.jboss.org/resteasy/docs/2.3.4.Final/userguide/html_single/#ExceptionHandling 

-- 
Weinan Li
JBoss, Red Hat


On Monday, October 29, 2012 at 5:22 PM, Ori Liel wrote:

> Hi, 
> 
> I have a small problem I could use some help with. 
> 
> When a user POSTs a request with an empty body, he gets 400 Bad Request with "SAXParseException; Premature end of file..." (since POST expects body). I'd like to show a friendlier message in the response body, something like: "POST request may not have empty body". 
> 
> Question 1: I'm looking for an interception point that will enable me to check if the user POSTed a request with an empty body. 
> 
> I tried using MessageBodyReaderInterceptor, but it appears that I don't have access to the Request object from the MessageBodyReaderContext object (am I wrong?) Then I noticed that ClientExecutionInterceptor seems to fit my needs, and wrote an interceptor that implements it - but the flow never reached it. 
> 
> Question 2: What are resteasy client interceptors, and how are they invoked? 
> 
> I'll elaborate a bit on the second question. Basically I'm not clear who is the 'client'. I always thought of client as the browser (or 'curl') making the http request, and resteasy runs server-side and handles the requests. So what does 'client' interceptor mean? When is a client interceptor invoked, and where does it run? Can I see it when debugging the server? Sorry for the very open question, but I'm missing something fundamental here...
> 
> Thanks, 
> 
> Ori. 
> 
> ------------------------------------------------------------------------------
> The Windows 8 Center - In partnership with Sourceforge
> Your idea - your app - 30 days.
> Get started!
> http://windows8center.sourceforge.net/
> what-html-developers-need-to-know-about-coding-windows-8-metro-style-apps/
> _______________________________________________
> Resteasy-developers mailing list
> Res...@li... (mailto:Res...@li...)
> https://lists.sourceforge.net/lists/listinfo/resteasy-developers
> 
> 

Re: [Resteasy-developers] Rest-Easy Client-side interceptors

[Ori L. <ol...@re...>]

I just want to add that PreProcessInterceptor doesn't fit either, because I have no access to the request body (there's HttpRequest object in the method parameters, but it doesn't have .getBody() method). 

----- Original Message -----
From: "Ori Liel" <ol...@re...>
To: res...@li...
Sent: Monday, October 29, 2012 11:22:11 AM
Subject: [Resteasy-developers] Rest-Easy Client-side interceptors

Hi, 

I have a small problem I could use some help with. 

When a user POSTs a request with an empty body, he gets 400 Bad Request with "SAXParseException; Premature end of file..." (since POST expects body). I'd like to show a friendlier message in the response body, something like: "POST request may not have empty body". 

  Question 1: I'm looking for an interception point that will enable me to check if the user POSTed a request with an empty body. 

I tried using MessageBodyReaderInterceptor, but it appears that I don't have access to the Request object from the MessageBodyReaderContext object (am I wrong?) Then I noticed that ClientExecutionInterceptor seems to fit my needs, and wrote an interceptor that implements it - but the flow never reached it. 

  Question 2: What are resteasy client interceptors, and how are they invoked? 

I'll elaborate a bit on the second question. Basically I'm not clear who is the 'client'. I always thought of client as the browser (or 'curl') making the http request, and resteasy runs server-side and handles the requests. So what does 'client' interceptor mean? When is a client interceptor invoked, and where does it run? Can I see it when debugging the server? Sorry for the very open question, but I'm missing something fundamental here...

Thanks, 

Ori. 

------------------------------------------------------------------------------
The Windows 8 Center - In partnership with Sourceforge
Your idea - your app - 30 days.
Get started!
http://windows8center.sourceforge.net/
what-html-developers-need-to-know-about-coding-windows-8-metro-style-apps/
_______________________________________________
Resteasy-developers mailing list
Res...@li...
https://lists.sourceforge.net/lists/listinfo/resteasy-developers

[Resteasy-developers] Rest-Easy Client-side interceptors

[Ori L. <ol...@re...>]

Hi, 

I have a small problem I could use some help with. 

When a user POSTs a request with an empty body, he gets 400 Bad Request with "SAXParseException; Premature end of file..." (since POST expects body). I'd like to show a friendlier message in the response body, something like: "POST request may not have empty body". 

  Question 1: I'm looking for an interception point that will enable me to check if the user POSTed a request with an empty body. 

I tried using MessageBodyReaderInterceptor, but it appears that I don't have access to the Request object from the MessageBodyReaderContext object (am I wrong?) Then I noticed that ClientExecutionInterceptor seems to fit my needs, and wrote an interceptor that implements it - but the flow never reached it. 

  Question 2: What are resteasy client interceptors, and how are they invoked? 

I'll elaborate a bit on the second question. Basically I'm not clear who is the 'client'. I always thought of client as the browser (or 'curl') making the http request, and resteasy runs server-side and handles the requests. So what does 'client' interceptor mean? When is a client interceptor invoked, and where does it run? Can I see it when debugging the server? Sorry for the very open question, but I'm missing something fundamental here...

Thanks, 

Ori. 

Re: [Resteasy-developers] Status this week.

[Bill B. <bb...@re...>]

ALl good Weinan...

On 10/25/2012 12:20 AM, Weinan Li wrote:
> Hi Team,
>
> Sorry I don't make much progress on RESTEasy issues at hand this week.
> I'm totally dived into JBoss EAP tasks and will be back next week. Thank
> you for your patience on my low responsiveness this week :-)
>
> --
> Weinan Li
> JBoss, Red Hat
>

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

[Resteasy-developers] Status this week.

[Weinan L. <we...@re...>]

Hi Team, 

Sorry I don't make much progress on RESTEasy issues at hand this week. I'm totally dived into JBoss EAP tasks and will be back next week. Thank you for your patience on my low responsiveness this week :-) 

-- 
Weinan Li
JBoss, Red Hat

Re: [Resteasy-developers] Programatic endpoints in RESTEasy

[Bill B. <bb...@re...>]

Please don't take any of my comments here personally.  Everybody CC'd on 
this email thread is smart and dedicated.  I think I came across as too 
combatative with them.  Apologies.  But, I'm trying to get them to 
convince me this is a good idea because it will need fundamental changes 
to Resteasy.  I honestly need to do this work because in the end, 
myself, Ron, and Wei need to maintain and support it.

Also, quite honestly, there is other work I'd much rather focus on, and 
have wnated to focus on for a long long time.  Specifically security. 
Not only that, but I've contracted with O'Reilly to update my book.  So, 
Doug, Dan, need to do some serious defending of why they want to do this.

FYI: I"m not convinced that what they want to do is a good idea.  Why 
wouldn't you just have a mobile client make HTTP invocations directly to 
a JAX-RS service?

On 10/24/2012 5:02 PM, Jay Balunas wrote:
> Hi Bill,
>
> I wanted to talk about the request Doug and Dan put in around
> programatic endpoints.  I think they did a great job of defining the
> initial feature set in the gist [1].
>
> There are a few compelling reasons to have this support that might make
> this worth reconsidering:
>
> 1) As part of a future dynamic Backend as a Service (BaaS) being able to
> programmatically create and update endpoints would be a great feature.
> 1.5) Take a look at Kinvey, or Parse for examples of this functionality.
>

I don't understand why you would want to programmatically create or 
modify HTTP request -> Java method mappings.  Seems like a bad idea to 
me.  JAx-RS is very sensative to the structure of a URL.  I can't see 
anybody ever wanting to dynamically change that a method parameter is 
mapped from a path segment to, let's say a query parameter.

I'm not a big fan of hiding remote invocations and blurring the line 
between client and server.  When I see descriptions like "	


> 2) As part of a light MVC with central routing, programatic endpoints
> let us define these in one place.
>

I disagree with this approach.  Use an MVC framework if you want to do 
MVC, why do you need JAX-RS?  Why do you even need MVC anymore now that 
we have rich clients?  Don't you realize REST is mainly a stateless 
architecture.  Now that rich clients can hold state, we don't need this 
MVC nonsense anymore.

I know Jersey has some Model-View support, but, I'm not convinced in the 
slightest that this belongs in a framework targeted to RESTful 
applications.  If work can be done to integrate Resteasy as-is to an 
existing MVC framework, that's cool, like we did with Seam and Spring 
MVC.  But don't ask me to rearchitect resteasy to do this.

Futhermore, why don't you just use Errai and their WebSocket-based 
protocol?  Then you can do all the RPC you want and not follow this 
silly idea of REST.

> 3) One feature I've been thinking about is dynamic endpoints based on
> client library requests
> 3.1) Client lib request entity "foo" but it does not exist, "/foo" is
> created with supporting methods
> 3.2) This would not be type-safe, but would be great in a JSON/dynamic world
>

I don't understand.  JAX-RS is a mapping from HTTP request to specific 
Java methods and Java types.  It is not a generic Servlet-like API.

> Also back in May when this was discussed before on the resteasy mailing
> list [2] you had mentioned about Doug driving this after 3.0.Alpha.
>   This is what Doug and Dan want to help with.
>

That was a nice way of me saying I don't find this feature important.

> So, all I'm asking is that was that talk about this a little more, see
> if there is a less invasive way of doing these changes, especially since
> Dan will be able to help and/or prototype some of this.
>

Yup let's talk, as long as you don't take offense to me being aggressive 
here.  Please please, don't take *ANY* of this personally.  I've been on 
the record for a long time internally at Red Hat as not being a fan of 
any of these web frameworks.

> Thanks,
> Jay
>
> [1] https://gist.github.com/3938238
> [2] http://sourceforge.net/mailarchive/message.php?msg_id=29626985

I'll re-read this stuff tomorrow so I can better understand where you 
guys are coming from.

The only compelling argument I've seen so far is that it could possibly 
be used to support other languages like Python, Ruby, etc. that run in 
the JVM.  Interesting, but not reason enough to bump it up on our work 
queue.

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com