Ext Direct Java based implementation

[waqar]

It is mentioned in the DJN 2 user guide it donot support "baseparams" and we must adapt a way of form Submit/api ...

how ever I cannot get the Idea of how to use api?submit with a "direct Store" and directFn when using DJN ...
Is any body out there already developed a "Paging grid" or a buffered Grid ? what way is adapted to pass parameters to server's java function.

please share the code of the store in java script if possible..

Any guidance will be appriciated!

[dalt]

Hi,

thank for your directjngine lib.

i've a problem... when i deploy two war in jboss as7 (two part of the same application) and i try to call, using direct, the slave war from the main war i've got this error:

{"tid":1,"action":"MyTestAction","method":"get","message":"RequestException: No action registered as 'MyTestAction'","where":"","type":"exception"}


i've defined the action "MyTestAction" in the slave web.xml.

please help me...

Paolo

[pagullo]

Maybe you are not providing the compiled classes + configuration in both wars? If that's the case, DJN has no way to know what calls are avaible, nor what they look like.

[pjain11]

I see DJN 2.0 alpha released in july 2011. Any idea about DJN 2.0 final release schedule?

[pagullo]

DJN 2.1 final is out.

The 2.0 alpha 1 ended up being production ready, as I said in other posts in which I recommended to use it for production. But I think we all needed to see the "final" suffix, so here it is

I should have removed the 'alpha 1' suffix a long time ago, if only to provide reassurance, mea culpa. The released version just adds some additional tests and I made sure it passes all tests for ExtJs 4.1.0. Some new change in 4.1.0 broke a test that used to work in 4.0.x, and I had to change the test code accordingly.

The bump from 2.0 to 2.1 is to emphasize the fact that this one works with ExtJs 4.1.0, which is the version I feel we all should be using, due to the many fixes and improvements it sports.

As always, you can get DJN at http://code.google.com/p/directjngine/downloads

Regards!

[pagullo]

Now that 2.1 is out and I have found some spare time for DJN (!), I've been thinking hard about new features.

In order to share my ruminations with the community I have publihed some of them at http://softdevbuilttolast.wordpress....tjngine-2-1-i/. I will soon follow with more posts.

Be aware that these are just ruminations, though

As always, comments and suggestions will be welcome.

[alexMobimesh]

Hi Pedro,
I'm exploring your directJNgine library and I have to say that I really like it! It really simplifies every day development, and I wanted to thank you for all the time you have spent on it providing a great library to all the world! The docs are brilliant and I've configured everything really fastly. Now that I have my remote methods (marked with the convenient @DirectMethod), that are usable from the client side, I was wondering how to implement a convenient way to manage the authorization level of each method.

In the perfect world I'd like to accomplish something like this:

@DirectMethod
@AccessLevel( level="Admin")
public String something()

I saw that I can access to the DirectJNgine servlet's context and session, but I wanted to ask you how do you implement the authentication internally and if it's possible to plug-in an external class to the DirectJNgine's servlet that implements a way of defining each access level. Ideally I think that the security manager has to be called by the DirectJNgine's servlet during the internal routing process, deciding whether to allow method execution or provide a standard exception (such as "403: forbidden") that is sent to the client. What do you think about this? I'm curious to hear your opinion.

Looking forward to hear from you,
Alex

[pagullo]

Hi Pedro,
I'm exploring your directJNgine library and I have to say that I really like it! It really simplifies every day development, and I wanted to thank you for all the time you have spent on it providing a great library to all the world! The docs are brilliant and I've configured everything really fastly.

Thanks!

Now that I have my remote methods (marked with the convenient @DirectMethod), that are usable from the client side, I was wondering how to implement a convenient way to manage the authorization level of each method.

In the perfect world I'd like to accomplish something like this:

@DirectMethod
@AccessLevel( level="Admin")
public String something()

I saw that I can access to the DirectJNgine servlet's context and session, but I wanted to ask you how do you implement the authentication internally and if it's possible to plug-in an external class to the DirectJNgine's servlet that implements a way of defining each access level. Ideally I think that the security manager has to be called by the DirectJNgine's servlet during the internal routing process, deciding whether to allow method execution or provide a standard exception (such as "403: forbidden") that is sent to the client. What do you think about this? I'm curious to hear your opinion.

Looking forward to hear from you,
Alex

I think that tinkering with DJN to handle security concerns is not a good idea, security is an orthogonal concern.

As a *quick* solution, you might be able to solve your issue by letting some other element check permisions and raise a security exception. DJN will pass it to the client with a message in an standard format that includes the exception type and its message.

Note that the message is referred to the "cause exception", not the last one in a exception stack, making it meaningful for that kind of processing .

[alexMobimesh]

Hi Pedro,
I already have developed my own Security manager that handles method-level permissions, but I need to intercept the calls to my method before they happen. By analyzing your source code, I've found that
every server side method is callled by the code on the line 144 of DispatcherBase class, that does the following:

132  protected Object invokeMethod(RegisteredMethod method, Object actionInstance, Object[] parameters) {
...
136      Method javaMethod = method.getMethod(); 
137      Object result;
...
144      result = javaMethod.invoke( actionInstance, parameters );
...
160      return result; 
161  }

The result is a generic Object. That made me thought about a way to implement a more flexible security manager without patching your library.
My idea is to replace the line 144 with the following one:

result = securityClass.invoke(javaMethod, actionInstance, parameters);

in which securityClass is an instance of a class that implements the public interface SecurityManager defined as follows:

public interface SecurityManager {
    
    public Object invoke(Method method, Object actionInstance, Object[] parameters);
}

By doing this, you could implement the default security manager bundled in DJN that simply does:

public class DjnDefaultSecurityManager implements SecurityManager {

    @Override
    public Object invoke(Method method, Object actionInstance, Object[] parameters) {
        return method.invoke( actionInstance, parameters );
    }
}

Then a configuration parameter could be added to the web.xml file in which the developer could specify if it's going to use its own implementation of the security manager.
The configuration parameter could be something like this:

<init-param>
    <param-name>DjnSecurityManager</param-name>
    <param-value>org.abusinessname.CustomSecurityManager</param-value>
</init-param>

If this parameter is not defined in the web.xml, the default DJN security manager class will be used.
In this way DJN delegates to the developer the task of implementing its own security manager, but provides a more convenient and elegant way to do it.

What do you think about this proposal? I think that it's a minimal tweak to your code that could provide a powerful feature to your library.

Alex

[pagullo]

Thanks for your proposal!


I prefer not to add security management to DJN, as I consider it an orthogonal concern -more so because there are so many ways to handle security, think Spring Security, JBoss Picketlink or JAAS.

Regards,