Richard Hightower has written an article on developing a transactional persistence layer using Hibernate and Spring. He walks through a working example which uses XDoclet to configure Hibernate, and then later uses Spring to tie everything together.

Conclusion

"In this article you've learned how to implement a transactional persistence layer using Hibernate and Spring. Hibernate is a leading OR mapping tool and Spring is an AOP framework and IOC container. Together, the two technologies allow developers to write code that is database-vendor agnostic, and that can run inside of a J2EE container or run standalone. While not central to the discussion, DbUnit (an extension to JUnit) was used to build and test all of the code for the examples in this article."

Read Object-relation mapping without the container

I'd like to see a comparison with/without container using only free/open source tools, including developement time and performance tests. :)

i think this combination of Spring and Hibernate will revolutionize the J2EE industry: you don't need expensive application servers to deliver enterprise-caliber applications. Plus the development is so much faster and easier. Long live Spring and Hibernate!!! ;)

Please checkout the Petshop developed using Tapestry, Spring and Hibernate.
The demo can be reached at http://217.164.144.19:7001/petshop

is the source available?

Sun is doing a great job for the benefit of Java & J2ee.Imagine accounting without FASB or any other industry without a standarizing body. Otherwise we will witness a plethora of Cowboys in the scene. Developers are already confused -which is which way they should follow. These days, one common J2ee developers' habit is to pick on and blame Sun for everything going wrong

Faisal

Yes, I will be posting it on java.net, project is called betterpetshop

Yes, I will be posting it on java.net, project is called betterpetshop

Why not submitting it to the spring community itself? Spring already includes among the example apps the petstore implemented with two different mvc layers (I think), it would be great if the tapestry version could be included!

Why not submitting it to the spring community itself? Spring already includes among the example apps the petstore implemented with two different mvc layers (I think), it would be great if the tapestry version could be included!

Yes, we have Spring and Struts MVC versions of our JPetStore. We'd be interested to see a Tapestry version.

What was the starting point for this implementation? Clinton's iBATIS JPetStore or the Spring jPetStore?

Rgds,
Rod

Yes, we have Spring and Struts MVC versions of our JPetStore. We'd be interested to see a Tapestry version.What was the starting point for this implementation? Clinton's iBATIS JPetStore or the Spring jPetStore?Rgds,Rod

Yes, I would definitely put it to the community. I am making some minor changes to it.
This petstore was based on an Petshop hosted at http://pwp.netcabo.pt/lneves/tapestryapps/

I started using a similar approach a while ago (AOP framework I use is aspectj) and it is super-convinient.

I really like the AOP approach as well. I am toying with the idea of using it to build an EAI framework or "Adaptive Bus" as I'm calling it. The actual messaging infrastructure would be adaptable via AOP so that adapter complexity could be absorbed by weaving some service specific logic into the messaging along with refactoring declarative workflow-style functionality into an AOP layer.

I think that the most important problem with lightweight container is the necessity of a standardisation. As Sun and JCP have created J2EE specification, the same should be done for this kind of new container. Everybody is agree on the fact that J2EE should evolve in a more lightweight way. For now, dependency injection mode is not "broadly" accepted or specified (constructor?, setter? dynamic injection with bytecode processing?). APIs like Callbacks, Exception handling, DAO support, bean factories interfaces are still proprietary.

If Spring is the way to go (and i beleive in this implementation), what about Pico, Hivemind and other Frameworks ?

In Brief, please, think about IoC as a new J2EE specification which will provide one day many "compatible" and "interopable" implementation.

I think that the most important problem with lightweight container is the necessity of a standardisation. As Sun and JCP have created J2EE specification, the same should be done for this kind of new container.

Why persons have such a slavish adherence to standards? Java is not a standard (Unlike Microsoft with C#, Sun never did it)!
In my opinion, JCP standards don’t have more value than defacto standards.. What you would call a real standard - Hibernate or JDO ?

Cobol is a standard for decades... How many of us can write 1 line of Cobol ? (I even think I never saw any lines of Cobol source...).

Everybody is agree on the fact that J2EE should evolve in a more lightweight way.

I don’t remember the last time I got so excited with some software technology like IoC and AOP, and I really think that Spring is the way to go. I don’t say I will never use EJB's again, but I will use them when I think they will be really useful and not because I'm forced to be able to get, for example, declarative Transaction management.

For now, dependency injection mode is not "broadly" accepted or specified (constructor?, setter? dynamic injection with bytecode processing?). APIs like Callbacks, Exception handling, DAO support, bean factories interfaces are still proprietary.
If Spring is the way to go (and i beleive in this implementation), what about Pico, Hivemind and other Frameworks ?In Brief, please, think about IoC as a new J2EE specification which will provide one day many "compatible" and "interopable" implementation.

For me it’s a good thing that there are many different frameworks. Progress only happens when new ideas pass through the natural selection... :) Some evolve and others are rejected.

Pedro Costa

Im also very sad that you think that JCP is useless. If today you can play around with JSP/Servlet and J2EE API on multiple application servers, this is because these specifications exists. JSF, JDO and all new coming specs will contribute to spread theses technologies.
I remember a couple of years ago, everybody was attracted by Toplink, the best O/R Mapping tools. Today, this is the turn of Hibernate. And tomorrow ?
As i said, Spring is the way to go, im involved in the .NET port, you can find Rod announce there. But i would be more confident if Spring could be a part of a whole J2EE standardization process as the basis of a new kind of container. Standardization is not imcompatible with keeping contributing to Spring, otherwise i wouldn't be part of the .NET team.

For the .NET port questions, i let Rod and Mark answer.

Well the idea to port good java framework to .net is interesting as it allows .net programmers to benefit best practice from java world and will ease communication of architectural patterns between the two worlds. Spring core seems quite neutral but the challenge would be a bit harder with framework like aspectwerk, webwork or loose coupling/asynchronous one (jms pub-sub, multicaster ala jgroups or jini/javaspace).
I'm curious is there any port of good .net framework to java ? As far as I know .net cloned ant, hibernate (the project seems stale) and now spring but I'am not aware of any .net framework cloned in the java world. Is it because there isn't any yet ? is it because of the .net or java community ?

PS : is there any spring/jini or spring/jxta integration work on the way? it would provide a really powerful trully resilient distributed framework. Moreover it would help to use very loose coupling architectures.

Best luck for your port sami.

Im also very sad that you think that JCP is useless. If today you can play around with JSP/Servlet and J2EE API on multiple application servers, this is because these specifications exists. JSF, JDO and all new coming specs will contribute to spread theses technologies. I remember a couple of years ago, everybody was attracted by Toplink, the best O/R Mapping tools. Today, this is the turn of Hibernate. And tomorrow ?As i said, Spring is the way to go, im involved in the .NET port, you can find Rod announce there. But i would be more confident if Spring could be a part of a whole J2EE standardization process as the basis of a new kind of container. Standardization is not imcompatible with keeping contributing to Spring, otherwise i wouldn't be part of the .NET team. For the .NET port questions, i let Rod and Mark answer.

I think that one has to think about what level of standardization is really needed. Standards may have various roles: one of those roles is ensure portability. When "everybody was attracted by Toplink" the reason was because the model was more powerful than EJB CMP, and portability was not jeopardised. Today, everybody is excited by Hibernate not because of a freakish trend, but because it's a good project, it's portable, its performance is good and is useful in a lot of cases.

There is nothing bad about it, and I'm not sure that if Hibernate didn't exist and everyone had tried to build solutions based on JDO 1.0 implementations we would live in a better world. Standards must be introduced when there is risk of having multiple competing and incompatible solutions at the PLATFORM LEVEL: it is important that a j2ee application would be able to work almost everywhere (i.e.: on every j2ee compliant app server, but I don't see the same need for a world where a j2ee application can work everywhere even if I switch the libraries it is run against (because, for example, the ORM follows a standard, the bytecode enhancer follows another one, the mvc follows another one, and so on).

This would of course be good in a world where we are sure that the standard is mapped onto the best solution, and the standard committee is composed by geniuses which create specifications that are the best possible ones. But the history of j2ee standardization shows this is not always the case: there are "pretty good standards" (such as servlets, JMX, JCA, ...), "pretty bad ones" (such as JSP) and awfully bad ones (such as entity ejbs): if Spring + Hibernate can take my architecture to a better level, and I'm not consequently limited in the portability I can achieve, I believe this is a Good Thing, and will definitely work for them being acknowledged as a "de facto" standard.

(but I'm afraid in a year or so the JCP will create a bad copy of that model and try to make it live with a EJB 3.0 specification which will do the usual mess of otherwise good ideas).

Spring is obviously a container. Same with Pico, Hivemind, JBoss microkernel, etc...

The heading of the article should read:

O/R mapping without a J2EE container.

Bill

Is Rolf listening? Rod Johnson announced that work has started on a .NET port of Spring, today. ;)

Of course it is much better to evolve a standard through a survival of the fittest process as Hibernate has done than by a committee. IMO Spring is more than a standard though: the quality stamp of professionalism.

But is it true that the .NET port has started? Where?

Regards
Rolf Tollerud

http://sourceforge.net/projects/springnet/

Of course it is much better to evolve a standard through a survival of the fittest process as Hibernate has done than by a committee. IMO Spring is more than a standard though: the quality stamp of professionalism.But is it true that the .NET port has started? Where?RegardsRolf Tollerud

It has been announced yesterday by Rod Johnson on the spring mailing lists.

I am not quite sure what it buys you.
When i create an object i inject
its relationships or it finds them.
Why add another layer that does something
so obvious and so clear?

Hi,

is the source code for this demo available?

Well, if I look at the spring documentation, it is like

"Hey it can do a lot for you, but if you need decent transactional control, you need to bring your own JTA".

And "not reinventing the wheel" sounds nice, but if a system depends heavily on third party libraries in any Java context, it will create maintenance hell in the short run if used in conjunction with - say - major application servers.

Also, the "IoC" programming model is in my experience nice and powerful - for good programmers. Unfortunately, most programmers are probably average or below average (by the very definition of "average") and for them this model is all but straightforward.

Regards, Karl

Well, if I look at the spring documentation, it is like "Hey it can do a lot for you, but if you need decent transactional control, you need to bring your own JTA".

N.b.: there is nothing strange with that sentence. It only means "you must plug the JTA implementation of your application server". Spring includes an open source txn mgr (JOTM), but you should use the one that is provided with the application server, which is supposedly more robust.

And "not reinventing the wheel" sounds nice, but if a system depends heavily on third party libraries in any Java context, it will create maintenance hell in the short run if used in conjunction with - say - major application servers.

Why? And why a Spring application should "depend more heavily" on third party libraries whan what a normal non-spring-based application would do?

Also, the "IoC" programming model is in my experience nice and powerful - for good programmers. Unfortunately, most programmers are probably average or below average (by the very definition of "average") and for them this model is all but straightforward.Regards, Karl

Well, I wonder what kind of developer is so underdeveloped that he can't understand he must not do a lookup of the resources he needs but they will be passed to his class by the context?

Well, I wonder what kind of developer is so underdeveloped that he can't understand he must not do a lookup of the resources he needs but they will be passed to his class by the context?Well, this might be true, if the developer's only concern is doing a lookup. To put it very short, if that was the only problem and gain from "dependency injection" in the swing way, than it adds about zero value to a totally singleton based approach. Or to phrase it differently: If a project runs into problems because developers are to underdeveloped to create a lookup (possibly using a simple service locator) there is a much bigger problem anyway :-).

Well, if I look at the spring documentation, it is like "Hey it can do a lot for you, but if you need decent transactional control, you need to bring your own JTA".

Spring is an application framework, not a system service provider. In the transaction area, it offers means for convenient transaction demarcation, both programmatic and declarative, with pluggable transaction management strategies. Declarative demarcation via AOP is possible on any POJO, without being tied to a specific backend strategy like JTA; that's an important (and to the best of my knowledge, unique) value proposition of Spring's transaction support.

For single-database transactions, Spring provides alternative strategies out-of-the-box, namely DataSourceTransactionManager (for a single JDBC DataSource), HibernateTransactionManager (for a single Hibernate SessionFactory) and JdoTransactionManager (for a single JDO PersistenceManagerFactory). All of them delegate to the local transaction management of the respective resource API, typically used with local resource factories. Note that those strategies also care for the lifecycle of transaction-scoped resources like Hibernate Sessions; this is something that the JTA API does not aim to cover in the first place.

If you need distributed transactions, i.e. transactions that span multiple transactional resources, choose the JtaTransactionManager strategy. It delegates to an available JTA subsystem: either the global one provided by your application server, or a local one like JOTM. Additionally, it also cares for transaction-scoped resources. Of course, you need to access corresponding transactional resources, typically fetched from the JNDI environment. You can also use this strategy for single-database transactions, but Spring's local transaction strategies offer compelling alternatives here.

So "decent transactional control" can be achieved with both local transaction strategies and JTA; the question is rather whether you actually need distributed transactions (what JTA was designed for). Note that the local strategies DataSourceTransactionManager and HibernateTransactionManager even support per-transaction isolation levels and the read-only mode of JDBC Connections, which isn't available with JTA because of its higher level of transaction abstraction.

And "not reinventing the wheel" sounds nice, but if a system depends heavily on third party libraries in any Java context, it will create maintenance hell in the short run if used in conjunction with - say - major application servers.

Spring does not aim to provide its own system service implementations; in that sense, we avoid reinventing the wheel. An important goal of Spring is to *avoid* unnecessary dependencies: If you don't need distributed transactions, don't depend on JTA; if you don't need global resources, don't depend on JNDI. And even if you do want to leverage the latter, keep the dependencies in your configuration rather than in your business object implementations.

For simple usage of Spring, all you need is spring.jar (or individual ones like spring-beans.jar plus spring-context.jar) and commons-logging.jar. If you want to use AOP, add aopalliance.jar; if you want to use CGLIB proxies, add cglib.jar; if you need neither, omit both. Dependencies are as minimal as possible, according to your usage level. Note that Spring is already used with all major J2EE application servers (both in development and in production); no noteworthy maintenance issues reported so far.

Also, the "IoC" programming model is in my experience nice and powerful - for good programmers. Unfortunately, most programmers are probably average or below average (by the very definition of "average") and for them this model is all but straightforward.

I disagree in that respect. Sure, inexperienced programmers tend to use (and like) ad-hoc solutions, but they're usually open to learning and adopting cleaner ways of application wiring. And once you've understood the basic idea, applying it is straightforward, particularly if you have sample apps and skeletons that illustrate simple scenarios. It typically become easier to work with than ad-hoc solutions quickly.

Juergen

Juergen: "For simple usage of Spring, all you need is spring.jar and commons-logging.jar"

Well that’s great but if I could have one single objection it would be just commons-logging (which has further depencies). Doesn't 1.4 has logging packages? The logging system seems quite complex to me, the only thing that distract in an otherwise so elegant system.

Then it would be zero (0) depencies, other than standard Java!

Regards
Rolf Tollerud

Rolf,

Juergen: "For simple usage of Spring, all you need is spring.jar and commons-logging.jar"Well that’s great but if I could have one single objection it would be just commons-logging (which has further depencies). Doesn't 1.4 has logging packages? The logging system seems quite complex to me, the only thing that distract in an otherwise so elegant system.Then it would be zero (0) depencies, other than standard Java!RegardsRolf Tollerud

There is still a lot of developers stuck with appservers that run on 1.3, so we can't rely on 1.4 logging beeing available.

Thomas

Well that’s great but if I could have one single objection it would be just commons-logging (which has further depencies). Doesn't 1.4 has logging packages? The logging system seems quite complex to me, the only thing that distract in an otherwise so elegant system.Then it would be zero (0) depencies, other than standard Java!

Well, logging APIs is an odd topic in the Java world... I repeatedly wonder why we have to worry about this in the first place. It's similar to nested exceptions: Why oh why didn't Java introduce a good logging abstraction and support for nested exceptions in 1.3?

Anyway, current fact is: We need some sort of logging abstraction, and J2SE 1.4's java.util.logging obviously isn't available on J2SE 1.3 which we will have to support for some time to come. (We even had someone running Spring on J2SE 1.2 recently, which isn't even officially supported.)

So Commons Logging is more or less the only choice at this point of time. On J2SE 1.3, it's typically used with Log4J; on J2SE 1.4, it allows to delegate to java.util.logging (but is still often used with Log4J). Commons Logging doesn't have further dependencies: The 30 KB commons-logging.jar is all you need.

In general, Log4J is a good reason to not use java.util.logging but rather Commons Logging for some time to come, even on J2SE 1.4. Log4J is more powerful, and it can easily be set up locally within an application, in contrast to java.util.logging which is configured centrally (for a whole VM).

Finally, note that many other frameworks use Commons Logging too, for example: Hibernate, iBATIS SQL Maps, Kodo JDO, Struts, WebWork, Quartz. Commons Logging as the common logging abstraction allows to reuse logging configuration in an integrated solution, on J2SE 1.3 and 1.4, so it's a natural choice for Spring.

Juergen

OK. I understand.

Thomas, thank you for the excellent introduction without I seriously doubt I would have ever got "hello" on the screen! Is perfect, written for a 7 year old as it should be :)

“My status, in this case, is not at all in doubt.”

Regards
Rolf Tollerud
(You are never too old to learn)

Background: I am not a fan of Entity EJBs, but SLSB are a useful enterprise tool.

Every time I see a Spring example, it looks like more XML hell. It seems to me that there is an irreductible amount of complexity involved in writing a business application with persistent data and transactions - a finite amount of work that needs to be done either in your code, framework code, or framework code generated or otherwise driven by XML you write. Solutions that try to sweep this natural complexity under the 'external XML file' rug (CMP, and from what I can tell, Spring) just break encapsulation and make applications that much harder to evolve and maintain.

As for AOP, the main justification for it seems to be: add transactions, logging, and persistence without 'corrupting' your business object model. On the surface, this seems like a nice ideal until you see what you have to do to attain it - post-Java-compilation byte code manipulation or drop Java for AspectJ. No, thanks.

I think AOP suffers from a lack of 'big-picture' perspective from its inception - did the designers of AOP think of the terms 'pointcuts' and 'crosscutting concerns' for all of 10 minutes before deciding that's what the concepts will be called for all time? Contrast with OOP: the terms build on real-world concepts - they mean something to people who aren't programmers: inheritance, encapsulation, objects. What's a pointcut? Something that comes out of a barber's butt?

Stanley,

Every time I see a Spring example, it looks like more XML hell. (...) Solutions that try to sweep this natural complexity under the 'external XML file' rug (CMP, and from what I can tell, Spring) just break encapsulation and make applications that much harder to evolve and maintain.

Look a second time; consider the value of Inversion of Control. All that a Spring XML bean definition does is define a named instance of a class, parameterized with bean properties and/or constructor arguments. The most important benefit is wiring with collaborating objects: An object simply expects a collaborating object that implements a specific interface, via a bean property setter or a constructor argument, without having to worry about the origin of that collaborating object. The Spring bean definition defines the wiring with specific target objects for the specified instance of your class.

The alternative is reading in your own config files that define your service implementation classes and parameters: You're duplicating Spring's bean definition format then. Or hard-code your classes to work with fixed collaborating objects: In this case, you can't easily replace a specific service object with a different implementation of the same interface; you'd need to change your calling Java code to instantiate this different implementation. In a Spring application context, simply change the bean definition, without affecting your Java code by any means.

I've certainly never heard someone compare Spring bean definitions and CMP yet. Of course, EJB deployment descriptors tend to be unnecessarily elaborate, but the basic principle of defining persistence mappings in XML files applies to Hibernate and JDO too. The latter do not attempt to move business logic into XML files but just mappings of persistent classes to dataase tables. Analogously, Spring bean definitions do not move business logic into XML files (your objects still implement your business logic) but just parameterization and wiring with collaborating objects.

As for AOP, the main justification for it seems to be: add transactions, logging, and persistence without 'corrupting' your business object model. On the surface, this seems like a nice ideal until you see what you have to do to attain it - post-Java-compilation byte code manipulation or drop Java for AspectJ.

From the point of Spring, the main usages of AOP are declarative transactions and development-time helpers like logging aspects, although there are many other possibilities. Declarative transactions are the most-loved SLSB feature, so there shouldn't be much discussion about its value; AOP is simply a way to apply those declaratively on POJOs. Spring does not attempt to provide means for persisting objects via AOP: There's just resource lifecycle management associated with transactions. In a typical Spring application, persistence code is implemented in DAOs, possibly delegating to Hibernate.

Note that with Spring's AOP support, you do neither have to do compile-time byte code manipulation nor use a special language like AspectJ. Spring's AOP framework uses either a J2SE Dynamic Proxy (when AOP-proxying an interface) or CGLIB (when AOP-proxying a full target class). The former way is essentially the same that EJB containers like JBoss use for proxying SLSBs, but in contrast to EJB, you do not have to use a separate deployment unit: Simply configure a corresponding bean definition in the Spring application context, and you're done - be it for a web application, a Swing app, or a test case.

Juergen