Ext Direct Java based implementation

[minneyar]

I can confirm that your alternative code works fine for me.

[pagullo]

I have released DirectJNgine 1.2 RC1 today.

As always, you can find it here: http://code.google.com/p/directjngine/

This new release runs on top of ExtJs 3.1.1, which is the officially supported ExtJs version.

I release this in the hope that those running it in non-Windows systems can check that it works as expected in their environment.

[stdunbar]

I'm looking to build a chat-like system and was going to use ExtJS and, potentially, DirectJNgine. I haven't seen particularly good or clear information regarding server push type of technologies with ExtJS 3.1.x even though it is checked off as "done" in the ExtJS road map.

I understand that in the Java server world asynchronous server updates are not at all standardized. There are Comet implementations included in Tomcat an Jetty but each of them is proprietary. The 3.0 Servlet spec addresses this and Glassfish 3.0 support this. So the landscape is harsh at best.

So, if I understand the DirectJNgine docs it looks like I'm limited to client initiated polling at this time. Is this correct? Am I going down the wrong path to use ExtJS on the front and Java on the back? Nothing has been implemented yet so I'm still very open.

Thanks for any info.

[pagullo]

So, if I understand the DirectJNgine docs it looks like I'm limited to client initiated polling at this time. Is this correct? Am I going down the wrong path to use ExtJS on the front and Java on the back?

The ExtDirect specification provides support for client-initiated polling only, and so does DirectJNgine.

I don't think your app will scale very well if you use client initiated polling. But if the number of clients is not big and the updates need not be very fast, you might find this workable.

[pagullo]

Today I have released DirectJNgine 1.2.

For more details, you can find the announcement here.

To all, thank you for your feedback and criticism.

Best regards,

[Whatty]

Today I have released DirectJNgine 1.2.

For more details, you can find the announcement here.

To all, thank you for your feedback and criticism.

Best regards,

Pagullo,

I am not 100% sure if you have been following the posts regarding the DirectJNgine / Spring integration but I would like to open a conversion regarding on how to support this type of external DI / IOC container (even more important once these features are rolled into JDK 7) in the contet of the DirectJNgine.

As expected, I have adapted / extended and unfortunately changed some of the base classes in the DirectJNgine to support the Spring integration (which I did not start but picked up from someone else), and now that the DirectJNgine has changed underneath me, there is a integration exercise that I must undertake again to bring the base version of what the Spring / DirectJNgine integration is based upon up to your latest version.

I would love to see some sort of open integration API / configuration option to allow these types of external DI containers (such as SPRING) to hook into the base DirectJNgine framework but that is going to take some collaboration between the authors of DirectJNgine and either myself or others in the community that require this type of integration.

Further to this the Spring community / authors may be willing to contribute to this integration, since there are number of features in the Spring framework that possibily could be leverage in the context of the DirectJNgine (such annotation based Spring configuration and bean lifecycle management). Logically it seems to make sense but I have yet to approach anyone in the Spring community (aka authors) about this type of integration.

Would it be possible to have a conversation regarding this and how to proceed.

Thanks in advance.

Whatty

[MoShAn480]

Hi,

I am working on a Spring MVC integration. Project can be found at:

http://code.google.com/p/springextjs...estSpringextjs

[pagullo]

Pagullo,

I am not 100% sure if you have been following the posts regarding the DirectJNgine / Spring integration

I followed the "Spring saga" with interest.
In fact, I helped Vincent Lagorce quite a bit when he attempted to provide Spring integration. I think you might have used his work as a starting point -not sure, though.

As expected, I have adapted / extended and unfortunately changed some of the base classes in the DirectJNgine to support the Spring integration (which I did not start but picked up from someone else), and now that the DirectJNgine has changed underneath me, there is a integration exercise that I must undertake again to bring the base version of what the Spring / DirectJNgine integration is based upon up to your latest version.

I would love to see some sort of open integration API / configuration option to allow these types of external DI containers (such as SPRING) to hook into the base DirectJNgine framework but that is going to take some collaboration between the authors of DirectJNgine and either myself or others in the community that require this type of integration.

Unfortunately, I don't have much time left nowadays, so I can't commit to consider or perform long-term modifications to DJN to support Spring right now.

When I announced 1.2 beta, a main concern was to open this kind of negotiation with people wanting to extend DJN, precisely to avoid this "DJN moving under my feet" thing. We've been *very* unlucky with the timing, because I would have loved to see someone seize the opportunity and provide robust Spring integration!

That said, I think you'll need very little effort to move to DJN 1.2.

You might want to take a look at the code for the classes in the "ssm" package, which implement the lifecycle support for the new session and application scoped objects. You will probably need to do something very similar for Spring.

Feel free to post here whenever you have some problem moving to the newest DJN version, and I will do my best to solve the issues you might encounter.

Regards,

[Whatty]

Understand we are all very busy, and yes "the moving under my feet thing" is exactly what I am hoping to avoid.

I believe that I have taken what was started by Vincent Lagorce and extended it further hooking into SSM layer mentioned by you and also provided some support for "external names" in the Action layer (decoupling of the action class from the external name known in the API), which was required by Spring.

I will execute a diff against the code base that I started with and the newest code base and hopefully the integration (re-integration) exercise will not be too painful.

Once I get it working on the newest version I will post back my Spring integrated version for all to use if required (but of course caveat emptor applies).

In particular the areas that caused me the most problem was the usage of private methods, which limited my ability to override behavior at certain key points without completely re-implementing the methods / classes and most of the changes that I made in the base classes (your code) was related to make methods protected (as opposed to private) and then overriding appropriately in my classes.

I expect that the library will reach a stable state as some point in time (if not already) and no major upgrades are on the horizon at the moment, so hopefully this re-integration exercise will not be occuring all that frequently.

Thanks for the effort on the library and your assistance.

Whatty

[tungchau]

I am using DirectJNGine. Does anybody have an answer for the following post?
http://www.extjs.com/forum/showthrea...554#post442554