The Spring Framework has gotten to the milestone of a 1.0 final release. Spring 1.0 is a complete Java/J2EE application framework, covering the following functionality: lightweight container, AOP support, JDBC abstraction, source-level metadata, MVC web framework, and much more.

Announcement Excerpt

A unique benefit of Spring is the ability to apply declarative transactions to any POJO, with JTA or a local transaction strategy: This allows to have lightweight transactional business objects in any sort of environment, for example in a web app running on plain Tomcat. Spring's transaction management is also capable of managing associated resources like Hibernate Sessions, avoiding the burden of custom ThreadLocal Sessions.

Building on the resource management infrastructure, Spring's HibernateTemplate significantly simplifies the implementation of Hibernate-based DAOs, reducing typical data access operations to single statements. A similar level of convenience is available for JDBC in the form of Spring's JdbcTemplate, and for iBATIS SQL Maps 1.3/2.0 in the form of SqlMapTemplate respectively SqlMapClientTemplate.

An important characteristic of Spring is that many of its features can be used individually, without the need to adopt an architecture that's completely based on Spring. Furthermore, a Spring-managed middle tier and all the functionality it provides can be reused in any sort of environment, be it a J2EE web application with a Spring web MVC, Struts, WebWork or Tapestry web tier, or a standalone application with a Swing user interface.

Read the Spring Framework 1.0 final announcement

Congratulations!

Is there XDoclet support for Spring? Last time I tried it, I had to write tons of XML.

Congratulations!Is there XDoclet support for Spring? Last time I tried it, I had to write tons of XML.

Actually, our goal is to keep the XML bean definition format as minimal as possible, therefore avoiding the need for using XDoclet in the first place.

However, we do support XDoclet in combination with Commons Attributes for source-level metadata: for example, to define transaction attributes in your source code. Have a look at the attributes version of our JPetStore for a working example.

We will continue to support and improve both styles of metadata: in definition files outside the source code (preferably concise XML), and as metadata attributes contained in Java source code.

Juergen

Congratulations!Is there XDoclet support for Spring? Last time I tried it, I had to write tons of XML.

I understand Juegen's reasoning for not generating Spring XML files using XDoclet. However, I've found that in practice my Spring XML files become quite unwieldy. Furthermore, coding information about a bean in two different files is not practicing the DRY principle.

Therefore, I have developed a Spring module for XDoclet. It's still rough around the edges, doesn't have any documentation yet, and doesn't support everything that could possibly go into a Spring XML file. Nevertheless, it's a good start and will suffice for many projects.

Right now you can download it at http://nfjs.habuma.com/xdoclet-spring-module-1.2.jar, but I anticipate checking it into XDoclet's CVS sometime soon. You'll also need to download XDoclet 1.2, because this will depend on XDoclet's core module and several other JARs that XDoclet depends on.

Now, some may say that wiring up your beans in doclet tags defeats the purpose of IoC. I disagree. The beans will still be wired through IoC. The dependencies will still be provided by an XML file. But using XDoclet, the dependencies are all in doclet tags, not in the compilable Java code itself. That's an important distinction. That means you can still pick up that bean and reuse it anywhere you want without having to carry its dependencies. For example, you can pick it up and use it in a test case, wiring the dependencies manually as mock objects. Using doclet tags simply says that in this one application(usually the only application that my beans will be used) we're going to wire it this way. You're still free to ignore the doclet tags and the generated XML file and wire it differently in a different application.

One other thing...for those interested, I just put the source code for the Spring module out to http://nfjs.habuma.com/xdoclet-spring-module-1.2-src.zip. Enjoy.

Once more...and I promise that this will be the last time I reply to my own post...

I've just checked the XDoclet module for Spring into XDoclet's CVS. You can download it and build it yourself from CVS: :pserver:anonymous at cvs dot sourceforge dot net:/cvsroot/xdoclet

It's still rough, but I intend to refine it as time goes by.

This raises an issue I've long had about xdoclet and other markup systems (like the upcoming attributes in Java 1.5 and the attributes in .NET). You said "the dependencies are all in doclet tags, not in the compilable Java code itself." But if the doclet tags are part of the Java source (as javadoc tags or any other kind of inline markup), doesn't that mean that the dependencies _are_ in the compilable code? In other words, you can't change those dependencies without a recompilation, can you?

This to me is a problem. I know a lot of people complain about config file proliferation, but there are some things that I think you have to pull out of your source code because otherwise, you can't deploy differently without a recompilation. I would imagine that IoC wiring would be one of these things (e.g., how do you change your specific implementation of a logging service you might be wired to?). Without externalizing the details, you can end up limiting your options.

For example, Hibernate externalizes the configuration of ORM. The advantage is, I can map the same set of base objects in completely different ways, such as to MySQL or Oracle (which, for example, handle automatic generation of key values differently and require different mappings). Plus, my objects aren't coupled to any specific tags in the hibernate library. Using JavaDoc, this coupling isn't compiler enforced, but I don't know how Java 1.5 will handle this. I do know that using attributes in .NET to mark up classes does require a forced dependency. As another example, if I want to mark up a class in .NET for XML serialization, my class becomes tied to the XML serialization attributes (there are ways around this, though).

I suppose it would be interesting to hear how others are handling the balance between flexible deployment and configuration file hell. My personal take is I'd prefer the configuration file scenario, provided the configuration files were intelligently designed to be actually usable (e.g, Hibernate good, most J2EE deployment descriptors BAD).

Sorry to stick this in a Spring announcement. Congrats on the release. Also, if Spring has some official take on this, I'd be glad to hear it.

Drew: You ask some very good questions. They're a bit off-topic for this thread, but let me try to answer them as quickly as I possibly can.

Doclet code is different than Java code. Java code is compiled into the compiled class file, whereas doclet code is parsed at build-time. True, in order to change a deployment descriptor, you'll need to re-run XDoclet after changing the doclet tags, but you don't necessarily need to recompile. But that's not much different than changing a deployment file by hand and having to redeploy.

There is an important distinction to be made between code generation (such as XDoclet) and JSR-175 metadata. XDoclet tags are not compiled into the resulting class file. But JSR-175 metadata is compiled into the class file. XDoclet metadata is read once at build-time to generate some other artifact(s). On the other hand, JSR-175 metadata is read from a class file at runtime (using reflection).

When applying XDoclet-style code generation, the important thing to understand is that there is a great amount of information that is either duplicated between Java code and deployment files (class names, property names, etc) or information that is spread across multiple files. Information that is duplicated or spread-out is subject to mistakes of inconsistency or at very least require you to switch between Java code and deployment code. XDoclet enables you work in only one file (the Java source code) and handles the burden of writing all of the boiler-plate code.

Certainly, XDoclet-style code generation isn't appropriate for every project. But I've found it to be greatly beneficial in the projects I work on (specifically using XDoclet to generate artifacts for Spring, Hibernate, and TLD files).

I'd be happy to discuss this more, but to avoid getting even further off-topic, perhaps this should be posted in the discussion forums.

As I've already indicated, keeping the XML configuration concise enough to avoid the need for XDoclet is a goal of Spring (and also Hibernate, AFAIK). Of course, you can still work with XDoclet, but you'll lose exactly the benefits of externalizing your configuration: As you say, you typically recompile for any changes then. Of course, it's still possible to override those source-level values in an XML bean definition, so you still retain configuration flexibility.

Note that by using autowiring (by type or by name), the Spring XML configuration file can get *very* concise. Autowiring by type requires a single instance of each required type; autowiring by name requires a bean name that matches each property name (for non-simple properties).

<beans>
  <bean id="myBean" class="myPackage.MyBeanImpl" autowire="byType"/>
  <bean id="myOtherBean" class="myPackage.MyOtherBeanImpl" autowire="byType"/>
</beans>

If you're happy to use the class name as id, for example because you never look up your service by name and don't have multiple instances of the same class, you can even omit the id attribute. Additionally, you can specify a "default-autowire setting at the "beans" level, resulting in:

<beans default-autowire="byType">
  <bean class="myPackage.MyBeanImpl">
  <bean class="myPackage.MyOtherBeanImpl">
</beans>

However, in my experience, almost all components in non-trivial applications require some amount of specific configuration, so it's rare to be able to simply autowire: You typically have some <property> tags to parameterize your components, even if collaborating objects are auto-wired. Note that I'm talking about simple parameter values here, rather than references to other components.

Configuration values are by their very nature not something to specify in Java sources: You can implement default values for your bean properties anyway, so there's no point in specifying configuration values in source-level metadata, transforming them to an XML bean definition file via XDoclet. The only benefit that I see is generating the skeleton of your bean definition, with the class name and all properties, to be filled with configuration values in the XML file.

Juergen

As I've already indicated, keeping the XML configuration concise enough to avoid the need for XDoclet is a goal of Spring (and also Hibernate, AFAIK).

With regard to Hibernate...I'm not sure that was a goal of Hibernate, because Gavin King himself started the XDoclet module for Hibernate. If Gavin's goal was to make Hibernate mappings concise enough not to require XDoclet, then why would he have created the XDoclet module? I don't know...that's probably a question for Gavin.

But XDoclet is about much more than saving you work. Sure, in some cases XDoclet saves you a ton of work (EJB is a case in point). In other cases, it saves you only a minimal amount of work. But in all cases, it helps you avoid repeating yourself (DRY) and helps you program close to the problem domain (eg, if you're editing the Foo component, you don't have to switch to a different editor to finish defining Foo in some XML file).

Of course, you can still work with XDoclet, but you'll lose exactly the benefits of externalizing your configuration: As you say, you typically recompile for any changes then. Of course, it's still possible to override those source-level values in an XML bean definition, so you still retain configuration flexibility.

Exactly. If you don't anticipate reusing the bean anywhere else, then wiring it via XDoclet is helpful and keeps you working in a single file per component as opposed to hopping around. Should you decide to wire things up differently (or even unit-test the component), then the wiring is still separate from the compiled class file, allowing you to wire it by hand in the other contexts.

My point here is that there is a significant difference between using "myFoo = new Foo()" and "@spring.ref bean='myFoo'". In the first case, you are coupling your components in the compiled code. In the second case, you're only coupling them in the doclet tag, allowing you to change the wiring independent of the compiled class file.

Note that by using autowiring (by type or by name), the Spring XML configuration file can get *very* concise.

Indeed. I agree that autowiring is a great way to cut down on the size of the Spring XML file.

But I argue that autowiring helps my case for using XDoclet. By choosing to auto-wire, you're deciding to let something else (the Spring container) decide how to wire stuff up. At that point, what's the harm in tagging your bean with "@spring.bean autowire='byName'"? Again, it's not much, but it helps keep me working in a single file and keeps me from repeating the component's classname in two files.

Configuration values are by their very nature not something to specify in Java sources

I agree. But what a lot of people seem to miss is that you don't have to hard-code configuration values in XDoclet. That point bears repeating: You don't have to hard-code configuration values in XDoclet. One of the coolest things about XDoclet is also the one that most people overlook or just don't know about: You can specify property values in XDoclet using Ant properties. For example, perhaps you're wiring up a bean property to set some database URL. Sure, you could hard-code it in the XDoclet tag, but you'd be better of setting it to an Ant property, as in "@spring.property value='${database.url}'". This way you don't have to decide until build-time what the property is. At that point you can set it in any of the ways Ant supports: a build properties file, using the -D option on the command line, setting it in your build.xml file, etc, etc.

After several posts in this thread, I keep forgetting to mention this:

Many congratulations to the Spring team. They've put together an awesome framework and a formidable challenger to EJBs, not to mention a framework that helps write better and more easily testable code. You guys rock!

Congrats to all on the project!

Congratulations!

Congratulations to all Spring team, especially Rod and Juergen. According declared features it seems like Spring has a bright future. I haven't read docs for final release yet, but I just wonder: is Spring gives opportunity for initialize XMLbeans only, or generate JavaBeans .java-files too? Of course, I may create XSLs and small program using Xalan and generate Java classes from XML definition myself, but I thought it may be useful if this feature would have done?

Congratulation to Spring team!
Would anyone write an article to compare the Spring with other Frameworks ?
As there are several Frameworks exists on the open source world, we need to know
which framework we should to choose or maybe lock-in ?

Congratulation to Spring team!Would anyone write an article to compare the Spring with other Frameworks ?As there are several Frameworks exists on the open source world, we need to knowwhich framework we should to choose or maybe lock-in ?

It is difficult that you feel "locked in", when programming with Spring: you see all those nice POJOs coming up, and all keeps clean... The features spring provides to my app at this time are clearly separated by some AOP or proxying mechanics, and they are explicitly layed out in my configuration: as for now, I know that my persistent services are powered by spring transactional features and by the fact that Spring automatically manages my Hibernate session (using threadlocals to store it and closing it automatically). Since spring is open source, I have tracked its inner workings a couple of times when I started using its features, and now I feel reasonably confident about it: should I rely on something else, it would probably be something that I or someone in my team have done... and it would surely not be as good as the same thing is in spring. I get a refreshing feeling, with spring because... I don't want to do frameworks comparisons. It's true, after many years of endless strugglings (struts vs struts + expresso, vs turbine, vs turbine - torque, vs turbine as a service framework, vs ejbs, vs webwork, vs webwork2, vs pico - nano - nanning...) I feel that spring is "the" right way to go, and with the roadmap they have for 1.1 (JMS integration, declarative JMX exposing of beans, and so on) I am even more confident in it. Give it a try: trust me, and do it BEFORE reading any comparison. It will take you less time to read the code of the examples than trying to understand what the comparison means, and at that time you will already be too excited to turn back.

Congratulation to Spring team!Would anyone write an article to compare the Spring with other Frameworks ?As there are several Frameworks exists on the open source world, we need to knowwhich framework we should to choose or maybe lock-in ?

There is another very light-weight JDBC framework called SQLExecutor. There is an article (and thread) about it here on TheServerSide:

http://www.theserverside.com/news/thread.tss?thread_id=21231

There is another very light-weight JDBC framework called SQLExecutor. There is an article (and thread) about it here on TheServerSide:http://www.theserverside.com/news/thread.tss?thread_id=21231

Another open source library: Jakarta Commons DBUtils

http://jakarta.apache.org/commons/dbutils/apidocs/index.html

FYI, Spring's JDBC support can easily be used in a programmatic fashion. You don't need to use Spring's application context concept or transaction management for this. This is a general goal of Spring: There are no unnecessary ties to running any component in a Spring application context.

Basically, just take a javax.sql.DataSource and instantiate a JdbcTemplate with "new JdbcTemplate(dataSource)". This works nicely in a JTA/EJB environment, for example. The same applies to Spring's JDBC operation objects in the jdbc.object package.

In terms of JAR files, all you need for this style of usage (library style rather than framework style) is spring-core.jar and spring-dao.jar, and of course commons-logging.jar. See the readme in the root of the Spring distribution for a detailed list of individual dependencies.

Juergen

Congrats to everyone involved.
Steve

At this point I am not totally sure what to use it for. There looks like there is a TON of stuff in there. Some of it is pretty extensive(AOP, JDBC/Hibernate, Web Framework), other parts are just helper/wrappers to things like Quartz.

I don't think I am interested in it as a web framework (as of right now). I am pretty happy with webwork2. I am open-minded though, what else can it do for me? What does it bring to the table via webwork2/spring combined?

I like hibernate. Is there any examples of using the HibernateTemplate WITH/LAZY LOADING collection and outside a web application (perhaps just in junit).

So far, the only thing I have taken advantage of is having a couple of my object pre-populated with some information. That part is kind of cool, in that I don't have to make my objects aware that they need to load their own properties.

Thanks,

Matthew Payne

Matthew

At this point I am not totally sure what to use it for. What does it bring to the table via webwork2/spring combined?

WW2/Spring is a popular combination--while we believe that Spring MVC is an impressive web framework, we release that many people are happy with other frameworks--Struts, WebWork, Tapestry etc--and our aim is to make it easy for them to add value with Spring without ripping up their web tier.

Spring can bring a powerful way of managing the middle tier for an app with a WW web tier. E.g.:
- sophisticated IoC: even to configure WW components--there's doco on the Open Symphony web site on this. It's significantly more powerful than WW IoC, which doesn't aim to provide such a generic, full-featured, IoC implementation. IoC (specifically Dependency Injection) can dramatically simplify the configuration of applications, simple or complex. And clean up code by eliminating hard-to-test JNDI lookups, use of Singletons etc. Look at the Spring JPetStore as an example of the consequences of IoC in a web app. (The simplification is even more worthwhile in more complex applications).
- declarative transaction management without EJB: even in a web container. This is a very popular motivation.
- AOP features for declarative security etc.
- Powerful way to manage Hibernate configuration and simplify some aspects of using Hibernate. All within the consistent transaction abstraction: no more hand-coding ThreadLocal sessions
- JDBC framework significantly simplifies typical JDBC operations, allowing them to be run in the same transactions as Hibernate operations (even without JTA)
- Framework to facilitate implementing DAO interfaces that don't depend on specific technologies such as Hibernate

Atlassian are using the WW2/Spring combo in their new Confluence application, for these and other features. And they're very happy.

Others are better qualified than I to comment on the finer points of Spring/Hibernate, so I'll leave that to them...

Regards,
Rod

Rod, send me an email when you get a chance, matt at sourcebeat dot com. I want to talk to you about donating some chapters of Matt Raible's book to your site when his book gets completed. Thanks.

- declarative transaction management without EJB: even in a web container. This is a very popular motivation.

This is the transaction interceptor package, right?

http://www.springframework.org/docs/api/org/springframework/transaction/interceptor/package-summary.html

When I analyzed Sun's Adventure Builder application,
I discovered that the application does not use the declarative
transaction capabilites of EJB.

Instead, the Adventure Builder application declares transactions
in a mappings.xml file. A TransactionFilter is used to start/finish
transactions.

"The TransactionFilter which is (part of the WAF) provides Adventure Builder the ability to wrap specific request processing and response generation in a single JTA transaction. This filter based on settings in the WAF configuration file mappings.xml will demarcate a transaction and commit the transaction for specified requests. This allows requests that must access to more than one transactional resource to perform such transactions as a single unit."

http://java.sun.com/blueprints/code/adventure/1.0/docs/architecture.html

http://java.sun.com/blueprints/code/adventure/1.0/src/com/sun/j2ee/blueprints/waf/controller/web/TransactionFilter.java.html

- declarative transaction management without EJB: even in a web container. This is a very popular motivation.

This is the transaction interceptor package, right...When I analyzed Sun's Adventure Builder application, I discovered that the application does not use the declarative transaction capabilites of EJB.Instead, the Adventure Builder application declares transactions in a mappings.xml file. A TransactionFilter is used to start/finish transactions... This filter based on settings in the WAF configuration file mappings.xml will demarcate a transaction and commit the transaction for specified requests. This allows requests that must access to more than one transactional resource to perform such transactions as a single unit

Sean, indeed Spring is not the only way to do declarative transaction management in a web container. Servlet filters, as used in Adventure Builder, are another viable option.

However, Spring's declarative transaction management support is far more sophisticated and flexible than the Adventure Builder approach, or anything else I've seen implemented with servlet filters.

For example, the Spring approach:
- is built on a sophisticated transaction abstraction layer, that has support for JTA as well as JDBC, Hibernate, iBATIS and JDO transaction APIs. (If you want, you can implement support for any other local transaction API you want.) Thus you can apply declarative transaction management to POJOs, and switch from using JDBC to JTA transactions under the covers without changing your code.
- thus it works in web containers without JTA support (like Tomcat). I really should have said that Spring allows "declarative transaction management anywhere, rather than "even in a web container". I'm currently using JTA declarative transactions in the deployed environment in a headless app, running some tests under JUnit with JDBC transactions. Without changing application classes at all.
- supports core transaction management concepts such as timeouts, isolation and propagation. The mappings.xml file is pretty basic and fails to address any of these.
- Spring avoids linking transactionality to a web request scope. This is my biggest issue with filter-based approaches. Web requests are driven by user interaction; the granularity of transactions should be driven by business logic.
- allows sophisticated targeting of transactional support to particular methods on particular objects (even targeted using Commons Attributes annotations as an option). See the JPetStore example shipped with Spring. There's more freedom in targeting transactions than with ejb-jar.xml (although of course ejb-jar.xml is well in advance of a filter-based request-oriented approach).
- allows "rollback rules" enabling declarative specification of which exceptions should cause rollback, without the need to call setRollbackOnly(). This is a unique feature. It means that many POJOs can be made transactional without any dependence on the Spring transaction API or any Spring interfaces.
- addresses important resource management issues in conjunction with transaction management, such as Hibernate session management

AFAICS the Adventure Builder filter
- doesn't provide any support for programmatic rollback, via some setRollbackOnly() method, which EJB CMT and Spring both do
- has some very interesting error handling. Just about every exception seems to be considered "recoverable", and processing continues.

There really isn't any advantage for servlet filters, beyond the fact that you don't need Spring or any other framework besides core J2EE. But of course realistic applications need to use frameworks for a variety of reasons.

Spring transaction management offers a similar basic value proposition to EJB CMT, but for POJOs, and has some unique features such as choice of transaction strategy, and rollback rules. Servlet filters are not comparable to EJB CMT.

Sorry for the long post, but I feel that these are important points.

Regards,
Rod

It was said that:
"remoting support for RMI, JAX-RPC and Caucho's Hessian/Burlap, for easy exposure of Spring-managed beans"

but there's not any documentation or sample code, I am quite confused by "Spring-managed beans", could the remoting utility be used to help java classes not defined in spring's configuration file?

At this point I am not totally sure what to use it for. There looks like there is a TON of stuff in there. Some of it is pretty extensive(AOP, JDBC/Hibernate, Web Framework), other parts are just helper/wrappers to things like Quartz. I don't think I am interested in it as a web framework (as of right now). I am pretty happy with webwork2. I am open-minded though, what else can it do for me? What does it bring to the table via webwork2/spring combined? I like hibernate. Is there any examples of using the HibernateTemplate WITH/LAZY LOADING collection and outside a web application (perhaps just in junit). So far, the only thing I have taken advantage of is having a couple of my object pre-populated with some information. That part is kind of cool, in that I don't have to make my objects aware that they need to load their own properties. Thanks, Matthew Payne

These days I work on an ecommerce system that's based on a struts + spring + hibernate architecture. One of the many nice parts of spring effect in it, is that I have a number of enterprise services that are implemented as simple javabeans, with declarative transactions provided by spring. This allows me to do testing in a nice way: I test the code that relies on hibernate and the db with a TestSetup that initializes my spring context once for all the test cases, and then passes it to all the tests that need it (sort of "dependency injection" for tests): the result is that, from that point on, I can test my business services with the same configuration that will be used in the web application, but outside the container.

Even if my services use the Hibernate and transaction interceptor (which is a slightly different approach, spring supports both), HibernateTemplate is indeed very useful: with it I've implemented some utility methods that allow me to automatically persist (in the junit setUp method) a number of objects that will be the basis for the test. In the tearDown they will automatically be deleted. The code that will create and delete the objects is
HibernateTemplate template = new HibernateTemplate( sessionFactory );
(...)
TransactionStatus status = txnMgr.getTransaction( new DefaultTransactionAttribute() );
try {
    template.execute( new HibernateCallback() {
        public Object doInHibernate( Session session ) {
            try {
                if ( reverse ) {
                    for ( int k = endIndex ; k > startIndex ; k-- ) {
                        Object o = objectsToCreate.get( k );
                        action.execute( o, session );
                    }
                }
                else {
                    for ( int z = startIndex ; z < endIndex ; z++ ) {
                        Object o = objectsToCreate.get( z );
                        action.execute( o, session );
                    }
                }
                return null;
            }
            catch ( HibernateException e ) {
                throw SessionFactoryUtils.convertHibernateAccessException( e );
            }
        }
    } );
    if ( log.isDebugEnabled() ) log.debug( "committing iteration " + i );
    txnMgr.commit( status );
}
catch ( Exception e ) {
    e.printStackTrace();
    log.error( "there was an error: rolling back iteration " + i );
    txnMgr.rollback( status );
    fail();
}

(where action is a generic interface which will be implemented by two concrete objects that do the creation and the deletion of the objects). It is a pretty specific example, but since it is executed in a junit test I believe it is a good example of how spring can be used at different levels in order to ease the work with useful tools.

Matthew,

I am pretty happy with webwork2. I am open-minded though, what else can it do for me? What does it bring to the table via webwork2/spring combined?

When using a third-party web framework or any other UI framework like Swing, you're essentially using Spring as middle tier framework: It configures and wires your business objects and resources then, making them available in consistent fashion, for example to your web controllers. That's what Atlassian do with WebWork2/Spring in Confluence. Spring allows you to implement a loosely-coupled business (and data access) layer that's reusable in any environment, be it a web app, a standalone app, or a test suite.

Note that Spring cares for virtually all typical issues here: setting up JDBC DataSources, Hibernate SessionFactories, transaction managers, etc - and of course your business objects and data access objects, accessing those resources. One of the most powerful features is declarative transaction demarcation via AOP: This allows you to have transaction conveniences similar to local SLSBs with your plain POJOs, still reusable in any environment (and with greater configuration power than EJB CMT).

Is there any examples of using the HibernateTemplate WITH/LAZY LOADING collection and outside a web application (perhaps just in junit).

Hibernate's lazy loading needs an active Hibernate Session: As the Session is associated with a transaction in Spring, lazy loading will work within the transaction scope. In a web app, we provide means for applying the Open Session In View pattern. Anywhere else, like in a test suite, you can lazily load outside transactions too, simply by using Spring's lower-level resource management API accordingly. See the Hibernate forum thread http://forum.hibernate.org/viewtopic.php?t=929167 for a code example.

Juergen

I'm using Spring and iBATIS: both are extremely dynamic projects. Keep it up!

Both Spring and iBATIS have excellent constantly updating documentation (new Spring docs improved dramatically for 1.0 final).

I have read some sort of comparison between Spring and other frameworks, mostly in blogs, some scattered articles on the Net. I guess it would make sense to put them (or references) on the Spring's web site. This will make life easier for people evaluating WebWork2, Tapestry, Spring,...

...I knew right away that this framework must be something really good. His book on J2EE design was simply amazing.

how close the Spring framework is to Rod Johnson's framework described in his book ? By looking at the features Spring provides, it seems that quite a few of the design solutions were taken straight from there. It would be really nice if Spring is a development out of that framework, because some its features were really neat, such as unchecked exception hierarchy and generic bean-based initialization mechanism.

So my question is -- what exactly is the degree of similaritiy between these two frameworks ?

how close the Spring framework is to Rod Johnson's framework described in his book ?

I understand that the version in the book was one stage in the development of the framework, and nowadays only retains historical importance :) So you should not look at the code in the book very closely, but use Spring instead.

This is what Rod Johnson wrote about it in the introductory thread of Spring in autumn 2003:

To the real point of my post: I'd like to encourage people using the code drop with my book to switch to Spring. There are a lot of worthwhile new features, and support from other Spring developers and the user community.

how close the Spring framework is to Rod Johnson's framework described in his book ? By looking at the features Spring provides, it seems that quite a few of the design solutions were taken straight from there. It would be really nice if Spring is a development out of that framework, because some its features were really neat, such as unchecked exception hierarchy and generic bean-based initialization mechanism.So my question is -- what exactly is the degree of similaritiy between these two frameworks ?

Many of the core concepts--including all those you describe--came straight from the interface21 framework described in my book. Everything in Spring today is consistent with the architectural approach advanced in the book. However, Spring is a lot more extensive and sophisticated than the book framework. It introduces new functionality in such areas as:
- Hibernate support is completely new. There is also JDO support now.
- The core Inversion of Control container (derived from the "generic bean-based initialization" you mention) is now far more sophisticated, with support for collections, Constructor Injection as well as Setter Injection, bean "post processing" etc. etc.
- AOP framework
- Transaction abstraction is completely new. I envisaged this at the time of writing the book, but no one person could do all the work required to deliver this (based as it is on AOP). Thus declarative transaction management is an important feature added last summer.
- Integration with many 3rd-party products such as iBATIS, FreeMarker, Quartz

Essentially Spring reflects the architectural principles described in Expert One-on-One J2EE, but has grown way beyond the original code drop. The most important ingredients have been
- Active developer community. We get great feedback from lots of users, which has helped to improve the framework a lot. It also means that Spring has been tested in far more environments than I could test the interface21 framework.
- A team of talented developers. The original code drop was a one-man effort (although based on a lot of experience using similar concepts in various projects). Spring today has a team of talented developers: Juergen Hoeller has made an unbelievable contribution.

Regards,
Rod

because now I know which direction to move, at least in terms of MVC frameworks :) If Spring is a development of interface21, then it really is worth adopting. I cannot say that I know interface21 code in detail, but I liked very much what I saw in there (especially the new ideas and general direction), despite it being in a fairly raw form.
P.S. By and large, interface21 code (for those who had bothered to look at it) is the best PR for this framework :) just wondering, do you need any more of open source developers on the project ? ;)

I noticed that package dependency tools are complaining about cyclic dependencies in Spring. Don't know if this is anything to be worried about, but you can check it with these tools:

http://javacentral.compuware.com/products/optimaladvisor/

http://andrei.gmxhome.de/jdepend4eclipse/

Hi Artti

I noticed a large number of package inter-dependancies when I reviewed
Rod's and Juergen's book, J2EE without EJB.

I didn't use any tools that time but noticed the dependancies during review
and visual inspection of the packages - particularly the beans
packages.

I really don't think it presents a problem. It just reflects the growing
complexity of the Spring framework.

Saying that though (coincidentally), I have just had a few dependancy issues compiling another framework in both Intellij Idea and Oracle JDeveloper #;-)

Regards,

Gary Watson
____________________________________________________

I've just checked all of those: They just represent minor cyclic dependencies between individual classes in subpackages, not between the root packages. We will address them as far as it makes sense for 1.0.1.

As Gary indicated, such minor cyclic dependencies are typical effects of a growing framework: All sorts of convenience classes emerge in subpackages, sometimes getting refactored into finer-grained packages, with initial cross-dependencies.

Juergen

I've been tryed to use Spring in my little project. The ideas of transactions and other things was so interesting that I intent to use Spring.

There is only one problem: I need only one servlet to handle all requests. But all jungnles with FormControllers and other controllers is against this one servlet idea. Am i wrong?

I've been tryed to make my own logic that uses sitemap where is the things about pages and processes (somethiong like in Struts). But there was problems to configure classes to use some way Springs transactions and connections to DB. Is there some way to use beans without declaring them first in web.xml and then necessary decalring in some controller? Also is there some way to use connections and transactions without that bean is first delcared in web.xml and in controller?

There is only one problem: I need only one servlet to handle all requests. But all jungnles with FormControllers and other controllers is against this one servlet idea. Am i wrong?

Spring's own web MVC framework is just an option. You can use a Spring-managed middle tier within any web environment, be it in combination with Struts, WebWork, WebWork2, Tapestry or your own web tier implementation. (Actually, people are combining Spring with all of these, with good results.)

Have a look at our JPetStore version which features a reusable Spring-managed middle tier that's accessed from two alternative web tiers: one based on Spring's own web MVC, one based on Struts 1.1. For a further example, Atlassian's Confluence uses a WebWork2 web tier on top of a Spring middle tier.

Basically, load your Spring root context via ContextLoaderListener/Servlet in web.xml. All you need for accessing it then is a ServletContext reference: Spring's WebApplicationContextUtils.getWebApplicationContext(ServletContext) method will give you a reference to the Spring context, allowing to fetch beans by name etc. You can do this in any web component: a Struts Action, a plain Servlet, a Filter, or even a JSP.

You only need a single root "applicationContext.xml" file with bean definitions then, covering the middle tier of your application, loaded by ContextLoaderListener/Servlet. There's no need for DispatcherServlet definitions or servlet-specific context files with controllers etc.

Alternatively, you could also use Spring's transaction and resource management support in a programmatic fashion. You'd have to care for configuration of the involved components yourself then, though, so I recommend to have a bean definition XML file that configures and wires your root application context.

Juergen