Menu
▾
▴
resteasy-developers
|
From: Andreas <a...@ho...> - 2008-04-08 19:04:05
|
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
|
|
From: Andreas H. <a...@ho...> - 2008-04-09 06:19:10
|
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
|
|
From: Bill B. <bb...@re...> - 2008-04-09 13:25:44
|
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
|
|
From: Andreas H. <a...@ho...> - 2008-04-09 15:00:18
|
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
|
|
From: Bill B. <bb...@re...> - 2008-04-09 19:17:41
|
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 |
|
From: Andreas H. <a...@ho...> - 2008-04-10 04:33:52
|
> 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 |
Thanks for helping keep SourceForge clean.
X