Ng, Victor schrieb:
Just a heads up that the Django section's later half is focused on integration with J2EE.  I've put in code and documentation on integrating with JNDI for database connection pooling, leveraging container managed thread pools for asynchronous processing, and closing up with JMS and STOMP for messaging between J2EE and non-Java applications.
 
vic
 
I love the disparage between explaining a Python for-loop but then throwing database connection pooling and other JEE expert level concepts on the reader without explaining even the terms nor discussing their relevance.

A few observations about JEE integration. JEE is a bundle of APIs capturing a variety of services.When the original J2EE was written in the late 1990s there weren't any high quality app-server implementions, neither were there competing products like Spring. In 2009 we can observe even more. For the services defined in the JEE there are now lots open source Java implementations which might comply or not comply to the JEE API descriptions. So the scenery is not unlike Pythons where we see various frameworks which integrate 3rd party service components like SQLAlchemy, Jinja2, Routes etc.

In the Javaverse we have e.g.

- Transation management -- Bitronix
- Security -- JGuard
- ORM  -- Hibernate
- Remoting -- JMI , Hessian
- Servlets -- Tomcat and various full JEE appservers
- Webservices -- Axis 2
- Web Templates -- JSP and JSF, Freemarker, Velocity

There is also OpenEJB but EJB is the part of the JEE I identified which fits the least with Jython because it is essentially Java with additional constraints which are not helpful in the Jython context. The JRuby cookbook makes use of EJBs only from the perspective of a client app written in JRuby and I would be surprised if anyone can advance beyond this within the JEE framework.

I'm not sure yet what to make of all the component wiring techniques in Java since I always considered this as the domain where dynamic languages can shine. They provide more flexiblility than annotation based techniques and are by orders of magnitude less clunky than Java+XML+DI. To sum it up: I believe there are sufficient high quality Java service components which can be put together in a best-of-the-breed framework a la Turbogears or something even more relaxed like Pylons. This makes me quite bit optimistc for the future of dynamic languages on the JVM.

Regards, Kay