Skip to main content

expojo 1.3.2 released!

exPOJO 1.3.2 has just been released.

exPOJO is a super lightweight framework that provides:
  • dependency injection in Java (no XML - say goodbye to Spring forever!) using the easy to use ModelExposer class.
  • high productivity persistence using the 'exposed POJO model pattern' to access your objects via Hibernate or JDO.
  • an ORM wrapper that helps you to build code that is portable across different ORMs.

Version 1.3.2 adds an exceptionally useful 'auto query resource clean up' class donated by Guido Anzuoni from Object Magic: Using this class to encapsulate returned query collection result you don't need to explicitly clean up the query resources associated with those results. Guido's class 'automagically' cleans up the resources when it is garbage collected. This is great for users of the OpenPersistenceManagerInView pattern. Currently Guido's class works with JDO only.

Version 1.3.2 also adds a new flushChanges method which is great when you need to establish an extremely complex object graph with cyclic references. ORMs occassionally generate FK constraints with such object graphs and the only workaround is to perform piecemeal database commits. The new flushChanges method can be called at various steps during construction of a complex object graph to perform piecemeal database commits, upon return from flushChanges the exPOJO transaction depth is restored to its previous value saving the developer from having to save/restore the transaction depth explicitly.


OMax said…
This comment has been removed by the author.
OMax said…
Repeating in last release post:
Why is this project not active anymore? Should JPA implementations now be preferred instead of expojo? What projects use expojo? Or when JPA support will be implemented? Does it work with GAE?
OMax said…
Is there a maven repo for expojo/archetype to try it out?
a.maza said…
With great interest I saw the recent release of expojo 1.4.

Is there any best practice example available how to integrate expojo with Wicket. Since wicket pages to not use servlets, I assume that the ExpojoServletFilter should target the WicketFilter in web.xml. But what is the recommended approach then to access Repositories/Services in the Wicket pages. Thanks
In answer to your questions: exPOJO is very much active though more activity occurs on the website rather than the blog.

JPA can be used under exPOJO just like Hibernate and JDO can be so that if your project uses exPOJO it remains easily portable between any framework or standard: Hibernate, JDO or JPA. The only difference is that exPOJO comes complete with Hibernate and JDO PersistenceProviderS but does not yet have a JPA implementation but if you look at the other two you'll see how easy that is for someone who has used JPA to create (and maybe contribute back to the open source project)

We are working on an example that demonstrates its use within a WIMDEX (Wicket, Model Driven, ExPOJO) stack. WIMDEX has to be one of the most productive web development stacks around.

Popular posts from this blog

exPOJO: version 1.3 released!

exPOJO Version 1.3 has recently been released.

It now makes dependency injection even easier to use. Simply configure the ExpojoServletFilter in your web.xml and voila!! Too easy.

For the lovers of the highly productive "exposed POJO domain model" pattern you will find the latest version of POJO irresistable.

Read more and download here.

exPOJO: used in major financial company's core enterprise software

A major provider of financial IT resources based in Sydney, Australia is using exPOJO to provide access to their core enterprise objects in a generic way. A variety of their integral applications use exPOJO to expose their core enterprise objects in a consistent and generic way saving thousands of developer hours whenever a new application needs to be created.

The exposed model was implemented using exPOJOs JPOX/JDO wrapper (a Hibernate wrapper is also available) as their transparent persistence solution. JPOX was chosen because it provides virtually 100% transparent persistence at the domain model level and has a significant performance edge due to its ability to perform build time byte code enhancement instead of relying on much slower run time reflection to do its job. The domain model objects are all pure POJOs without any need for annotations or the need to add extra methods to enable the underlying ORM to function correctly.

All domain models are designed and maintained using the …