Ext Direct Java based implementation

[tungchau]

Hi,
I found out that DirectJNGine does not support Action class that implemeted a Java Interface. It threw "IllegalArgumentException: object is not an instance of declaring class" when I tried to invoke the Action. For example, if I have MyAction class that implement IAction as the following:

@Service("MyAction")
public class MyAction implements IAction {
 
//...
@DirectMethod
public String doEcho(String n) {
      return n;
}

Calling the remote API as the following:

MyAction.doEcho("Tung Chau", function(p, response){

      Ext.Msg.alert("Message::"+response.status,(response.status)? response.result : response.message);
        });

If I make MyAction class NOT to implement IAction interface, then everything will work.
Is this a Spring bean configuration problem, not DirectJNGine problem?

[tungchau]

Hi Pedro,
I had a problem described at the following thread:
http://www.extjs.com/forum/showthrea...554#post442554

I wonder if the problem related to GSON configuration, not DirectJNGine?

Thanks,
Tung Chau

[pagullo]

Hi,
I found out that DirectJNGine does not support Action class that implemeted a Java Interface. It threw "IllegalArgumentException: object is not an instance of declaring class" when I tried to invoke the Action. For example, if I have MyAction class that implement IAction as the following:

@Service("MyAction")
public class MyAction implements IAction {
 
//...
@DirectMethod
public String doEcho(String n) {
      return n;
}

Calling the remote API as the following:

MyAction.doEcho("Tung Chau", function(p, response){

      Ext.Msg.alert("Message::"+response.status,(response.status)? response.result : response.message);
        });

If I make MyAction class NOT to implement IAction interface, then everything will work.

DirectJNgine *does* support actions implementing interfaces: I have such an action working correctly in front of me. Please, check your facts before making such assertions, as other potential users might be lead to think DJN belongs to the "non-working/just crap" software category, which I think is not the case.

Now, let's see whether I can help you.

Is this a Spring bean configuration problem, not DirectJNGine problem?

Since I am no Spring programmer, I can only guess about what's going on. But, to me, it looks like this is some configuration problem, or you need to create some kind of DJN/Spring bridge. Maybe Spring is playing proxy-like games, creating and instantiating a different class where MyAction is expected? Can you check that?

Besides, I think Vincent Lagorce and Whatty have some software that helps bridge the DJN/Spring gap, did you check it?

As an aside, there are a pair of good ideas/best practices in DJN can be helpful in your scenario:

a) Use "clean" action classes whose *only* purpose is to interact with the Javascript side of the world, probably just redirecting the call to the real object in charge.
This takes care of problems due to external lifecycle cotnrol, proxies being generated under-the-hood, etc.

b) Define "clean" data exchange classes.
This takes care of the potential problems you can find with very complex Java structures, that can stretch GSON a bit too much. You can alwasys configure GSON adequately, but this can be more complicated than creating simpler data exchange classes.

I have found these practices invaluable when "strange" things happen. Integration between frameworks/libraries can be a nightmare, and making things as simple as possible can go a long way to make it easier.

Regards,

[pagullo]

Hi Pedro,
I had a problem described at the following thread:
http://www.extjs.com/forum/showthrea...554#post442554

I wonder if the problem related to GSON configuration, not DirectJNGine?

Thanks,
Tung Chau

GSON is the one in charge of JSON handling. I think it is having a hard time handling interfaces.

You should probably pass concrete classes.

[hschaefer123]

Hi,
i have just tested the feature concerning stateful actions.

The action behaves the way expected, but for me i am missing
a feature like the servlet init() and destroy() methods.

The init() can be realized via a singleton class member, instantiated inside method,
but how should the destroy been handled?

I would like to exclude 'expensive/inperformant' functionality inside session scope,
but i have to close/destroy depending things on session close.

Any ideas?

Best wishes,
Holger

[pagullo]

Hi,
i have just tested the feature concerning stateful actions.

The action behaves the way expected, but for me i am missing
a feature like the servlet init() and destroy() methods.

The init() can be realized via a singleton class member, instantiated inside method,
but how should the destroy been handled?

I would like to exclude 'expensive/inperformant' functionality inside session scope,
but i have to close/destroy depending things on session close.

Any ideas?

Best wishes,
Holger

I think your strategy should be exactly the same you would use with "expensive" objects stored in the session: just ignore the fact that they are instantiated by DirectJNgine.
Maybe you can use HttpSessionListener to perform expensive resource cleanup.

You will probably need to find some of the objects stored in the session by DJN to perform cleanup. Session scoped objects are stored in the HttpSession with the "DirectJNgine.SESSION.xxx" name, where "xxx" is the action name -as set in the @DirectAction annotation (or the class name, without the package).

Objects with application scope are stored as "DirectJNgine.APPLICATION.xxx" in the ServletContext.

Regards

[Sesshomurai]

Hi,
I was reading the 1.2 manual and it mentions briefly about the nature of the callback function from a simple method call (not a store or form) and it would discuss more of it later in the guide. I didn't notice any further info about it.

So my question is, how are the callback functions used to determine success or failure of the method call ,etc.

Thanks!! Great product here.

[pagullo]

Hi,
I was reading the 1.2 manual and it mentions briefly about the nature of the callback function from a simple method call (not a store or form) and it would discuss more of it later in the guide. I didn't notice any further info about it.

So my question is, how are the callback functions used to determine success or failure of the method call ,etc.

Not sure what part of the documentation you are talking about, but maybe this will help (from page 13):

The call to multiply is a bit more interesting, because it shows how to handle server errors:

TestAction.multiply(num.getValue(), function(result, e) {
  var t = e.getTransaction();
  if(e.status) {
    out.append(String.format(
     '<p><b>Successful call to {0}.{1} with ' +
     'response:</b><xmp>{2}</xmp></p>',
     t.action, t.method, Ext.encode(result)));
  } 
  else {
    out.append(String.format(
            '<p><b>Call to {0}.{1} failed with message:</b><xmp>{2}</xmp></p>',
      t.action, t.method, e.message));
  }
  out.el.scrollTo('t', 100000, true);
});

Here, we get the event transaction and check its status: if it is true, the execution of the application method finished successfully, and you can safely use the result. Else, the execution finished with a server error. For all intents and purposes this is considered to be a server error by DirectJNgine, and is notified as such to Ext Direct.

When there is a server error, the event received by the function handling the result will have a message field, providing some kind of explanation about the problem, and if in debug mode, a where field providing additional information. This field will always be an empty string when not in debug mode.

DirectJNgine provides as message the name of the Java exception and the message it contains, while where contains the full stack trace of the exception.

For more info, check the ExtJs documentation, as that's what defines how ExtDirect implementations should work. Besides, depending on the context, you might find that there are specific ways to handle errors.

Hope this helps

Thanks!! Great product here.

Thanks :-)

[Sesshomurai]

Ahhh great. Thanks for pointing that out Pedro. Much appreciated.

[vlagorce]

I am pleased to announce that I'll finish the spring integration I have start many month ago..