6 Replies Latest reply on Nov 18, 2009 1:02 AM by rkilcoyne.rkilcoyne.mac.com

Seam Remoting: Type question

rituraj_tiwari May 29, 2008 3:28 AM

I have a @WebRemote method that can return a subclass of a base type. Something like:

@Name("MyBean")
public class MyBean
  @WebRemote
  public BaseType getInfo() { ... }

Initially, I had the base type be an interface. I was observing that my callback(result) was being called with an undefined result value.

I looked at the interface.js?MyBean JavaScript and realized that the BaseInfo type was not being generated. I converted BaseInfo into a JavaBean. This generated the JS stub properly.

Now I ran into the next problem. The object returned by getInfo() is actually a subclass of BaseType . So, when the response XML comes down, it has

<envelope> ...<bean type="SubclassType" ... </envelope>

Needless to say, the JS stub does not find this type and my result is once again undefined .

Am I using remoting wrong or should I expect the marshaling code to set the bean type to what is declared on the getInfo() interface?

Thanks.

-Raj

1. Re: Seam Remoting: Type question

shane.bryzak May 29, 2008 3:38 AM (in response to rituraj_tiwari)
You need to explicitly import the subclass stub:

<s:remote include="myComponent,com.example.SubClassType"/>
Actions
2. Re: Seam Remoting: Type question

rituraj_tiwari May 29, 2008 5:03 AM (in response to rituraj_tiwari)

Shane,
That works. I have to say that Seam remoting is very cool.

It would have been nice if I did not have to explicitly enumerate the subclasses. If I add a new subclass, this leads to one more place I have to track.

On a minor note: if I have a space after the comma in the list, I get a component not found error.

-Raj
Actions
3. Re: Seam Remoting: Type question

shane.bryzak May 29, 2008 5:09 AM (in response to rituraj_tiwari)

It would have been nice if I did not have to explicitly enumerate the subclasses. If I add a new subclass, this leads to one more place I have to track.

I'm afraid that would be next to impossible, how could the interface generator be aware of every single class that implements an interface/extends the base class?

I'll take a look at the space after the comma issue, it should be a simple matter of trimming the spaces off.
Actions
4. Re: Seam Remoting: Type question

rituraj_tiwari May 29, 2008 6:47 AM (in response to rituraj_tiwari)
I would think that the better out of the box behaviour would be to stick to the interface/base class at the method signature of the @WebRemote method. So, if I have @WebRemote signature:

@Name("MyBean") public class MyBean { @WebRemote public BaseType getInfo() { ... } ... }

And a type

public class BaseType { beanProperty1; beanProperty2; }

And a subtype:

public class SubType extends BaseType { beanProperty3; }

If my @WebRemote method happens to return SubType , it should still be marshalled as BaseType with beanProperty3 also being available so that if my JS code wanted to explicitly cast it to SubType it could.
Actions
5. Re: Seam Remoting: Type question

shane.bryzak May 29, 2008 8:56 AM (in response to rituraj_tiwari)

If the method returned a SubType yet it was marshalled as BaseType, then it would be unmarshaled as BaseType on the client also (and not include the extra methods defined by SubType). And there's not really any way to easily cast complex types in JavaScript as far as I'm aware.

Also keep in mind that a JavaScript-based client might not be the only consumer of Seam Remoting.
Actions
6. Re: Seam Remoting: Type question

rkilcoyne.rkilcoyne.mac.com Nov 18, 2009 1:02 AM (in response to rituraj_tiwari)

Thanks for the response -- that's 2x tonight that I had a relatively obscure question answered by the forums.

I'll be sure to contribute back as I work on integrating seam remoting with GWT.
Actions

Go to original post