Ext Direct Java based implementation

[Whatty]

We are currently investigating the servlet approach that and I believe are making some progress, will let you know once we have something workable.

Thanks for the assistance

[dreamtaotao]

I like DirectJNgine. I tried to DirectJNgine with struts2 integration but it seems impossible, it seems not work with MVC frameworks is that right? For example struts2. If you can do to give some clarification. Thank you, sorry my English not good

[pagullo]

DirectJNgine is only integrated with the servlet API at this moment.

The layer on top of the engine that supports the servlet API is thin, and it should be possible to integrate it with other frameworks/libraries, but at this moment I know of no one who has attempted to integrate DirectJNgine with Struts 2.

That said, I think you can install the DJN servlet and make it coexist with Struts 2, but whether this is applicable will depend on how you plan to use DJN. Deep integration might require extra work, but just using it to handle some chores should be possible.

[Whatty]

Good morning,

We have been working with the djn-spring-1.1-rc1 library and have made a bunch of updates to the Spring Integration adding support for sessions.

I have attached the source code and configuration files required for this to work.

Basically it attempts to locate the Spring bean in the session first and if found uses that instance for invocation of the method, otherwise it asks Spring for the appropriately named bean.

This is a very very rough first attempt at it and believe me there are many many opportunities for refactoring and improving this code but I wanted to get it out there for others to take a look at, possibly use and suggest improvements.

Whatty

[pagullo]

Hi!

After several request from DJN users I have dedided to add support for making it possible to access the following information easily from a DJN method:

• HttpSession
• ServletContext
• HttpServletRequest
• HttpServletResponse
• HttpServlet
• ServletConfig

Besides, I am providing support for session and application scoped actions too.

I have implemented this as an extension built on top of the DJN core, as I strongly feel that state management is an orthogonal concern, but I will include this in the same JAR, to make things easy

Here is what I plan to support...

Accessing the session, request, response, etc. from a DJN method
You can acces the session, servlet context, request, response, servlet and servlet configuration using the WebContext and WebContextManager classes, as shown in the following code:

public class WebContextManagerTest {
  public static class WebContextInfo {
    public int callsInSession = 0;
    public int callsInApplication = 0;
    public String sessionId;
  }
  
  @DirectMethod
  public WebContextInfo test_webContext() {
    WebContext context = WebContextManager.get();
    HttpSession session = context.getSession();
    ServletContext application = context.getServletContext();
    
    // Keep a counter of how many times we have called 
    // this method in this session
    Integer callsInSession = 
      (Integer)session.getAttribute("callsInSession");
    if( callsInSession == null ) {
      callsInSession = new Integer(0);
    }
    callsInSession = new Integer(callsInSession.intValue() + 1);
    session.setAttribute("callsInSession", callsInSession);

    // Keep a counter of how many times we have called 
    // this method in this application
    Integer callsInApplication =
     (Integer)application.getAttribute("callsInApplication");
    if( callsInApplication == null ) {
      callsInApplication = new Integer(0);
    }
    callsInApplication = 
      new Integer(callsInApplication.intValue() + 1);
    application.setAttribute("callsInApplication", 
      callsInApplication);
    
    // Return status information
    WebContextInfo result = new WebContextInfo();
    result.callsInApplication = callsInApplication.intValue();
    result.callsInSession = callsInSession.intValue();
    result.sessionId = context.getSession().getId();
    return result;
  }
}

Making an action session-scoped
To make an action session-scoped, just use the @ActionScope annotation as follows:

@ActionScope(scope=Scope.SESSION)
public class SessionStatefulActionTest {
  private int count = 0;

  @DirectMethod
  public synchronized int test_getSessionCallCount() {
    this.count++;
    return this.count;
  }
}

Note how the only thing you need to do is to add the @ActionScope annotation.

Making an action application-scoped
To make an action application-scoped, just use the @ActionScope annotation as follows:

@ActionScope(scope=Scope.APPLICATION)
public class ApplicationStatefulActionTest {

  private int data = 0;
  private int count = 0;
  private int pollData = 0;
  
  @DirectMethod
  public synchronized int test_getApplicationData() {
    this.data++;
    int result = this.data;
    
    // Trick to allow multiple test executions
    if( this.data == 2) {
      this.data = 0;
    }
    return result;
  }
  
  @DirectMethod
  public synchronized int test_getApplicationCallCount() {
    this.count++;
    return this.count;
  }

Again, the only thing you need to do is to use the @ActionScope annotation.

This functionality is currently in alpha, and feedback from DJN users will be welcome. I haven't polished all concurrency related issues, and will greatly appreciate you guys take a look at it.

The attached JARs include the corresponding classes and source code.

@vlagorce & other people working in DJN extensions
Since some DJN internals have changed to make the DJN core completely independent of state management, you will probably have to make some little changes to your code. Sorry about that, guys.


Besides, for those interested in having session and application scoped actions, you will probably be able to rely on the new functionality provided by DJN instead of having to implement it on your own.

[dreamtaotao]

I am pleased to DirectJNgine becoming more and more powerful. Just seen DirectJNgine-Spring, regret that so little information and no examples and documentation, and I hope we can DirectJNgine combined with the spring should be nice to do! I wish you success in your work that I have been watching the better DirectJNgine！

[Whatty]

Pedro,

First of all thank you very much for addressing Session support in the DirectJNgine.

Having taken a look at the update, and already integrated it with the SessionAware spring integrator that I posted yesterday, I would like to suggest a simple modification to the RequestProcessorBase class that I believe will make it easier for integrating other bean controllers such as Spring

In the method below, you grab the RegisteredMethod in which to service the request and allow the dispatcher to execute the method against the action instance

protected Object dispatch(Class<?> instanceClass, Method method, Object[] parameters) {
    return getDispatcher().dispatch( instanceClass, method, parameters );
}
  
// TODO: this is NOT something PollRequestProcessor will use. Handle somewhere else!
protected Object dispatch( String actionName, String methodName, Object[] parameters ) {
    assert !StringUtils.isEmpty(actionName);  
    assert !StringUtils.isEmpty(methodName);
    assert parameters != null;
    
    RegisteredMethod method = getMethod( actionName, methodName);
    Object result = dispatch(method.getActionClass(), method.getMethod(), parameters);
    return result;
}

Since you pull the information out of the RegisteredMethod to make the call to dispatch method, you essentially loose track of the actionName. This action name is used by Spring to initiate the bean lookup.

I had to override the JSON request processor to handle this situation as below:

protected Object dispatch( String actionName, String methodName, Object[] parameters ) {
        assert !StringUtils.isEmpty(actionName);  
        assert !StringUtils.isEmpty(methodName);
        assert parameters != null;
       
        
        RegisteredMethod method = this.getMethod(actionName, methodName);
        
        LOGGER.debug("actionName = " + method.getActionName() + ", methodName = " + method.getMethod().getName());

        Object result = this.dispatch(method, parameters);
        return result;
}

protected Object dispatch(RegisteredMethod method, Object[] parameters) {
        return ((SessionAwareSpringDispatcher)this.getDispatcher()).dispatch(method, parameters);
}

where instead of pulling the information out of the RegisteredMethod, I just pass it to the dispatcher. This makes action name available to the dispatcher, which I then use to lookup up the bean in the Spring Context.

I could have used the action class name, but this puts an invalid dependency on the action name to class name association.

I believe this small refactoring would make it easier for people to override the default behavior in the dispatch hierarchy for action instantiation, or in my case bean lookup by action name.

Again I thank you and I am sure the community thanks you for your efforts.

Whatty

[Whatty]

Good afternoon,

I have quickly updated the session aware Spring Integrator that I posted a few days ago to make the latest version of the DirectJngine 1.2-Alpha1.

Again, it is very very rough and could probably do with some refactoring / cleanup but but is functional.

To the author of the original Spring Integration, I updated some of your classes to match the new DirectJngine so please take a look.

MMV (mileage may vary)

Whatty

[pagullo]

Pedro,

First of all thank you very much for addressing Session support in the DirectJNgine.

Having taken a look at the update, and already integrated it with the SessionAware spring integrator that I posted yesterday, I would like to suggest a simple modification to the RequestProcessorBase class that I believe will make it easier for integrating other bean controllers such as Spring

In the method below, you grab the RegisteredMethod in which to service the request and allow the dispatcher to execute the method against the action instance

protected Object dispatch(Class<?> instanceClass, Method method, Object[] parameters) {
    return getDispatcher().dispatch( instanceClass, method, parameters );
}
  
// TODO: this is NOT something PollRequestProcessor will use. Handle somewhere else!
protected Object dispatch( String actionName, String methodName, Object[] parameters ) {
    assert !StringUtils.isEmpty(actionName);  
    assert !StringUtils.isEmpty(methodName);
    assert parameters != null;
    
    RegisteredMethod method = getMethod( actionName, methodName);
    Object result = dispatch(method.getActionClass(), method.getMethod(), parameters);
    return result;
}

Since you pull the information out of the RegisteredMethod to make the call to dispatch method, you essentially loose track of the actionName. This action name is used by Spring to initiate the bean lookup.

I had to override the JSON request processor to handle this situation as below:

protected Object dispatch( String actionName, String methodName, Object[] parameters ) {
        assert !StringUtils.isEmpty(actionName);  
        assert !StringUtils.isEmpty(methodName);
        assert parameters != null;
       
        
        RegisteredMethod method = this.getMethod(actionName, methodName);
        
        LOGGER.debug("actionName = " + method.getActionName() + ", methodName = " + method.getMethod().getName());

        Object result = this.dispatch(method, parameters);
        return result;
}

protected Object dispatch(RegisteredMethod method, Object[] parameters) {
        return ((SessionAwareSpringDispatcher)this.getDispatcher()).dispatch(method, parameters);
}

where instead of pulling the information out of the RegisteredMethod, I just pass it to the dispatcher. This makes action name available to the dispatcher, which I then use to lookup up the bean in the Spring Context.

I could have used the action class name, but this puts an invalid dependency on the action name to class name association.

I believe this small refactoring would make it easier for people to override the default behavior in the dispatch hierarchy for action instantiation, or in my case bean lookup by action name.

Again I thank you and I am sure the community thanks you for your efforts.

Whatty

Hi!

I didn't do it the way you suggest because poll methods need to be taken into account too, and I implemented them so they are 'global', i.e., they do not belong to a RegisteredAction, and therefore I can't pass the action name to the dispatch method for poll methods (sigh).

But I can pass the class, and it is really useful sometimes, for example to process custom annotations -which is what I do to support stateful actions.

As to way poll methods do not belong to a RegisteredAction, that made lots of sense when we had no stateful actions, as it made implementing some things much easier back then. Changing that now would change the published API...but I might do, because that part of the API is rarely used, to be fair...On the other hand, I was aware that if I had made that change, I would have had the RegisteredAction available, and passing that to dispatch would make additional info available, including the action name you want...

So, I need to consider carefully how or whether to pass the additional info you suggest. Let me think about that, ok?

Thanks for the feedback

Best regards,

[lxbzmy]

can not call a directmethod when a string param contains \n \r etc?
why?