Ext Direct Java based implementation

[yAdEs]

Thanks pagullo,great work!


Your djn is awesome!
I have made a directly ORM framework with Ext by djn, and It works well.

The only suggestion is, do you consider to change gson with Jackson?
It's much more efficiency and can easily extend to google app format.

I changed it by myself, but I strongly recommand u change it,too.

[omarc]

You modified the library to use Jackson instead?

Is your version available anywhere?

I'm very interested in taking a look at how it works.

Cheers,

Omar

[jpr]

What do you think about using SLF4J as a logging facade instead of hardcoded LOG4J for logging. This gives us the possibility to change/adapt &nbsp;to a logging framework used by the application which embeds DirectJNgine.<br><br>Steps are quite easy:<ol><li>Instead of log4j-1.2.15.jar use slf4j-api.jar and the binding slf4j-*.jar depending on the logging framework, you would like to use, e.g. slf4j-log4j12.jar</li><li>Import org.slf4j.Logger and org.slf4j.LoggerFactory, instead of org.apache.log4j.Logger</li><li>Change all Logger.getLogger( xxx.class) to LoggerFactory.getLogger( xxx.class)</li><li>Fix some errors, e.g. logger.fatal is not supported by slf4j, use logger.error instead</li><li>In DirectJNgineServlet.java change org.apache.log4j.NDC to org.slf4j.MDC</li><li>Instead of NDC.push/pull use the MDC map of slf4j (put/remove)</li><li>Adapt the logging statements to use placeholders instead of concatenated string (Performance)</li><li>On most occurences "if(logger.isDebugEnabled())" can be removed, as calling logger.debug() is not a performance issue anymore.</li></ol>Advantages: We use logback as our logging framework. This gives us the possiblity to set different log level at runtime. No need to restart the application. Depending of the application even a per session / per user logging in separate files is possible.<br><br>Any comments?!?<br><br>Jan<br><br>

[jpr]

What do you think about using SLF4J as a logging facade instead of hardcoded LOG4J for logging.

This gives us the possibility to change/adapt to a logging framework used by the application which embeds DirectJNgine.

Steps are quite easy:

1. Instead of log4j-1.2.15.jar use slf4j-api.jar and the binding slf4j-*.jar depending on the logging framework, you would like to use, e.g. slf4j-log4j12.jar
2. Import org.slf4j.Logger and org.slf4j.LoggerFactory, instead of org.apache.log4j.Logger
3. Change all Logger.getLogger( xxx.class) to LoggerFactory.getLogger( xxx.class)
4. Fix some errors, e.g. logger.fatal is not supported by slf4j, use logger.error instead
5. In DirectJNgineServlet.java change org.apache.log4j.NDC to org.slf4j.MDC
6. Instead of NDC.push/pull use the MDC map of slf4j (put/remove)
7. Adapt the logging statements to use placeholders instead of concatenated string (Performance)
8. On most occurences "if(logger.isDebugEnabled())" can be removed, as calling logger.debug() is not a performance issue anymore.

Advantages: We use logback as our logging framework. This gives us the possiblity to set different log level at runtime. No need to restart the application. Depending of the application even a per session / per user logging in separate files is possible.

Any comments?!?

Jan

[pagullo]

What do you think about using SLF4J as a logging facade instead of hardcoded LOG4J for logging.

This gives us the possibility to change/adapt to a logging framework used by the application which embeds DirectJNgine.

Steps are quite easy:

1. Instead of log4j-1.2.15.jar use slf4j-api.jar and the binding slf4j-*.jar depending on the logging framework, you would like to use, e.g. slf4j-log4j12.jar
2. Import org.slf4j.Logger and org.slf4j.LoggerFactory, instead of org.apache.log4j.Logger
3. Change all Logger.getLogger( xxx.class) to LoggerFactory.getLogger( xxx.class)
4. Fix some errors, e.g. logger.fatal is not supported by slf4j, use logger.error instead
5. In DirectJNgineServlet.java change org.apache.log4j.NDC to org.slf4j.MDC
6. Instead of NDC.push/pull use the MDC map of slf4j (put/remove)
7. Adapt the logging statements to use placeholders instead of concatenated string (Performance)
8. On most occurences "if(logger.isDebugEnabled())" can be removed, as calling logger.debug() is not a performance issue anymore.

Advantages: We use logback as our logging framework. This gives us the possiblity to set different log level at runtime. No need to restart the application. Depending of the application even a per session / per user logging in separate files is possible.

Any comments?!?

Jan

I like slf4j and the way it isolates you from the underlying logging system, and I thought about this some time ago, but decided against it.

Why? The built-in log4j viewer (Chainsaw) + slf4j MDC + log4j adapter stack is less functional for "just-in-time" log analysis than the log4j NDC + built in viewer stack: NDCs are shown and can be filtered dynamically with the built-in viewer, MDCs are lost.

Sometimes, that functionality is *very* useful for me, when debugging server side code. While writing DJN itself, it proved invaluable. Therefore, I could not justify back then spending extra effort to get less functionality in my own usage scenarios in order to get slf4j support.

So, unless I get into a project that devotes some development time for me to do this, I do not plan to support slf4j in the near future. And, believe me, I would love to do it, as I know it would be useful in some scenarios

[adavis2]

Like n0n3 (who posted on 14-Jul-2012) I am also trying to implement a paged grid panel using a directjngine back-end. Actually, what I'd like to do is create a buffered (infinite) grid, where paging is handled when you scroll through the grid. Is it possible to do either of these things? If so, could you point me toward an example?

Currently I'm able to display a grid panel with a paging toolbar and load the first page by subsetting the data to be returned. Unfortunately, I'm not sure how to pass back the total number of records (so the paging toolbar will show "Displaying 1 - X of Y" and enable the next button). How can I pass back the total number of records in the dataset?

I feel like there will be more challenges to overcome before I can get a buffered grid working, but getting it working with paging is the first step.

[maddhippy]

Hi, I'm using DJN with Sencha; It's been working perfectly until forms.

When I create a form like is said in the docs as so:

Ext.define('mdms.mynote.view.components.MyNoteForm',{    extend: 'Ext.form.Panel',
    config:{
        hidden:true
    },
    constructor:function(config){
        Ext.apply(config,{
           url: Ext.mdms.BASE_PROVIDER_URL,
           api: {
               submit:InsertNote.perform
           },
           items:[{
               xtype: 'textfield',
               name: 'descContact',
               value: 'hello world'
           }]
        });
        this.callParent([config]);
    }
});

it throws this on my server:

SEVERE: Servlet.service() for servlet DjnServlet threw exception
com.softwarementors.extjs.djn.router.processor.RequestException: Form post request is missing the following parameters: extAction, extMethod, extType, extTID, extUpload
	at com.softwarementors.extjs.djn.router.processor.RequestException.forFormPostMissingParameters(RequestException.java:117)
	at com.softwarementors.extjs.djn.router.processor.standard.form.FormPostRequestProcessorBase.checkNoMissingParameters(FormPostRequestProcessorBase.java:103)
	at com.softwarementors.extjs.djn.router.processor.standard.form.FormPostRequestProcessorBase.process(FormPostRequestProcessorBase.java:61)
	at com.softwarementors.extjs.djn.router.processor.standard.form.simple.SimpleFormPostRequestProcessor.process(SimpleFormPostRequestProcessor.java:62)
	at com.softwarementors.extjs.djn.router.RequestRouter.processSimpleFormPostRequest(RequestRouter.java:69)
	at com.softwarementors.extjs.djn.servlet.DirectJNgineServlet.processRequest(DirectJNgineServlet.java:609)
	at com.softwarementors.extjs.djn.servlet.DirectJNgineServlet.doPost(DirectJNgineServlet.java:580)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:637)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:293)
	at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:859)
	at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:602)
	at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:489)
	at java.lang.Thread.run(Thread.java:680)

I am trying to submit like so:

form.submit({
            params:{
                test:'test'
            },
            success:function(form, action){
                console.log('success')
            },
            failure:function(form,action){
                console.log(form);
            }
        });

It seems from those errors that the form submit does not go through the Ext.direct router and the Ext.direct metadata properties are not being added. Is there something additional I need to be doing here?

Thanks

[pagullo]

DJN works with forms from the very first version. I suspect there is some configuration error or some missing step in the javascript side -I think you are using the right annotation in the Java side, but just check it.

The DirectJNgine code includes some tests that exercise this feature, you might want to take a look at the javascript/java code.

[mark.peters]

DJN works with forms from the very first version.

Hi Pedro. I'd like to detail some issues I had when using DirectSubmit (ExtJS 4.1) with DJN 2.2. My experience would lead me to say that DJN has not yet been updated to support form submit for the latest version of ExtJS.

The issues all revolve around the fact that DJN's responses to form submits do not at all conform to the specified responses here: http://docs.sencha.com/ext-js/4-1/#!...n.DirectSubmit (see "sample success packet" and "sample failure packet"). This bug manifests itself in different ways:

1) No support for void @DirectFormPostMethod methods.

A void method that completes normally (without exception) will have the "failure" callback called in ExtJS because DJN's response has the "result" property set to null.

My current workaround for this bug has been to always return an object from form post methods, which has a success field hardcoded to true. Another workaround is to return a boolean and return true if the method completes successfully.

2) No support for exceptions thrown from @DirectFormPostMethod methods.

When a form post method throws an exception, DJN will send the serialized StandardErrorResponseData class. This does not have a "result" field as required, with a "success" value set to false. As a result, ExtJS will call the failure callback, but will do so for the wrong reason. ExtJS treats it (and other malformed responses) as a connection error, rather than a server error. The error metadata (message, serverException, etc) are not available to the callback.

I've looked at the DJN test for this case, and it is wrong. The test verifies that the callback is called, but was changed for ExtJS 4.1 to expect a "connect" failure instead of a "server" failure. This is not correct.

My current workaround to this issue is to add custom GSON serialization when serializing StandardErrorResponseData, to rewrite the response into what ExtJS expects. This involves adding an object property named "result" with a "success" property set to false, and then moving the "message", "serverException" and "where" objects into that result object (otherwise they will not be available in the callback).

So as I said, I think there's a little ways to go before it could be said that DJN 2.2 supports form submit for ExtJS 4.1. But this has been the first major defect we've found in DJN; our experience with it in general has been positive. Thanks for your work on it.

[lee el]

Hi,

I started to use DirectJNgine and I was able to configure it and use it within extjs app.
I regiester it in my main script file app.js as follows:

Ext.application({
    
    name: 'App',
    appFolder: 'app',
    launch: function() {
        Ext.Direct.addProvider(MyProvider.direct.REMOTING_API);

and then I am able to call the java classes and methods.
the problem is when I change some file my server redeploys the APP and then I get an error about the provider:
Uncaught ReferenceError: MyProvider is not defined

only when I restart my server the problem is solved, I would like to have suggestions why this is happening
is there some king of log?
thanks,
Lee