Help

Controls

PermLinkWikiLink

Built with Seam

You can find the full source code for this website in the Seam package in the directory /examples/wiki. It is licensed under the LGPL.

Forum: Seam Users Forum ListTopic List
03. Apr 2008, 02:34 CET | Link

Hello All,

I'm working on an ExtJs to Seam bridge and have some questions regarding error handling in the Seam Remoting layer. I notice that when exceptions are encountered on the server my registered callback for the remote invocation is not invoked. I looked into this issue with firebug and noticed that when an exception is raised a response is not returned to the underlying XHR.

My initial strategy with this is to return Json from a POJO Seam component using detached entities fetched from a SLSB. All of this is working just fine and I have a great solution using an extension of the Ext.data.DataProxy to popluate Ext stores which back many of its widgets. However when things go bad Seam Remoting isn't giving me any feedback so I can respond these unexpected conditions.

As I work out these last issues I was hoping that I could get some answers from the group as to how best deal with this. I'm very much a noob with Seam. In struts 2 I would get a 500 status and would be able to deal with this accordingly. My initial design ideas here are to use a combination of annotations and put some around advice on these @WebRemote methods to deal with exceptions in a graceful way so that atleast my callback gets invoked with something like {success:false}.

I was hoping to extend this solution to provide a more RPC style of interaction that Seam Remoting seems to be leaning towards. In this case I will also need a way to deal with server side errors.

I hope this makes sense and look forward to any feedback the group has to offer. Feel free to hit me up with questions if anything in this post isn't clear.

Tia, Sean

8 Replies:
03. Apr 2008, 05:12 CET | Link

There are currently the following open issues in JIRA relating to exception handling in Seam Remoting:

http://jira.jboss.org/jira/browse/JBSEAM-633

http://jira.jboss.org/jira/browse/JBSEAM-1279

http://jira.jboss.org/jira/browse/JBSEAM-1229

Unfortunately they have been pushed to the back-burner temporarily while I work on enhancements to security, however remoting will be receiving more attention after the current security work is complete. Please feel free to add comments to these issues in JIRA (JBSEAM-633 is most relevant I'd say) if you have specific requirements or implementation ideas.
03. Apr 2008, 05:33 CET | Link

Thanks Shane. 633 seems similar. I'll have some feedback that I'll post on JIRA.

Sean
03. Apr 2008, 12:20 CET | Link

check out http://ntispace.blogspot.com/

There's a posting about remoting exceptions. Not my blog, some French guy, but I got the proxy stuff from it and it works fine, also no JSON stuff since remoting returns js objects.
03. Apr 2008, 14:54 CET | Link

thanks for the link. I have seen this and based my proxy on it slightly. His solution was geared towards grids. You actually can return JSON. I'm using a POJO Action and its @WebRemote method returns a String that is actually Json. It works quite well.

Sean
03. Apr 2008, 16:14 CET | Link

Isn't seam wrapping the result in xml first ??

03. Apr 2008, 16:31 CET | Link

Yes Seam uses an XML envelope for the exchange, both request and response. A typical response is something like: 

<envelope>
  <header>
    <context>
      <conversationId>8</conversationId>
    </context>
  </header>
   <body>
     <result id="0">
       <value>
           <str>%7Bdata...</str>

The Seam Component proxy only passes the content of the str element to my callback. This content is valid Json.

So the server-side architecture is simple. I have a POJO Action backed by a SLSB. The POJO exposes a @WebRemote method that returns a String. When the event (request) is received the domain objs are fetched from the SLSB. Subsequently the POJO Action translates and returns the domain objs into a Json formatted String.

Here's an explanation of the client-side artifacts that provide the integration glue with Ext: http://mcdconsultingllc.com/node/18.

Note: I'm still working on this but it loads the client-side stores prefectly. I need to work on the param passing integration next. It works fine when the Seam component exposes a method without args.
03. Apr 2008, 19:51 CET | Link

Well I just don't get the part to translate it to json first, what's the advantage ?

Having seam converting my objects works way better for me (although the json string could be smaller without all the xml tags but I don't think thats much of a issue)

Together with a colleague were also gonna check out the seam-ext integration possibilities. So good to see even more people looking in to it.

03. Apr 2008, 20:27 CET | Link

Sander,

This is just the first step. The proxy is the core to the solution so I figured this was the best way to start off. The advantage is Ext natively supports Json, ie I only needed to focus on the Proxy not a custom reader to support bean to JS serialization to Ext record creation.

I just wanted something simple to start with and Json fit that need. Once this is working well I plan to introduce a custom Ext.data.DataReader so the solution would be more 'Seam-like'.

Speaking of integration this is only part of the picture, integration of Ext store backed widgets. The Ext form stuff introduces it's own Json protocol and the Actions are very much coupled to the traditional ajax model.

Sean