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

[Resteasy-developers] Beta 3 released

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

I won't "publicly" release it until Monday, but it is on sourceforge, 
and I've updated the wiki and javadocs a bit.

Best regards,

Bill

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

[Resteasy-developers] resteasy spring integration

[Cecil N. <cec...@gm...>]

Hello- A question on resteasy and spring...
I have used resteasy to connect to my database as a test case by hard/soft
coding in a properties file.  But to do it right I am trying to switch to a
connection pool.  So I put together the applicationContext.xml file for
Spring, etc.  It isn't working yet... I have tried various approaches, but
bottom line, it looks like spring is creating instances and so is resteasy.
So when resteasy tries to get my jdbc template instance, it is always null.

Based on the wiki article on this subject, I think the resteasy spring
version is supposed to inject *after* resteasy creates the instance.  I
suspect there's more config info that I am missing.  Hope someone can point
the way here.

Thanks

Here are some snippets in case it helps:
*from web.xml*
<web-app>

    <!-- JSR 311 stuff -->
    <display-name>Archetype Created Web Application</display-name>
    <context-param>
        <param-name>resteasy.scan</param-name>
        <param-value>true</param-value>
    </context-param>

    <listener>

<listener-class>org.resteasy.plugins.server.servlet.ResteasyBootstrap</listener-class>
    </listener>

    <listener>

<listener-class>org.resteasy.plugins.server.servlet.SpringContextLoaderListener</listener-class>
    </listener>

    <servlet>
        <servlet-name>Resteasy</servlet-name>

<servlet-class>org.resteasy.plugins.server.servlet.HttpServletDispatcher</servlet-class>
    </servlet>

    <servlet-mapping>
        <servlet-name>Resteasy</servlet-name>
        <url-pattern>/*</url-pattern>
    </servlet-mapping>

    <context-param>
        <param-name>contextConfigLocation</param-name>
        <param-value>/WEB-INF/applicationContext.xml</param-value>
    </context-param>

</web-app>

*from applicationContext.xml*
    <bean id="plmwh"
        class="org.springframework.jndi.JndiObjectFactoryBean"
        lazy-init="true">
        <property name="jndiName" value="plmwh"></property>
    </bean>

    <bean id="gxoJdbcTemplate" class="gxo.dao.GXOJDBCTemplate">
        <constructor-arg value="true" />
        <property name="dataSource" ref="plmwh" />
    </bean>

    <bean id="dbquery3_dao" class="dbquery3_dao" >
        <property name="jdbcTemplate">
            <ref bean="gxoJdbcTemplate" />
        </property>
    </bean>

Re: [Resteasy-developers] RESTeasy XML content negotiation

[Christian S. <chr...@gm...>]

Hi Bill,

thanks I have checked out the latest version and it works now.

regards,
Christian

2008/4/9, Bill Burke <bb...@re...>:
>
> Ok, this is fixed in trunk/  I'm traveling the next week, so I won't be
> able to do another release in 2 weeks or so.  Please check out trunk if you
> want this bug fix.
>
> Bill
>
> Bill Burke wrote:
>
> > Ok, thanks.  I'll take a look sometime today and put out a patch
> > tomorrow.  I think I'm just not matching on properties.  I thought I was,
> > guess not.
> >
> > Christian Sadilek wrote:
> >
> > > Hi Bill,
> > >
> > > thanks for your reply. this is exactly what I tried to do:
> > >
> > > I have the following 4 methods:
> > > @ProduceMime("application/xml;schema=foo")
> > > @GET
> > > public String getMeFoo(@PathParam("obj-id") int objectId) {
> > >  return "<foo>"+objectId+"</foo>";
> > > }
> > >
> > > @ProduceMime("application/xml;schema=bar")
> > > @GET
> > > public String getMeBar(@PathParam("obj-id") int objectId) {
> > >  return "<bar>"+objectId+"</bar>";
> > > }
> > >   @ConsumeMime("application/xml;schema=foo")
> > > @PUT
> > > public void putMeFoo(String xml) {
> > >  System.out.println("foo");
> > > }
> > >   @ConsumeMime("application/xml;schema=bar")
> > > @PUT
> > > public void putMeBar(String xml) {
> > >  System.out.println("bar");
> > > }
> > >   I used the same annotations on the client interface and created it
> > > using the ProxyFactory.
> > > @GET
> > > @ProduceMime("application/xml;schema=foo")
> > > public String getMeFoo(@PathParam("obj-id") int objectId);
> > >
> > > @GET
> > > @ProduceMime("application/xml;schema=bar")
> > > public String getMeBar(@PathParam("obj-id") int objectId);
> > >   @PUT
> > > @ConsumeMime("application/xml;schema=foo")
> > > public void putMeFoo(String xml);
> > >   @PUT
> > > @ConsumeMime("application/xml;schema=bar")
> > > public void putMeBar(String xml);
> > >   However, only the "foo methods" are called (even if I call
> > > getMeBar() or putMeBar()). I tried it with beta1 and beta2.
> > > Am I doing something wrong?
> > >
> > > As far as I was able to trace the problem I end up with 4 different
> > > uriParamChildren in the root PathSegmentNode. 2 for GET and
> > > 2 for PUT. The first one to be analyzed in
> > > PathSegmentNode.findResourceInvoker always wins because the media types are
> > > compatible as MediaType.isCompatible() "only" checks for the type and
> > > subtype (not for any mime properties).
> > >
> > > Thanks again for your help.
> > >
> > > king regards,
> > > Christian Sadilek
> > >
> > > 2008/4/7, Bill Burke <bb...@re... <mailto:bb...@re...>>:
> > >
> > >    Sorry, that should be
> > >
> > >    @ConsumeMime("application/xml;schema=foo")
> > >    @PUT
> > >    public void putMe(String xml) {}
> > >
> > >
> > >    Bill Burke wrote:
> > >
> > >        Christian,
> > >
> > >        It doesn't work already?
> > >
> > >        Can't you do:
> > >
> > >        @ConsumeMime("application/xml;schema=foo")
> > >        @GET
> > >        public String getMe() {}
> > >
> > >        Or do you mean something else?
> > >
> > >
> > >        FYI, to subscribe:
> > >
> > > https://lists.sourceforge.net/lists/listinfo/resteasy-developers
> > >
> > >
> > >
> > >        Christian Sadilek wrote:
> > >
> > >            Hi Bill,
> > >
> > >            are there any plans to support MIME properties for XML
> > >            content negotiation in RESTeasy like you described in your
> > >            Blog
> > >
> > > http://bill.burkecentral.com/2008/03/05/restful-xml-content-negotitation
> > > ?
> > >
> > >            I would like to expose two different xml representations of
> > >            a resource and the solution you presented would fit
> > > perfectly.
> > >
> > >            Thank you!
> > >
> > >            I hope it's o.k. to send you this email directly. I could
> > >            not find a user forum.
> > >
> > >            kind regards,
> > >            Christian Sadilek
> > >
> > >
> > >
> > >    --    Bill Burke
> > >    JBoss, a division of Red Hat
> > >    http://bill.burkecentral.com
> > >
> > >
> > >
> >
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
>

Re: [Resteasy-developers] Issue with Resteasy JAX-RS and interfaces

[Andreas H. <a...@ho...>]

> Ok, I fixed this one to be as you said (i verified with spec committee
> on behavior).  Please checkout trunk if you want the fix.

Great! Thanks. I'll give it a spin today.

> As far as the polymorphic/dynamic resource locators, I'm not going to
> get to that for a week or so because I'm traveling starting tomorrow.
>
> I'll do a release in about 2 weeks.

Sounds good.

Andreas

Re: [Resteasy-developers] Issue with Resteasy JAX-RS and interfaces

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

Andreas Holstenson wrote:
> When looking more into this I realize that I would expect the
> following from the
> isWriteable(Class, Type, Annotation[]) method:
> 
> * Class is the actual class of what would be written
> * Type is the defined type (such as Device or List<String>)
> 
> Does that make sense?
> 
> Thanks for your speedy response!
> 
> // Andreas


Ok, I fixed this one to be as you said (i verified with spec committee 
on behavior).  Please checkout trunk if you want the fix.

As far as the polymorphic/dynamic resource locators, I'm not going to 
get to that for a week or so because I'm traveling starting tomorrow.

I'll do a release in about 2 weeks.

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

Re: [Resteasy-developers] RESTeasy XML content negotiation

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

Ok, this is fixed in trunk/  I'm traveling the next week, so I won't be 
able to do another release in 2 weeks or so.  Please check out trunk if 
you want this bug fix.

Bill

Bill Burke wrote:
> Ok, thanks.  I'll take a look sometime today and put out a patch 
> tomorrow.  I think I'm just not matching on properties.  I thought I 
> was, guess not.
> 
> Christian Sadilek wrote:
>> Hi Bill,
>>
>> thanks for your reply. this is exactly what I tried to do:
>>
>> I have the following 4 methods:
>> @ProduceMime("application/xml;schema=foo")
>> @GET
>> public String getMeFoo(@PathParam("obj-id") int objectId) {
>>   return "<foo>"+objectId+"</foo>";
>> }
>>
>> @ProduceMime("application/xml;schema=bar")
>> @GET
>> public String getMeBar(@PathParam("obj-id") int objectId) {
>>   return "<bar>"+objectId+"</bar>";
>> }
>>    
>> @ConsumeMime("application/xml;schema=foo")
>> @PUT
>> public void putMeFoo(String xml) {
>>   System.out.println("foo");
>> }
>>    
>> @ConsumeMime("application/xml;schema=bar")
>> @PUT
>> public void putMeBar(String xml) {
>>   System.out.println("bar");
>> }
>>    
>> I used the same annotations on the client interface and created it using 
>> the ProxyFactory.
>> @GET
>> @ProduceMime("application/xml;schema=foo")
>> public String getMeFoo(@PathParam("obj-id") int objectId);
>>
>> @GET
>> @ProduceMime("application/xml;schema=bar")
>> public String getMeBar(@PathParam("obj-id") int objectId);
>>    
>> @PUT
>> @ConsumeMime("application/xml;schema=foo")
>> public void putMeFoo(String xml);
>>    
>> @PUT
>> @ConsumeMime("application/xml;schema=bar")
>> public void putMeBar(String xml);
>>    
>> However, only the "foo methods" are called (even if I call getMeBar() or 
>> putMeBar()). I tried it with beta1 and beta2.
>> Am I doing something wrong?
>>
>> As far as I was able to trace the problem I end up with 4 different 
>> uriParamChildren in the root PathSegmentNode. 2 for GET and
>> 2 for PUT. The first one to be analyzed in 
>> PathSegmentNode.findResourceInvoker always wins because the media types 
>> are compatible as MediaType.isCompatible() "only" checks for the type 
>> and subtype (not for any mime properties).
>>
>> Thanks again for your help.
>>
>> king regards,
>> Christian Sadilek
>>
>> 2008/4/7, Bill Burke <bb...@re... <mailto:bb...@re...>>:
>>
>>     Sorry, that should be
>>
>>     @ConsumeMime("application/xml;schema=foo")
>>     @PUT
>>     public void putMe(String xml) {}
>>
>>
>>     Bill Burke wrote:
>>
>>         Christian,
>>
>>         It doesn't work already?
>>
>>         Can't you do:
>>
>>         @ConsumeMime("application/xml;schema=foo")
>>         @GET
>>         public String getMe() {}
>>
>>         Or do you mean something else?
>>
>>
>>         FYI, to subscribe:
>>         https://lists.sourceforge.net/lists/listinfo/resteasy-developers
>>
>>
>>
>>         Christian Sadilek wrote:
>>
>>             Hi Bill,
>>
>>             are there any plans to support MIME properties for XML
>>             content negotiation in RESTeasy like you described in your
>>             Blog
>>             http://bill.burkecentral.com/2008/03/05/restful-xml-content-negotitation?
>>
>>             I would like to expose two different xml representations of
>>             a resource and the solution you presented would fit perfectly.
>>
>>             Thank you!
>>
>>             I hope it's o.k. to send you this email directly. I could
>>             not find a user forum.
>>
>>             kind regards,
>>             Christian Sadilek
>>
>>
>>
>>     -- 
>>     Bill Burke
>>     JBoss, a division of Red Hat
>>     http://bill.burkecentral.com
>>
>>
> 

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

Re: [Resteasy-developers] Issue with Resteasy JAX-RS and interfaces

[Andreas H. <a...@ho...>]

Hello,

>  I need more information on this.  The spec says that either you put your
> annotations on an interface or on the class/superclass and not both. Can you
> show me more pseudo code?

I have attached some more code below. If the spec says that you either
annotate the interface or the class/superclass that you can mentally
remove the getSelf() defined in Device. It would move into the
concrete implementation.

interface Device {
    @GET
    Device getSelf();
}

@Path("devices")
class RootResource {
    Device getDevice(String id) {
        // lookup and return a device, which is either Device1 or Device2
    }
}

class Device1 implements Device {
    public Device getSelf() {
        return this;
    }

    @GET
    @Path("something")
    public Object getSomething() {
        // Get something
    }
}

class Device2 implements Device {
    public Device getSelf() {
        return this;
    }

    @GET
    @Path("else")
    public Object getSomethingElse() {
        // Get something else
    }
}

>  So derivatives of Device are returned from getDevice()?  The problem with
> this is a performance one.  Resteasy would have to calculate and introspect
> and match the request on every single request.  There would be no way to
> optimize.
>
>  I guess I'll have to support it...  I'll see what I can do today and get
> out a new release.
>

Yes, exactly. Thanks! Take your time with the implementation, I'm not
in a hurry.

>
>  Well, I'm in a quandry with this one.  Reason?  Generic types.  Say you
> want to write a multipart provider that matches on List<String>?  it is
> impossible to determine the generic type of the object.
>
>  I switch it to matching on the returned entity's class.

When looking more into this I realize that I would expect the
following from the
isWriteable(Class, Type, Annotation[]) method:

* Class is the actual class of what would be written
* Type is the defined type (such as Device or List<String>)

Does that make sense?

Thanks for your speedy response!

// Andreas

Re: [Resteasy-developers] Issue with Resteasy JAX-RS and interfaces

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

Andreas Holstenson wrote:
> Hello,
> 
> I have recently started testing Resteasy JAX-RS. I'm extremely happy so far,
> but I have run into a few problems. I have a application that was working
> with Jersey that is now deployed on Resteasy. The problem here is the
> following:
> 
> I have a method in my root resource that returns an interface called Device
> such as:
> 
> @Path("{id}")
> Device getDevice(@PathParam("id") String id);
> 
> The device interface in turn has JAX-RS annotations on it:
> 
> interface Device {
>        @GET
>        Device getSelf();
> }
> 
> The device implementation have several implementations that each one have
> different JAX-RS resource. My problem is that it seems to be impossible reach
> those resources as it seems that Resteasy always works against the interface
> for lookups.
> 

I need more information on this.  The spec says that either you put your 
annotations on an interface or on the class/superclass and not both. 
Can you show me more pseudo code?

So derivatives of Device are returned from getDevice()?  The problem 
with this is a performance one.  Resteasy would have to calculate and 
introspect and match the request on every single request.  There would 
be no way to optimize.

I guess I'll have to support it...  I'll see what I can do today and get 
out a new release.


> Is this the intended behavior? I don't remember what the JSR says about this,
> but it worked fine with Jersey.
> 
> Also on a related note it seems that MessageBodyWriter.isWriteable(Class,
> Type, Annotation[]) gets passed the declared type of the method instead of
> the actual class of the return value. This caused problems with JAXBProvider
> as my concrete implementations had a @XmlRootElement annotation but the
> actual Device implementation did not.
> 

Well, I'm in a quandry with this one.  Reason?  Generic types.  Say you 
want to write a multipart provider that matches on List<String>?  it is 
impossible to determine the generic type of the object.

I switch it to matching on the returned entity's class.

Bill

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

[Resteasy-developers] Issue with Resteasy JAX-RS and interfaces

[Andreas H. <a...@ho...>]

Hello,

I have recently started testing Resteasy JAX-RS. I'm extremely happy so far,
but I have run into a few problems. I have a application that was working
with Jersey that is now deployed on Resteasy. The problem here is the
following:

I have a method in my root resource that returns an interface called Device
such as:

@Path("{id}")
Device getDevice(@PathParam("id") String id);

The device interface in turn has JAX-RS annotations on it:

interface Device {
       @GET
       Device getSelf();
}

The device implementation have several implementations that each one have
different JAX-RS resource. My problem is that it seems to be impossible reach
those resources as it seems that Resteasy always works against the interface
for lookups.

Is this the intended behavior? I don't remember what the JSR says about this,
but it worked fine with Jersey.

Also on a related note it seems that MessageBodyWriter.isWriteable(Class,
Type, Annotation[]) gets passed the declared type of the method instead of
the actual class of the return value. This caused problems with JAXBProvider
as my concrete implementations had a @XmlRootElement annotation but the
actual Device implementation did not.

Oh, both of these issues are tested against 1.0-beta-2, as I don't have time
right now to check against the trunk.

// Andreas Holstenson

[Resteasy-developers] Issue with Resteasy JAX-RS and interfaces

[Andreas <a...@ho...>]

Hello,

I have recently started testing Resteasy JAX-RS. I'm extremely happy so far, 
but I have run into a few problems. I have a application that was working 
with Jersey that is now deployed on Resteasy. The problem here is the 
following:

I have a method in my root resource that returns an interface called Device 
such as:

@Path("{id}")
Device getDevice(@PathParam("id") String id);

The device interface in turn has JAX-RS annotations on it:

interface Device {
	@GET
	Device getSelf();
}

The device implementation have several implementations that each one have 
different JAX-RS resource. My problem is that it seems to be impossible reach 
those resources as it seems that Resteasy always works against the interface 
for lookups.

Is this the intended behavior? I don't remember what the JSR says about this, 
but it worked fine with Jersey.

Also on a related note it seems that MessageBodyWriter.isWriteable(Class, 
Type, Annotation[]) gets passed the declared type of the method instead of 
the actual class of the return value. This caused problems with JAXBProvider 
as my concrete implementations had a @XmlRootElement annotation but the 
actual Device implementation did not.

Oh, both of these issues are tested against 1.0-beta-2, as I don't have time 
right now to check against the trunk.

// Andreas Holstenson

Re: [Resteasy-developers] RESTeasy XML content negotiation

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

Ok, thanks.  I'll take a look sometime today and put out a patch 
tomorrow.  I think I'm just not matching on properties.  I thought I 
was, guess not.

Christian Sadilek wrote:
> Hi Bill,
> 
> thanks for your reply. this is exactly what I tried to do:
> 
> I have the following 4 methods:
> @ProduceMime("application/xml;schema=foo")
> @GET
> public String getMeFoo(@PathParam("obj-id") int objectId) {
>   return "<foo>"+objectId+"</foo>";
> }
> 
> @ProduceMime("application/xml;schema=bar")
> @GET
> public String getMeBar(@PathParam("obj-id") int objectId) {
>   return "<bar>"+objectId+"</bar>";
> }
>    
> @ConsumeMime("application/xml;schema=foo")
> @PUT
> public void putMeFoo(String xml) {
>   System.out.println("foo");
> }
>    
> @ConsumeMime("application/xml;schema=bar")
> @PUT
> public void putMeBar(String xml) {
>   System.out.println("bar");
> }
>    
> I used the same annotations on the client interface and created it using 
> the ProxyFactory.
> @GET
> @ProduceMime("application/xml;schema=foo")
> public String getMeFoo(@PathParam("obj-id") int objectId);
> 
> @GET
> @ProduceMime("application/xml;schema=bar")
> public String getMeBar(@PathParam("obj-id") int objectId);
>    
> @PUT
> @ConsumeMime("application/xml;schema=foo")
> public void putMeFoo(String xml);
>    
> @PUT
> @ConsumeMime("application/xml;schema=bar")
> public void putMeBar(String xml);
>    
> However, only the "foo methods" are called (even if I call getMeBar() or 
> putMeBar()). I tried it with beta1 and beta2.
> Am I doing something wrong?
> 
> As far as I was able to trace the problem I end up with 4 different 
> uriParamChildren in the root PathSegmentNode. 2 for GET and
> 2 for PUT. The first one to be analyzed in 
> PathSegmentNode.findResourceInvoker always wins because the media types 
> are compatible as MediaType.isCompatible() "only" checks for the type 
> and subtype (not for any mime properties).
> 
> Thanks again for your help.
> 
> king regards,
> Christian Sadilek
> 
> 2008/4/7, Bill Burke <bb...@re... <mailto:bb...@re...>>:
> 
>     Sorry, that should be
> 
>     @ConsumeMime("application/xml;schema=foo")
>     @PUT
>     public void putMe(String xml) {}
> 
> 
>     Bill Burke wrote:
> 
>         Christian,
> 
>         It doesn't work already?
> 
>         Can't you do:
> 
>         @ConsumeMime("application/xml;schema=foo")
>         @GET
>         public String getMe() {}
> 
>         Or do you mean something else?
> 
> 
>         FYI, to subscribe:
>         https://lists.sourceforge.net/lists/listinfo/resteasy-developers
> 
> 
> 
>         Christian Sadilek wrote:
> 
>             Hi Bill,
> 
>             are there any plans to support MIME properties for XML
>             content negotiation in RESTeasy like you described in your
>             Blog
>             http://bill.burkecentral.com/2008/03/05/restful-xml-content-negotitation?
> 
>             I would like to expose two different xml representations of
>             a resource and the solution you presented would fit perfectly.
> 
>             Thank you!
> 
>             I hope it's o.k. to send you this email directly. I could
>             not find a user forum.
> 
>             kind regards,
>             Christian Sadilek
> 
> 
> 
>     -- 
>     Bill Burke
>     JBoss, a division of Red Hat
>     http://bill.burkecentral.com
> 
> 

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

[Resteasy-developers] BETA-2 released

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

http://bill.burkecentral.com/2008/04/07/resteasy-jax-rs-10-beta-2-released/

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

Re: [Resteasy-developers] WebApplicationException and http status codes

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

K, if u download BETA 2, everything should be cool.



Bill Burke wrote:
> Oh geez.  Thanks Thomas!
> 
> here I thought I was going to be able to release today....
> 
> :)
> 
> I'll have something out tomorrow.
> 
> Thomas T. Cremers wrote:
>> Hello,
>>
>> A couple of days ago I ran into a problem with throwing WebApplication 
>> examples with a response object:
>>
>> throw new WebApplicationException(Response.status(412)
>>                                                        
>> .type("text/plain;charset=utf-8")
>>                                                        
>> .entity("Something went wrong").build());
>>
>> Throwing this exception would give a text/plain body with the entity 
>> body but with http code 200. Throwing the same exception without an 
>> entity would give the expected (412 response with an empty body).
>>
>> After a little code browsing I found the problem in Dispatcher.java 
>> invoke method. I created a patch file from revision 133 attached to this 
>> email.
>>
>> Regards,
>>
>> Thomas Cremers
>>
>>
>>
>> ------------------------------------------------------------------------
>>
>> -------------------------------------------------------------------------
>> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
>> Register now and save $200. Hurry, offer ends at 11:59 p.m., 
>> Monday, April 7! Use priority code J8TLD2. 
>> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> 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

Re: [Resteasy-developers] WebApplicationException and http status codes

[Thomas C. <ttc...@gm...>]

Hey Bill,

That's fast! I will update tomorrow.

Thanks,

Thomas


On Apr 7, 2008, at 9:08 PM, Bill Burke wrote:

> K, if u download BETA 2, everything should be cool.
>
>
>
> Bill Burke wrote:
>> Oh geez.  Thanks Thomas!
>> here I thought I was going to be able to release today....
>> :)
>> I'll have something out tomorrow.
>> Thomas T. Cremers wrote:
>>> Hello,
>>>
>>> A couple of days ago I ran into a problem with throwing  
>>> WebApplication examples with a response object:
>>>
>>> throw new WebApplicationException(Response.status(412)
>>>                                                       .type("text/ 
>>> plain;charset=utf-8")
>>>                                                       .entity 
>>> ("Something went wrong").build());
>>>
>>> Throwing this exception would give a text/plain body with the  
>>> entity body but with http code 200. Throwing the same exception  
>>> without an entity would give the expected (412 response with an  
>>> empty body).
>>>
>>> After a little code browsing I found the problem in  
>>> Dispatcher.java invoke method. I created a patch file from  
>>> revision 133 attached to this email.
>>>
>>> Regards,
>>>
>>> Thomas Cremers
>>>
>>>
>>>
>>> ------------------------------------------------------------------------
>>>
>>> -------------------------------------------------------------------------
>>> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference  
>>> Register now and save $200. Hurry, offer ends at 11:59 p.m.,  
>>> Monday, April 7! Use priority code J8TLD2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
>>>
>>>
>>> ------------------------------------------------------------------------
>>>
>>> _______________________________________________
>>> 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

Re: [Resteasy-developers] RESTeasy XML content negotiation

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

Sorry, that should be

@ConsumeMime("application/xml;schema=foo")
@PUT
public void putMe(String xml) {}

Bill Burke wrote:
> Christian,
> 
> It doesn't work already?
> 
> Can't you do:
> 
> @ConsumeMime("application/xml;schema=foo")
> @GET
> public String getMe() {}
> 
> Or do you mean something else?
> 
> 
> FYI, to subscribe:
> https://lists.sourceforge.net/lists/listinfo/resteasy-developers
> 
> 
> 
> Christian Sadilek wrote:
>> Hi Bill,
>>
>> are there any plans to support MIME properties for XML content 
>> negotiation in RESTeasy like you described in your Blog 
>> http://bill.burkecentral.com/2008/03/05/restful-xml-content-negotitation?
>>
>> I would like to expose two different xml representations of a resource 
>> and the solution you presented would fit perfectly.
>>
>> Thank you!
>>
>> I hope it's o.k. to send you this email directly. I could not find a 
>> user forum.
>>
>> kind regards,
>> Christian Sadilek
> 

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

Re: [Resteasy-developers] RESTeasy XML content negotiation

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

Christian,

It doesn't work already?

Can't you do:

@ConsumeMime("application/xml;schema=foo")
@GET
public String getMe() {}

Or do you mean something else?


FYI, to subscribe:
https://lists.sourceforge.net/lists/listinfo/resteasy-developers



Christian Sadilek wrote:
> Hi Bill,
> 
> are there any plans to support MIME properties for XML content 
> negotiation in RESTeasy like you described in your Blog 
> http://bill.burkecentral.com/2008/03/05/restful-xml-content-negotitation?
> 
> I would like to expose two different xml representations of a resource 
> and the solution you presented would fit perfectly.
> 
> Thank you!
> 
> I hope it's o.k. to send you this email directly. I could not find a 
> user forum.
> 
> kind regards,
> Christian Sadilek

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

Re: [Resteasy-developers] WebApplicationException and http status codes

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

Oh geez.  Thanks Thomas!

here I thought I was going to be able to release today....

:)

I'll have something out tomorrow.

Thomas T. Cremers wrote:
> 
> Hello,
> 
> A couple of days ago I ran into a problem with throwing WebApplication 
> examples with a response object:
> 
> throw new WebApplicationException(Response.status(412)
>                                                        
> .type("text/plain;charset=utf-8")
>                                                        
> .entity("Something went wrong").build());
> 
> Throwing this exception would give a text/plain body with the entity 
> body but with http code 200. Throwing the same exception without an 
> entity would give the expected (412 response with an empty body).
> 
> After a little code browsing I found the problem in Dispatcher.java 
> invoke method. I created a patch file from revision 133 attached to this 
> email.
> 
> Regards,
> 
> Thomas Cremers
> 
> 
> 
> ------------------------------------------------------------------------
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
> Register now and save $200. Hurry, offer ends at 11:59 p.m., 
> Monday, April 7! Use priority code J8TLD2. 
> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> 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] WebApplicationException and http status codes

[Thomas T. C. <ttc...@gm...>]

Hello,

A couple of days ago I ran into a problem with throwing WebApplication
examples with a response object:

throw new WebApplicationException(Response.status(412)

.type("text/plain;charset=utf-8")
                                                       .entity("Something
went wrong").build());

Throwing this exception would give a text/plain body with the entity body
but with http code 200. Throwing the same exception without an entity would
give the expected (412 response with an empty body).

After a little code browsing I found the problem in Dispatcher.java invoke
method. I created a patch file from revision 133 attached to this email.

Regards,

Thomas Cremers

[Resteasy-developers] releasing on mon or tues

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

I'm releasing beta 2 on monday or tuesday.  Everything is clean up in 
trunk.  I just need to do documentation.

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

[Resteasy-developers] SPI cleanup/refactoring

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

I've done another big commit.  The public methods of the SPI were 
dependent on classes outside of the package.  This is a nono.

I hope to freeze the SPI going forward.



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

[Resteasy-developers] Big Refactoring + Grizzly integration committed

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

I did a big refactoring so that resteasy could support other HTTP 
servers.  This expanded the SPI a little bit.  I also had to refactor 
the testsuite a lot too.

I also did some Grizzly HTTP and Grizzly Comet integration.  Here are 
the details:


* Grizzly HTTP Servlet was extremely buggy.  I found and fixed 5 
different bugs in their implementation by doing some delegation and 
inheritance hacks.

* This implementation scares me because there is no testsuite for the 
Servlet stuff and only a tiny testsuite for the HTTP stuff.  Its also 
totally hacked from the Tomcat codebase.

* Grizzly Comet wasn't so buggy, but still had a few of the bugs I found 
in HTTP Servlet implementation that were related.

* Both Grizzly HTTP and Comet take one full second to bootstrap.  TJWS 
takes only a few milliseconds.  So, TJWS is staying in.  Full testsuite 
run with TJWS on my box:  7 seconds.  Full testsuite run using Grizzly 
(HTTP or Comet): 30 seconds.


I'm going to fool around a little bit with adding asynchronous 
capabilities to resteasy with Grizzly Comet.




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

[Resteasy-developers] Variant junk committed

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

All the Variant junk in the spec is finally implemented.  Not sure if I 
like that stuff very much, but I guess we're stuck with it.

Bill


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

Re: [Resteasy-developers] Synced with jsr311 trunk

[Ryan J. M. <ry...@da...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I just committed the ported code from the RESTEasy alpha. After  
noodling around your idea of the List and Set idea, I am starting to  
like that idea so much better.  With that said, let's shoot for end of  
next week to have the MessgaeBodyWorkers and the  
CollectionMimeMultipartProvider a long with some extensive unit tests  
for those.

Ryan-


On Mar 17, 2008, at 8:34 AM, Bill Burke wrote:

> That would be cool and most helpful.  Multipart definitely needs  
> this. Timeframe?  I want to get out another release in 2 weeks or so  
> as I have  another resteasy project dependent on the next release.
>
> Ryan J. McDonough wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>> You mean things like MessageBodyWorkers? I just want to clarify  
>> that this is the interface that is used to lookup and different  
>> providers for MessageBodyReader/Writer's? If you haven't started on  
>> this already, I'd be interested in taking a stab at this one. For  
>> the MimeMultipartProvider, I'd like to try and leverage existing  
>> providers for the message parts and having access to the look up  
>> mechanism would be handy.
>> Ryan-
>> On Mar 15, 2008, at 3:22 PM, Bill Burke wrote:
>>> FYI, on Friday, I synced up with JSR311 trunk.  There's some cool  
>>> stuff
>>> going on there that I want to take advantage of.
>>>
>>> -- 
>>> Bill Burke
>>> JBoss, a division of Red Hat
>>> http://bill.burkecentral.com
>>>
>>> -------------------------------------------------------------------------
>>> This SF.net email is sponsored by: Microsoft
>>> Defy all challenges. Microsoft(R) Visual Studio 2008.
>>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>>> _______________________________________________
>>> Resteasy-developers mailing list
>>> Res...@li...
>>> https://lists.sourceforge.net/lists/listinfo/resteasy-developers
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1.4.7 (Darwin)
>> iD8DBQFH3Qy/K/xjmUY6JwURAmtcAJ4w0DH+zHOr87FbNmy8j/biB//gDgCgmYFB
>> AMvH/Xjci5i0GbHdElpCyBM=
>> =yLv5
>> -----END PGP SIGNATURE-----
>
> -- 
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)

iD8DBQFH3mr4K/xjmUY6JwURAlnFAJ0VHx2cOFpdYROJoF3jFkzDETWMDACeKY5T
BJoO6WjSBcQpl3FQsm0nFOg=
=+uVj
-----END PGP SIGNATURE-----

[Resteasy-developers] jax-rs + comet

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

I'm going to prototype an asynchronous model over RESTEasy JAX-RS using 
Comet APIs.  Jerome's email thread got me interested in this.

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

[Resteasy-developers] RESTEasy MOM

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

I've just finished a first stab at RESTFul JMS.  I've written a RESTFul 
interface over JMS.  Its available under resteasy/resteasy-mom in SVN. 
I can't release it until we REV JAX-RS again though.


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