I've just implemented a ThreadLocal mode. This is available via the AOP framework, not as a basic part of the BeanFactory as with the "singleton" and "prototype" modes. (However, it's transparent to users.) That particular feature is alpha for now. I've also added support for instance pooling, although we're not convinced it's necessary in most cases, unless objects are very expensive to configure.

It is possible to have a hierarchy of containers. Leaf containers can add or override definitions in ancestor containers. So far we haven't used this in the request-session-application scope you suggest--all containers are normally application scope. However, the suggestion is interesting.

Regards,
Rod

> (ThreadLocal) container?

What are you trying to say here? Do you mean ThreadLocal or Request container or what? ThreadLocal scope != Request Scope, unless you reset ThreadLocal container after every request (and even then it's not the sama, but close).

Request and ThreadLocal are the same if you set up and tear down the container or resources for each request.

We do this in WebWork for the ActionContext (which is a ThreadLocal map of values).

Jason

> > which is the fallback for a request
> > (ThreadLocal) container?
>
> What are you trying to say here? Do you mean ThreadLocal or Request container or what? ThreadLocal scope != Request Scope, unless you reset ThreadLocal container after every request (and even then it's not the sama, but close).

<Rod>
Note that if we do want to recover from an unchecked data access exception, we can still do so. We can write code to handle only the recoverable condition. For example, if we consider that only an optimistic locking violation is recoverable, we can write code in a Spring DAO as follows:

try {
// do work
}
catch (OptimisticLockingFailureException ex) {
// I'm interested in this
}

If Spring data access exceptions were checked, we’d need to write the following code. Note that we could choose to write this anyway:

try {
// do work
}
catch (OptimisticLockingFailureException ex) {
// I'm interested in this
}
catch (DataAccessException ex) {
// Fatal; just rethrow it
}

One potential objection to the first example - that the compiler can’t enforce handling the potentially recoverable exception - applies also to the second. Because we’re forced to catch the base exception (DataAccessException), the compiler won’t enforce a check for a subclass (OptimisticLockingFailureException). So the compiler would force us to write code to handle an unrecoverable problem, but provide no help in forcing us to deal with the recoverable problem.
</Rod>

Hm... The second code snippet and the description (in bold) are simply not true and dangerously misleading! The last catch block that simply re-throws the DataAccessException is _redundant_ and should not have been put into the example to begin with. I am surprised that such a false argument somehow made its way into this article...

I truly hope that after numerous "checked vs. unchecked" debates we all will at some point realize that we are _not_ forced to catch checked exceptions if we don’t want to handle them.

Regards,
Dmitriy Setrakyan
xNova™ - Reusable System Services for Java and .NET

I should have said "wrap and rethrow" rather than "rethrow it", assuming that DataAccessException is not in the throws clause of the method. I'll ask TSS to change the text.

Dmitriy>I am surprised that such a false argument somehow made its way into this article...

Your typo does not explain the problem described by Dmitriy.

<Rod>
Because we’re forced to catch the base exception (DataAccessException), the compiler won’t enforce a check for a subclass (OptimisticLockingFailureException). So the compiler would force us to write code to handle an unrecoverable problem, but provide no help in forcing us to deal with the recoverable problem.
</Rod>

Checked exceptions should not be blamed if the compiler does not allow you to deal with each problem differently. The exception class hierarchy used, does not allow the compiler to deal with each exception differently:
+-NestedRuntimeException?
        |
        +-DataAccessException
                  |
                   +-OptimisticLockingFailureException
 
Checked exceptions should not be blamed if the compiler provides no help in handling recoverable problems. A proper use ( understanding? ) of inheritance
might allow the compiler to help you to deal with each problem differently:
          
        +------------+---+-------------+
DataAccessException OptimisticLockingFailureException


Dmitriy> I truly hope that after numerous "checked vs. unchecked" debates we all
>will at some point realize that we are _not_ forced to catch checked exceptions if we don’t want to handle them.

I agree.

David,


A proper use ( understanding? ) of inheritance
might allow the compiler to help you to deal with each problem differently

Please pay me the courtesy of assuming I understand inheritance :-) Your alternative would allow the compiler to force handling of OptimisticLockingFailureException. However, it would mean at least 2 catch blocks (or propagation of two exceptions) every time the API was used. Users who were uninterested in optimistic locking would need to write a catch block for an exception that could never occur. JTA uses this flat exception approach, and it's painful to use in practice. The same would also apply to ever other subclass of DataAccessException. Would you promote them to top-level exceptions also?

Regards,
Rod

Rod,

>Your alternative would allow the compiler to force handling of OptimisticLockingFailureException.

I was only trying to explain the scenario (of the compiler not checking for OptimisticLockingFailureException) that you tried to describe.

The OptimisticLockingFailureException was (hidden) made subclass of DataAccessException to ease the burden (pain?) of handling it. It’s unreasonable to think that the compiler should provide help in handling exceptions that have been hidden. Its like asking the compiler to implement polymorphism. Hidden exceptions will have to be dealt with at runtime using instanceof or getCause().

By letting users know that a method may throw a given exception, the compiler is doing users a service. Only a change in attitude is required. Modern tools (IDEs etc) can ease your pain.

David,

As I pointed out, your approach would completely flatten the hierarchy and become unmanageable. Sure, a tool could generate all the catch blocks, but in most cases they would involve cut-paste code, and obscure the business purpose of the code. Why treat just OptimisticLockingException any differently from any other subclass, if you advocated promoting it to top level? I just chose this exception as an example, but there's more than that one case to consider.

Regards,
Rod

Dispite the debate about checked vs. unchecked exceptions, we have successfuly implemented and deployed a mission critical enterprise web application using Spring (all the layers) and I should say that it's been a real pleasure and productivity gain and also no problems what so ever to work with a hierachy of unchecked exceptions. Will never go back to the old thinking of checked exceptions. Againg, IMHO and the real world experience with Spring.

Regards,
Dmitriy Kopylenko
Senior J2EE architect,
Rutgers, the state university of New Jersey

I can attest that the infrastructure provided by Spring is very simple to use (particularly the Hibernate and transaction support) and very non-invasive. I use a reusable, integrated stack of Webwork, Spring, and Hibernate, and I find it very, very productive.

I'm having a hard time understanding a previous post regarding the "intrusion of the JavaBeans paradigm". When did no-arg public constructors and public mutator methods become so terrible? The BeanFactory just needs a set method, not a get method, and it makes sense - "set this configuration property on this object". And regarding the "refactoring-hostile" charge against XML configuration files - I just repackaged about half of the classes on a Spring-managed system, and I did a simple search-and-replace in the config files. It took less than a minute to do this (package name refactoring done in Eclipse, search-and-replace in UltraEdit). That's not hard.

I know folks like the Picocontainer because it doesn't require bean-wiring, but I've never found this XML to be difficult or time-consuming to write. In fact, I enjoy having it, as it consolidates both bean-wiring and configuration parameters into one place, and it's easy to read and write as far as XML goes. Plus, I can configure vendor classes through the BeanFactory, as it's very common for vendor libraries to provide no-arg constructors and set methods (there seem to be a lot of vendors out there that don't seem to mind the "intrusiveness of the JavaBean" standard either).

Bottom line though - YMMV with Spring, just like anything else. If you prefer working with checked exceptions, or if you prefer to rely on constructors for bean-wiring (good luck with vendor API's), then you probably won't be satisfied with Spring.

Rob

Rod,
  whats the relationship between this framework and CSF? is this better?

eddie

I've been looking at both Spring and JSF for a particular web application. I wonder if Spring does provides a long-term solution and if its many layers (mini-frameworks) do not compete with standards.

-JSF also provides IoC container and automatic wiring of beans (so called "managed beans"). It is pretty similar to what you'll find in Spring with all the disadvantages: Intrudes the JavaBeans paradigm on to the developer (always public classes, non-sense empty public constructor and public getter/setters that would make your private fields .... rather public). Piles of refactoring-hostile XML bean-wiring descriptors, too. In both JSF and Spring this is nowhere near the level of Picocontainer, but at least, with JSF you've got something STANDARD! (Hint: if you want to see a nice way of relaxing the most anti-encapsulation requirements of JavaBeans, read carefully the Hibernate docs…)

-In the web layer, Spring does not go much farther than Struts and Webwork, though, the MVC part is a bit more polished. But JSF aslo has a very nice one! Comparing JSF to Spring here is like comparing BMW to Hyundai. Spring just lacks out-of-the-box UI components like dynamic swing-style menus, panels, event listeners, validators, skins, multi-phased transmition of UI-bean properties to the model, etc. and conveniently leaves it to the "freedom of choice". Well, thanks!

-In my experience, Hibernate is easy enough to integrate with any sort of application (including JSF-based), and if you need to store Session in a thread local storage, just look at the excellent documentation at www.hibernate.org

My only problem with JSF is that it is a "EA4" product … Other opinions?

Hristo

You're giving Spring a minus for not being a final released project and comparing it to JSF? JSF is not anywhere near released, and we won't really start to see it creaking at the seams in production for another year.

All of those nice UI components you're touting in JSF are going to crush your server, BTW, as every click on them requires a roundtrip and re-constituting and rendering the whole graph of UI components... Think slow-ass JSP times 100 in weight... I'm yet to be convinced that JSF can be used for anything with more than 10 or 20 concurrent users.

Jason, based on my initial tests from JWSD1.2, this need not be true. I didn't get around to doing a lot of load testing, but the reconstitution is not as resource intensive as you make it out to be.

Sandeep

Jason-,
No, nowhere I referred to the release cycles of either JSF or Spring, though timing might be a crucial issue for someone's next web project.

Yes, the maintenance of far more superior UI architecture come at a price, if server RAM is an issue these days at all. But there are ways to off-load the server (Hint: look at the MyFaces approach, which, by the way, also exist in JSF EA4). The fact is that .NET Forms developers are far more productive in turning up web sites with .NET Forms and I hope JSF will be the right answer.

But that was not my point..., which was: Are the perceived benefits of Spring enough to justify the risk of a adopting yet another non-standard framework, where equally good standard ones are near completion. The Java community has been badly burned by the mirad of half-baked and defunct "web frameworks". In contrast, look at the list of JSF adopters.

On the plus side for Spring: it is OPEN SOURCE and Rob (a very nice fellow, from what I can tell) & Company are available 24-hours if you bump into a bug

Hristo

On the plus side for Spring: it is OPEN_SOURCE and Rob (a very nice fellow, from what I can tell) & Company are available 24-hours if you bump into a bug

Hristo,

> I've been looking at both Spring and JSF for a particular web application. I wonder if Spring does provides a long-term solution and if its many layers (mini-frameworks) do not compete with standards.

Spring and JSF are not direct competitors at all. JSF is "just" a web framework, albeit a rich one, while Spring is a generic application framework that happens to have web support too. You can use the Spring bean container in any environment, be it a web app, an EJB implementation, or an applet.

In particular, Spring offers a lot of goodies for middle tiers, i.e. the implementation and wiring up of business objects, data access objects, and resources. Its generic transaction infrastructure is not tied to any specific environment. JSF does not even aim to compete in this respect.

If you choose JSF, then you've got a web framework in your stack. Spring can offer great value for the middle tier here, just like it already does for Struts, WebWork, and Tapestry users.

> Piles of refactoring-hostile XML bean-wiring descriptors, too.

IntelliJ IDEA nicely refactors class names in XML descriptors. Sure, you will have to adapt bean properties names if they change, but this is just a minor nuisance in practice.

Note that the metadata in bean descriptors is not some pile of meaningless junk. It's the minimum of metadata that you need for setting up named bean instances: per bean, a name, a class, and zero or more property names and values. You could register those programmatically if you want to.

A NanoContainer will need similar metadata if it aims to set up different instances per type and populate them with both component dependencies and parameters. For PicoContainer's "configuration-less" style, Spring offers similar means in the form of the autowire feature, to be available in 1.0 M2.

> -In the web layer, Spring does not go much farther than Struts and Webwork, though, the MVC part is a bit more polished. But JSF aslo has a very nice one! Comparing JSF to Spring here is like comparing BMW to Hyundai. (...)

Spring aims to provide a clean web MVC framework that is consistent with the general bean factory approach. It does by no means aim to compete with the likes of JSF or Tapestry in terms of pre-built UI components. JSF may be an alternative for Spring's web MVC, but Spring's middle tier support and JSF complement each other.

Juergen

Thanks Juergen-,
But please, what would be these compelling reasons for the Java developer to risk depending on Spring long-term and discard a standard API.
- JSF also offers a nice IoC container for the middle tear (the so called model beans), which is pretty much like the Spring's one. No clear winner here.
- Hibernate is pretty much self-sufficient in terms of transaction management.
- I do not plan on using JDBC, so the the Spring wrapper around JDBC does not appeal to me (but might for someone else, I admit)
- JSF's MVC implementation is an equally good one: configurable navigation logic, front-end dispatching server, all the works..., but FAR MORE in the UI department, UI component listeners/events, validation, skins, tags, etc. Why would I use Spring here?
- The last time I checked the Spring's AOP implementation was dynamic proxies based and basically method-interception only. I might just want to use AspectJ for more serious stuff.

On a side note:
I looked at the Spring code and noticed that you folks like to make very, very deep hierarchies and I am a bit afraid of code where inheritance is favored over composition. But I might be wrong on that one...


Hristo

I wouldn't say that Spring is about deep use of inheritance. It heavily uses interface based design.

Regards,
Dmitriy.

While the web-ui layer is of course propriatary, most code in other layers doesn't have to have to know anything about Spring, so there is not really much of a potential issue with 'lock-in'.

> - JSF also offers a nice IoC container for the middle tear (the so called model beans), which is pretty much like the Spring's one. No clear winner here.

Please take a better look. Spring's container is _significantly_ more powerful, when you combine all the capabilities (bean container, AOP, and integrated utility classes for things like transactions and resource management).

> - Hibernate is pretty much self-sufficient in terms of transaction management.

I think Hibernate's the cat's meow, but Spring just makes it better. Rod's article mentioned the reasons (the section starting with "Why would you use Hibernate plus Spring, ..."), so I am not going to repeat them in detail here. I can just assure you after having tried both approaches that the Spring/Hibernate integration makes just makes things a lot better. Declarative transactions (or programmatic), handling of Sessions (binding to the thread as needed) and other resources, swapping configurations around for testing vs. production, the ability to easily write code (if you want to) with no dependency on Hibernate's proprietary API (except in small isolated pieces that would be easy to rewrite if you switched persistence frameworks). All of these benefits come at basically no cost.

> - I do not plan on using JDBC, so the the Spring wrapper around JDBC does not appeal to me (but might for someone else, I admit)
> - JSF's MVC implementation is an equally good one: configurable navigation logic, front-end dispatching server, all the works..., but FAR MORE in the UI department, UI component listeners/events, validation, skins, tags, etc. Why would I use Spring here?

While the Spring web-UI layer is quite nice, certainly a lot better in every respect than the likes of Struts, there are a _lot_ of tangible benefits to using Spring even without the UI layer. I generally use Spring with Tapestry as the web UI layer, and they integrate together very nicely (there's a doc on the Spring website detailing Tapestry-Spring integration). I have my misgivings about the architecture of JSF, but you could certainly use JSF with Spring and take advantage of all the other, non-UI aspects.

> - The last time I checked the Spring's AOP implementation was dynamic proxies based and basically method-interception only. I might just want to use AspectJ for more serious stuff.

Ok, or you might find that Spring handles your needs :-) What can I say, I would worry about it when the time comes. You can do a _lot_ of things with the AOP support in Spring, and the reality is that it is there to make the container a much better tool...

> On a side note:
> I looked at the Spring code and noticed that you folks like to make very, very deep hierarchies and I am a bit afraid of code where inheritance is favored over composition. But I might be wrong on that one...

There are some relatively deep hierarchies in some places (it's by no means a rule that it's deep everywhere, but if you look you might find a few hierarchies that are perhaps as deep as 4 or 5 levels). They are however quite well thought out, and have well thought-out extension points. Keep in mind that these hierarchies are all _within_ Spring. That is, the advisability of using inheritance vs. composition when working within a library is not the same thing as when you are extending a library...

Regards,
Colin

Hristo,

> - JSF also offers a nice IoC container for the middle tear (the so called model beans), which is pretty much like the Spring's one. No clear winner here.

As Colin has indicated, they only look equal from a bird's eye perspective. First of all, Spring's core bean factory implementation is pluggable: XML, properties files, programmatic. It can be applied to any kind of environment: web app, EJB implementation, standalone app, test suite, even applets. Beyond the core bean container, it offers an AOP framework with out-of-the-box transaction infrastructure and dedicated Hibernate support, among other things.

JSF is like Struts in that respect: It may offer certain means for managing business objects but purely targeting web apps. If you're fine with that and like its general approach, then go with it! If you want to have clear layering with a dedicated middle tier, being able to reuse your business and data access objects in standalone apps and test suites easily, including declarative transaction support, then I suggest to adopt Spring as middle tier framework.

> - Hibernate is pretty much self-sufficient in terms of transaction management.

I absolutely appreciate Hibernate, no doubt. But I think Gavin will agree that transaction management is not Hibernate's main concern, just like it isn't JDBC's. Native transactions are an important core functionality of a data access tool. What middle tier frameworks give you is high-level transaction management, both declaratively and programmatically; compare Spring's capabilities to EJB CMT with local SLSBs here.

A speciality of Spring's transaction management is that it uses a pluggable strategy than can adapt to the environment. Switching your declarative transactions from native Hibernate to JTA is just a matter of configuration. Additionally, there are a couple of neat extra features, like the ability to export Hibernate transactions to plain JDBC code, with the latter not being aware of participating in a Hibernate-driven transaction.

> - JSF's MVC implementation is an equally good one: configurable navigation logic, front-end dispatching server, all the works..., but FAR MORE in the UI department, UI component listeners/events, validation, skins, tags, etc. Why would I use Spring here?

If you like to build your web UIs from existing components, then choose the likes of JSF and Tapestry. Spring's web MVC is intended for view developers that like to control the details of the HTML/JavaScript code (using JSP/Velocity/Tiles/etc as view technology); this addresses both rather simple web views and very sophisticated ones. Spring's web framework focuses on controllers with pluggable views, although we do offer a basic JSP tag library.

> - The last time I checked the Spring's AOP implementation was dynamic proxies based and basically method-interception only. I might just want to use AspectJ for more serious stuff.

Spring's AOP implementation will use J2SE proxies for interfaces and CGLIB for full classes. It's about method interception only, by design: This is the single most important hook that typical applications need, especially as it respects encapsulation. We are able to provide this for individual instances, without needing control over the class loader (like JBoss 4). For anything beyond, choose AspectJ which is basically a language extension.

Juergen

There are a lot of neat ideas and smart people behind this project, but it doesn't appear to have gained any transaction in the user community.

There are about 20 downloads a day off of the website, about 3 messages a day on the user list, and a Wiki that consists of hyperlinks back to the Sourceforge page.

There are already a lot of options out there for AOP frameworks, IOC containers, and would-be Struts replacements, so users may need a more compelling reason to switch than "Yeah, but we like our design better."

Perhaps there need to be more concrete, functional components shipped with the framework so that developers feel like they are getting more out-of-the-box functionality when they begin to play with it.

Be careful to judge on the basis of user mailing list activity, especially with a young project. There are quite a lot of people using Spring that are completely silent there. Additionally, some people choose to join the developer list instead, or ask on the SourceForge forums. We're also supporting quite a few people by personal email or even by phone.

I'm personally actively supporting Spring users on the Hibernate forums, as we've got numerous people adopting Spring as their middle tier framework of choice in combination with Hibernate. There's also an extensive Spring article in the Hibernate community area. Our own Wiki isn't properly set up yet, admitted; we're currently using the main website as our public entry point.

> There are already a lot of options out there for AOP frameworks, IOC containers, and would-be Struts replacements, so users may need a more compelling reason to switch than "Yeah, but we like our design better."

A lot of options in terms of web frameworks, sure. We even offer documents on straightforward integration with Struts and Tapestry, BTW. But what AOP frameworks or IoC containers have more activity than Spring? PicoContainer and Nanning don't, as far as I know; they don't even have a user mailing list or forums yet, for example. Avalon doesn't seem to be a particular pop star either.

> Perhaps there need to be more concrete, functional components shipped with the framework so that developers feel like they are getting more out-of-the-box functionality when they begin to play with it.

There is a wealth of out-of-the-box functionality, like the transaction infrastructure, the JDBC framework, and the Hibernate and JDO support, to name just a few. The web framework is also pretty rich already, offering various view technologies etc. And stuff like declarative transaction support for POJOs on web containers like Tomcat is pretty unique, to the best of my knowledge.

Typical web frameworks just give you web MVC, typical IoC containers just the bare container. Sure, you can use the Spring bean factory in a plain vanilla style too, as everything is carefully layered for minimum cross-dependencies and maximum reusability. But you can adopt it as a full application framework if you choose, serving as the backbone for all kinds of applications.

FYI, we're currently working on even more options for lightweight transaction demarcation, namely auto-proxying of POJOs via source-level metadata. Frankly, I don't know of any other project that focuses on lightweight enterprise infrastructure in the way we do. We've definitely got a vision, and we're not at all "just liking our design better" in a not-invented-here fashion.

Juergen
Spring Framework developer

According to SourceForge there have been 1,784 downloads since July, 0 before then.

If I charitably believe that 25% of the downloaders are actually using their downloads for something useful, that gives 446 users.

Nanning appears to be even younger than Spring.

As a point of comparison, Hibernate has around 80,000 downloads.

    -Mike

Uh -- and what is your point? Judge an open source product based on whether it helps you get your work done, and is useful code, not the # of downloads.

Spring and Hibernate are completely different products. You could choose to use Hibernate in conjunction with parts of Spring. You could use JSF with parts of Spring. This isn't an either or issue.

I've been reviewing Spring and Rod's book for a couple of weeks. I really like the book and a lot of the ideas present in the framework. In particular, the JDBC, Beans, and IOC layers look like they can solve a lot of real world problems (plus, you can take what you want while ignoring the rest).

Probably my biggest concern with the JDBC layer is the use of unchecked exceptions. I don't agree with the principal that is shown here. One of the things I plan to try is to take the source and change the root to be a checked exception. I'm curious to see how much of the other layers will have be be modified to work with that one change.

I know this has talked about a lot, and I really do not want to start another discussion on the pros/cons or aesthetics of checked exceptions vs. unchecked ones.

But Gregg, I've to agree with you here. My (PERSONAL) proclivities in the direction of checked exceptions prevent me from jumping on the Spring bandwagon.

Sandeep

93 000 now ;-)

But if you look carefully at the last four months of Spring statistics, and the first four months of Hibernate activity, you will see that the numbers are very similar.

Sure, we are clocking > 10 000 downloads per month NOW - when we are a 2-year old project - but noone should expect that straight away! Spring is doing very well and certainly capturing a lot of attention.

Even if I personally don't like the Spring framework way (to much inner class make the code unreadable IMHO), I really like to have meaningful JDBC exception. So, Gavin, shouldn’t this be done inside Hibernate? We could have UniqueConstraintViolationException and InvalidForeignKeyException inherits from JDBCException. Correct error codes for each database and each error could be put inside the Dialect object.

Adrien

I actually don't understand this point - what does Spring have to do with a proliferation of inner classes?

>
> I actually don't understand this point - what does Spring have to do with a proliferation of inner classes?

I think what Adrien meant was the template/callback style, i.e. to invoke a template object and pass a custom callback implementation to it. This is offered by Spring for resource handling with JDBC/Hibernate/JDO, and for programmatic transaction demarcation. But please don't confuse the *option* of template/callback style with Spring's programming model in general! It's just one way to access certain services; there are always alternative ways too:

- You can easily use the PlatformTransactionManager interface to demarcate transactions in the usual no-callback style; or switch to declarative AOP transactions via TransactionInterceptor.

- HibernateTemplate offers a lot of convenience methods that avoid callback implementations while retaining proper resource handling. Furthermore, there's HibernateInterceptor for AOP-based resource handling without callbacks.

- Adopt JDBC operation objects: No need to implement PreparedStatementSetter or ResultSetExtractor callbacks there; just subclass MappingSqlQuery and implement mapRow accordingly, then execute it whenever you need it.

Admittedly, JDBC operation objects are often kept as inner classes, but that is the application developer's choice: You can make them top level classes too. If you don't like that JDBC programming style at all, you can also keep writing conventional JDBC code but participate in Spring transactions by using Spring-specific DataSourceUtils.getConnection/closeConnectionIfNecessary methods.

Juergen

Ugggghhh.

Yes, of course it would be a good thing.

JDBC driver error codes are just awful though. So its a real pain in the ass to get right....

>
> Ugggghhh.
>
> Yes, of course it would be a good thing.
>
> JDBC driver error codes are just awful though. So its a real pain in the ass to get right....

I guess. But since Spring has already done part of the job... Hope Spring guys will accept you to stole it ;).

   Adrien

I assume there are thousands of people using the code from the book who have no idea that it's been released as an open source project. I only found out about it at the server side conference.

As an active user of Spring right now I don't tend to query the lists much as there is extensive documentation for most of the "older" features, the source and the book. I believe Rod mentioned in one of the forums that he's working on a new book as well, presumably to cover newer Spring features.

SKroah

Sean,

I would highly encourage you to subsribe to the Spring mailing lists (user, dev) It is a _great_ source of information on Spring.

Dmitriy.

According to SourceForge there have been 1,784 downloads since July, 0 before then.
There are actually 2,819 downloads showing on SourceForge now. As another poster pointed out, there are also lots of users using the code drop with my book. (I regularly get emails from them, although of course there's no way to guess numbers. I believe that my book has sold more than 10,000 copies so far, so that's one starting point.) No download was available before July although people did use CVS diectly, and quite a few continue to.

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.

Regards,
Rod

OK, I'm still at the why stage - while you guys are all arguing about detail.

What problem are you solving that java doesn't?

Decoupling of OBJECTS via XML config is a good thing? Why?
Centralising configs in XML is a good thing? Why?
Dynamic generation of java objects based upon the columns of a result set..Why?

OK, XML decoupling first. I'm not agueing against XML, it's very useful for data formats. But why decouple objects in this way. What is the benefit - OK, I'll presume your answer is:
Means at deployment time we can switch implementations really simply.

Except it's a flawed concept - you can only switch implementations after extensive test. The 'ancient' way of doing this is to replace code, compile and then test. You are removing the compile step and replacing it with a deployment step. One is done using high level language and compilation, and one is done using ascii config files. Why is ascii better than java?

Centralising configs in XML next. How often have you wished that developers would give it up. We have a database, we have DBA's on the maintenance team. It is so much better for a project to have database driven configs, centrally visible, with audit behind them. Fine you need a config to tell the app where the database is, but thats it. OK, so your config table is 'proprietary' to your project. But if you can't understand key value pairs in a database then you will struggle with XML as well.

Dynamic generation based on result sets? I have trouble with the mass movement to run time code generation. O/R tools can generate data objects to handle any situation. You then have code in the code base which is visible to all, and you test, review, compile etc without worries of hidden performance bottlenecks, or tool changes etc etc. What is so bad about data classes, why are you scared of having programmers get the code up front.
Again I'll presume your answer is something to do with 'less typing'. But I'm not saying we hand code the stuff - I'm saying we generate it and have it visible in the code base. And I'm saying it's better because everyone can understand the code.


Now, all these points are meant to be a little dense, I am truly interested in why you believe your solutions are better than the simple, 'traditional' approach which believes in OO and high level coding.

Jonathan

Jonathan,

The motivation for externalizing configuration is to minimize the hassle of coding to interfaces rather than classes. Too often this ends up being very messy, because there are two problems: 1. knowing which class to instantiate; 2. configuring that object, as different implementations of the same interface will have different configuration requirements. If you use new and apply configuration wherever you create an object, you end up with a lot of code that may need changing (especially if the object needs other objects): you've lost the benefit of coding to the interface (or having the interface at all). So people often end up with Singletons (hard to test and inflexible) or custom-coded factories. Spring provides a consistent approach to this, that allows sophisticated management of relationships between objects as well as consistent sourcing of String and primitive properties. Using a consistent approach to sourcing objects also potentially allows AOP advice, pooling etc. So we feel that there is a real problem here, and we believe that Spring provides a good solution.

Certainly you should test if you switch implementation. But this doesn't mean it's not a worthwhile goal. There are also benefits in being able to switch from stub to production implementations easily during development. Remember also that each implementation of an interface should have been unit tested to ensure that it satisfies the contract. Integration testing is still necessary, of course, but the likelihood of breakage is greatly reduced.

Having experience of both XML-driven and database-driven configuration, I've found that XML tends to work better. Database-driven configuration can become a nightmare very quickly, as typical application configuration requirements don't benefit from the relational paradigm. However, Spring is designed to allow configuration to be stored anywhere. A Spring BeanFactory or ApplicationContext could be sourced from a database. We have a JdbcBeanFactory, but it doesn't seem to have provoked much interest. However, there is no reason that anyone who wanted to couldn't implement a sophisticated database configuration strategy for Spring.

Dynamic generation of Java objects based on a result set? Spring doesn't do this, so you've misunderstood.

Our approach emphasizes simplicity and OO. Java is a great language, but there are many problems it doesn't address. Spring's configuration management aims to provide the glue that is usually custom-coded in typical applications.

Regards,
Rod

"Dynamic generation of Java objects based on a result set? Spring doesn't do this, so you've misunderstood. "

Comes from skimming! I'll read the code snippet properly next time.

Some background: I have tried twice now to get into avalon, and each time give up because you have to buy their entire world view. Plus james didn't install on the latest avalon release (given 2 hours of trying).

So, getting back to XML decoupling of objects. I'm cool with common config of COMPONENTS that require this - either from config or database. But, the suggestion of decoupling objects seems mad. But this could be the 'principle' rather than the 'practice'. i.e. in reality a web site may have only 3 or 4 main classes requiring this type of config. Is that the way you see it?

Jonathan
ps If you can port james onto spring that would be really fine.

Jonathan,

Some background: I have tried twice now to get into avalon, and each time given up because you have to buy their entire world view.
Hopefully Spring won't prove that hard because we try hard to avoid imposing special requirements. E.g. application code doesn't normally need to depend on Spring. All you need to do is provide a no-arg constructor and whatever JavaBean properties you need. And countless existing classes can be used in Spring.


So, getting back to XML decoupling of objects. I'm cool with common config of COMPONENTS that require this - either from config or database. But, the suggestion of decoupling objects seems mad. But this could be the 'principle' rather than the 'practice'. i.e. in reality a web site may have only 3 or 4 main classes requiring this type of config. Is that the way you see it?

Spring is about the way you see it. The distinction between "component" and "object" is a tricky one. Different developers and different applications may take a different approach. If you wanted to configure only 3-4 business objects with dependencies on other objects, config parameters etc. that would work very nicely in Spring. You're free to choose whatever granularity of object you want to manage via Spring. I tend to use a finer level of granularity (partly because it seems to naturally fall out of practising test driven development), but that's a matter of usage. My personal rule of thumb is that if there's a benefit in coding to an interface, rather than a class, there may be a benefit in externalizing the configuration.

Other things I've found good to externalize are resource dependencies like DataSources (pluggability can be very useful here) and anything that might ever be implemented as a local EJB rather than a Java class. In this case, Spring will be able to create a proxy for the EJB based on configuration change, without impacting Java code or making it depend on the JNDI and EJB APIs.

Regards,
Rod

So, getting back to XML decoupling of objects. I'm cool with common config of COMPONENTS that require this - either from config or database. But, the suggestion of decoupling objects seems mad. But this could be the 'principle' rather than the 'practice'. i.e. in reality a web site may have only 3 or 4 main classes requiring this type of config. Is that the way you see it?

We have more then 100 objects (interfaces) and XML bean factory works VERY nicely for us. With out it it would be REALLY messy.

Dmitriy.

First of all, I don't think people are trying to solve things that Java does not solve. It's a framework on top of Java solving real world problems, everybody encounters every day. It does not (try to) provide theoratical concepts, solutions Java does not provide...

One of Spring's main focusses is being non-intrusive and I think Rod et. al. have done a _great_ job at that. The JavaBeans approach is a great way of development, advocating interface based design and removing dependencies on frameworks.

From this point of view, I think it's better to 'code' your configuration in XML, rather than providing some god-object-like classes that put together you're objects and collaborators. The concept of leaving your configuration out of your code - be it based on XML, databases, properties-file, etetera - removed another dependency on whatever configuration mechanism you're having.

Ok, right now it's XML. Every open source project always screams that it's going to implement other storage facilities for configuration, besides XML. Well, the Spring people have not yet developed other storage facilities, but in fact, it's not that hard. If you want a database based approach, go ahead.

I agree with you partly on the testing issues of configurations. However, I've developed three applications right now using Spring and in each of them it turned out that configuration flaws we're 1) limited to a few and 2) always appeared at deployment time. I didn't have to constantly test the complete application, since the errors always turned up during startup. I do agree however, that somehow there should be syntax checking or a like...

I can't say much about the third issue you're raising, since I'm not using the result set features...

>I am truly interested in why you believe your solutions are better than the simple, 'traditional' approach which believes in OO and high level coding.

I think Spring allows for better separation of responsibilities in development (due to separation of configuration and clearly defined contracts between MVC and business logic, business logic and transactions, etcetera). Also, I think Spring makes your code better testable and easier reusable. Why? Again because of 1) the clear separation of responsibilities (IoC, MVC, transaction, persistence, etcetera) and 2) because of the non-intrusive way the JavaBeans based approach offers...

Furthermore, my opinion basically is: if something has shown its value after using it a couple of times I don't really care about wether or not it's better in concepts than anything else. I've gained more than I lsot using that specific something, so I might as well just continue to use. Just give it a try...

Hi,

"Furthermore, my opinion basically is: if something has shown its value after using it a couple of times I don't really care about wether or not it's better in concepts than anything else. I've gained more than I lsot using that specific something, so I might as well just continue to use. Just give it a try..."

I agree, which is why I need concrete reasons. I'm pretty happy with JSP/Struts/OR. Bespoke security and audit.

It's worked many times, is mainstream and gives a highly portable skillset.

Jonathan

:). I forgot to mention here that looking into new approaches is always important! Though I was happy with Struts for instance, I kept being on the lookout for better solutions. Once I found Spring, had some spare time and tried it out, I considered it to be a reasonable alternative. Research is really important in my opinion. Without that we would still be using Cobol or something, just because it proved itself once!

Alef,

"Once I found Spring, had some spare time and tried it out, I considered it to be a reasonable alternative."

It's the spare time bit - I'm trying to piggy back on others experience!

Jonathan
ps I agree about research. It's why I like the server side.

>
> What problem are you solving that java doesn't?
>

Common ones that have been solved time and time again, and putting them in an elegant, reusable framework simply so you don't have to go over the same, well-trodden ground again.

> Decoupling of OBJECTS via XML config is a good thing? Why?
> Centralising configs in XML is a good thing? Why?
> Dynamic generation of java objects based upon the columns of a result set..Why?
>
> OK, XML decoupling first. I'm not agueing against XML, it's very useful for data formats. But why decouple objects in this way. What is the benefit - OK, I'll presume your answer is:
> Means at deployment time we can switch implementations really simply.

You presume wrong. Its more than that - its removing the difficulty with obtaining a handle on some objects. Lets say I have an application scoped business object, inventively named Foo, and another business object Bar. Foo at some point needs to operate on Bar, but how does it get hold of Bar to operate on it? You could use the singleton patter (ugh) or you could bind it in the application context of your web application. Which means that at some point, something needs to know that it is operating in a web environment, and needs to be responsible for extracting Bar (knowing also the name that it is bound with) and give it to Foo.

Or:

You use Spring and let Spring create an instance of Bar and give it to Foo. Its so easy to do, why wouldn't you?

Plus it gives you an generic application scope that you may not necessarily have already (ie. outside of a web context), and an application level event model.

>
> Except it's a flawed concept - you can only switch implementations after extensive test.

And extensive testing is one thing this framework facilitates. Encouraging objects to be more bean-friendly and container-independent lends itself to testing for starters. But also, by actively encouraging the widespread use of interfaces, it makes it really easy to use dummy and test objects throughout, before dropping in live implementations.

>The 'ancient' way of doing this is to replace code, compile and then test. You are removing the compile step and replacing it with a deployment step. One is done using high level language and compilation, and one is done using ascii config files. Why is ascii better than java?

I don't follow your point. Spring does not obviate the need for compilation and testing. It does however mean that you can wire up your objects anyway you like, and they do not need to be aware of how they obtain references to each other.


>
> Centralising configs in XML next.

Not necessarily the case. Spring has an XML Bean factory out of the box, yes, and that is likely to be the most commonly used implementation. But the bean wiring functionality is implementation agnostic (So you can use properties files or plain application code to build your beans). So if you *really* wanted, you could store all your configs in the database with very little effort.

> How often have you wished that developers would give it up.

Sometimes, but not nearly as often as I've cursed someone for putting all of the application configuration in the database. (There is a place for both, and I've done both, but I happen to believe that application configuration that can change only at deployment time belongs in an external configuration file produced by your deployment process)

> We have a database, we have DBA's on the maintenance team. It is so much better for a project to have database driven configs, centrally visible, with audit behind them. Fine you need a config to tell the app where the database is, but thats it. OK, so your config table is 'proprietary' to your project. But if you can't understand key value pairs in a database then you will struggle with XML as well.

Well firstly, what if you don't have a database?

Secondly, the spring config isn't just for key/value pairs. You use it to wire up maps, lists and instances of your application objects, which is far more powerful.

Thirdly, for example, lets say you have an application with three front-end web application servers behind a load balancer, and one database. Now, you want to make a release with new configuration information that breaks your old version. For maximum availability you will want to upgrade each of your web applications in turn. With an externalised config (that may be server specific for all you know) its a matter of deploying a new WAR on each server in turn. But what if all of the applications are drawing on the same, global, configuration table? You have to bring *all* of your servers down, change the config in the database, make your release, and bring the servers back up.

Fourthly, I prefer my deployments to consist of as few steps as possible:
Build WAR - Deploy WAR
as opposed to
Build WAR - Update database configuration - Deploy War
or realistically,
Build WAR - Stop Web Application - Update database configuration - Deploy War - Start Web Application

Database configuration works for parameters that are definitely global, and that it may be necessary to change at runtime. This is definitely not what you would use spring configuration for.

> Dynamic generation based on result sets? I have trouble with the mass movement to run time code generation. O/R tools can generate data objects to handle any situation. You then have code in the code base which is visible to all, and you test, review, compile etc without worries of hidden performance bottlenecks, or tool changes etc etc. What is so bad about data classes, why are you scared of having programmers get the code up front.
> Again I'll presume your answer is something to do with 'less typing'. But I'm not saying we hand code the stuff - I'm saying we generate it and have it visible in the code base. And I'm saying it's better because everyone can understand the code.
>

I'm sorry, but I don't understand your point here - dynamic generation of what? I'll admit I'm no Spring master, so this maybe some functionality I've not come across, but I don't know what features you're referring to. Spring gives you direct access to JDBC resultsets really simply if you need it. You can then map these resultsets to objects of your choosing anyway you like if you need to. It also allows you to combine this with declarative transactions through dynamic proxies if you need it. It also lets you drop in hibernate, or anything else, instead of JDBC if you need it. Where's the problem?

>
> Now, all these points are meant to be a little dense, I am truly interested in why you believe your solutions are better than the simple, 'traditional' approach which believes in OO and high level coding.

The thing I liked most about using spring, once I started using it, wasn't anything specific in its feature set. It was the fact that I found my code became more elegant, more loosely coupled and more OO as a result. It freed me from worrying about how the hell my objects were going to get a handle on each other, junked any singleton patterns that might have been lying around, removed many domain-specific dependencies that made testing such fun, and practically begged me to use interfaces all over the place. I found myself writing the code I'd always wanted to write, but not quite been able to due to the constraints of working with existing web application and framework functionality. This is an intangible benefit, granted, and quite subjective, but this has been my experience of Spring.

Dave,

nice answers.

"You use Spring and let Spring create an instance of Bar and give it to Foo. Its so easy to do, why wouldn't you? "

I disagree with this bit, using a 'context' object hidden behind singleton is way simpler than buying into a framework. But...

"Plus it gives you an generic application scope that you may not necessarily have already (ie. outside of a web context), and an application level event model. "

I'm happier with this. But it is not at all hard to create an application context. As we know.

Anyway, thanks for the post, it was what I was after.

Jonathan

>
> I disagree with this bit, using a 'context' object hidden behind singleton is way simpler than buying into a framework. But...

Using a singleton is definately simpler, and we used that extensively. However, as the app got larger so did the singleton until it was unmanageable. We then split it into a few managable singletons, and after a while the code was a complete mess. Singleton's are a simple solution which is effective in a simple app. However, as the app grows, it is very hard to maintain (and even harder to test). It is also very difficult to avoid over-coupling when using Singletons, and test-driven development is also hard.


>Again, after as much detail as possible here. There has to be compelling ?>reason to invest in a new framework.

>It's the spare time bit - I'm trying to piggy back on others experience!


As far as a compelling reason to switch from a framework that works, it's hard to quantify and is usually a subjective evaluation based on the experience of the developer, but I'll try to give some ideas. To speed up development. To improved a programs design. To make testing easier. To gain features not available in the current framework. To allow an application to grow beyond the capacity (reasonably) allowed by the existing framework. To reduce the learning curve of new team members. You need to see what the "cost" of using your current framework is compared to the "cost" of learning Spring and using it. My evaluation back in February was that the benefits outweighed the costs, and our decision was proved correct. My personal experience (and that of our company) is that Spring's value far exceed makes development simpler and quicker while at the same time reducing learning curve and seamlessly allowing/supporting other best practices like interface-based design and TDD.

I haven't looked deeply at Spring ... I'm a little busy with HiveMind :-)

Jonathon Gibbons wrote:

> Decoupling of OBJECTS via XML config is a good thing? Why?

People often use the terms "objects", "components" and "services" interchangeably. They aren't.

I don't think it would be worth the effort to code objects together.

By my definition, a *service* is more than just an *object*. In practical terms (somewhat HiveMind-centric) a service is going to be an implementation of a service interface, combined with some amount of configuration, including connections to other services, plus interceptors around the core service implementation, plus proxies to apply the service model (singleton, threaded, pooled, etc.)

Once you start seeing a network of services working together as your basic application model, and you still want thread-safety, singletons (or other service models), and easy configuration ... XML starts looking like a sweet way to express all that.

XML also does an excellent job acting like "glue". The objects you don't write (either because you can grab them off the shelf, or because they just aren't necessary) are often more important than the objects your do write. The expressiveness and flexibility of XML is what allows this kind of dynamic binding to actually work.

> Centralising configs in XML is a good thing? Why?

In addition, once you externalize all these connections and relationships as XML, you can do some nifty things, such as document all those connections centrally.

These kinds of descriptors (in Avalon, Spring, HiveMind, etc.) exist to complement the static structure of your application; they augment your Java classes. The dynamic structure of your application (the kind of data that will vary over time, such as preferences) should be stored into a database.

I just started evaluating the Spring framework, and I agree with some of the concerns expressed in the message. It seems that the Spring framework approach is "less coding, more configuration". I wonder whether this is a good approach. While it may seem nice on the surface, this approach just moves the complexity out of the Java code to the XML configuration files.

This is by far the biggest complaint that one hears about J2EE (fortunately, XDoclet solves the problem quite nicely). Also, the large amount of XML configuration is a big issue with Struts. The Spring framework seems to bring the problem to an entirely new level.

To take things to the extreme (and I am not trying to suggest that this is what Spring is doing), it would be possible to create a proprietary XML-based syntax that could describe your whole application logic, so that no coding needs to be done whatsoever (basically, this would be equivalent to creating an entirely new interpreted language). Would anyone argue that this is a good thing?

It seems that the Spring framework approach is "less coding, more configuration". I wonder whether this is a good approach. While it may seem nice on the surface, this approach just moves the complexity out of the Java code to the XML configuration files...

Opinions differ on this, but I think it's important to remember the total complexity is the sum of the code complexity and configuration complexity. If you get the balance right, the total is reduced.

Personally I strongly favour getting the majority of configuration out of Java code, and have seen the benefits of doing so in many projects. Indeed, the reason I designed Spring was the problems I was encountering with existing approaches to configuration management: both in Java code, ad hoc properties files etc.

I have never seen a non-trivial application that successfully held all its configuration (both simple configuration and object relationships) in Java code. Instead I've seen a mishmash of ad hoc solutions, which work out a lot more complex and verbose than the Spring approach.

There are a host of reasons to get certain configuration out of Java code. To take just two:
- recompilation is not an option to change configuration in many environments
- A key point of interfaces is replaceability: one of the goals of Spring's configuration is to promote that

Also, remember that many of the things you can do in Spring config files you can't easily do in Java alone: for example, declarative transaction management; providing the ability to switch from a POJO implementation of a business interface to an EJB implementation resulting from a JNDI lookup.

If you compare Spring with typical alternatives in the J2EE space--such as EJB-based web applications--you'll find a lot less code and a lot less configuration. E.g. to use an EJB you'll need 2 EJB deployment descriptors, Service Locator/Business delegate etc. With Spring the XML configuration is much simpler and there is zero lookup in Java code.

To take things to the extreme (and I am not trying to suggest that this is what Spring is doing), it would be possible to create a proprietary XML-based syntax that could describe your whole application logic, so that no coding needs to be done whatsoever (basically, this would be equivalent to creating an entirely new interpreted language). Would anyone argue that this is a good thing?

This is not really relevant to Spring--as you say yourself. IMO, XSLT demonstrates that a completly XML-based programming language is not a great idea.

Regards,
Rod

Hi Rod,

I think you and all other developers on the Spring Framework have done a great job. After buying your book (btw. best J2EE literature I have read until now) I thought about using parts of the original i21 code for an upcoming project. Currently we are using parts of the Spring Framework (JDBC/DAO stuff) for that.
In my opinion the Spring Framework is a great source of inspiration and new ideas for any developer involved in J2EE. Keep up the good work and I am looking forward to the final 1.0 release.

Jürgen Denzel

Juergen said:

PicoContainer and Nanning don't, as far as I know; they don't even have a user mailing list or forums yet, for example. Avalon doesn't seem to be a particular pop star either.

A couple of months ago you hijacked a thread announcing the release of PicoContainer. Now you also come with completely unsubstantiated claims about PicoContainer not having mailing lists or forums.

http://www.picocontainer.org/project-info.html

Why are you doing this Juergen?

Aslak,

A comparison with Spring was invited in that thread by Claude Hussenet, who is not associated with Spring.

PicoContainer is an interesting project that aims to address some of the same problems as does the Spring lightweight container. I'm sure you also have an active user community, and I'm happy for potential users to make their own choice. However, as far as I can see your lists do seem to be oriented towards PicoContainer developers.

Regards,
Rod

>
> PicoContainer and Nanning don't, as far as I know; they don't even have a user mailing list or forums yet, for example. (...)
>
> (...) Now you also come with completely unsubstantiated claims about PicoContainer not having mailing lists or forums.
>
> http://www.picocontainer.org/project-info.html
> Why are you doing this Juergen?

Sorry if I have offended you, Aslak. I admit that the comparison in terms of user mailing list was a bit of a late-night knee-jerk reaction to the comment on low traffic on the Spring user mailing list.

However, I can't find any *user* mailing list or user forum for PicoContainer yet. That's not a tragedy; young projects do not have to set such things up right from the start. But what is unsubstantiated about the claim?

Regarding the accusation of hijacking that thread back then: Rod already stated that I didn't start the comparison; someone specifically asked for it. And after all, you were pretty silent in terms of specific answers there; you obviously didn't want to discuss the issues I mentioned in detail.

Juergen

Either someone in DNS world is playing the joker, or someone has moved your project with telling you Aslak!! (The doesn't bring you to any useful doccos!)

Try: http://docs.codehaus.org/display/PICO/One+minute+description

:)

>doesn't appear to have gained any transaction in the user community.
>
>There are about 20 downloads a day off of the website, about 3 messages a day
>on the user list, and a Wiki that consists of hyperlinks back to the >Sourceforge >page.

I am always amaized by this argument: the majority is using XYZ product, so it
must be the best one around.

Majority of people in North America drive Ford, but this doesn't mean (at least
to me) that Ford makes the best cars on planet and that Mercedes-Benz is crap.
The majority often doesn't really care about their choice and following them is
not an attractive option to me.


> There are already a lot of options out there for AOP frameworks, IOC containers, and would-be Struts replacements, so users may need a more compelling reason to switch than "Yeah, but we like our design better."
>
> Perhaps there need to be more concrete, functional components shipped with the framework so that developers feel like they are getting more out-of-the-box functionality when they begin to play with it.

If I'm not mistaken, Turbine, Expresso and Keel and partly Echo application
frameworks have been and continue to offer tons of "out-of-the-box
functionality". I, personally, is trying to avoid this overload of bundled solutions as much as possible. That's why my favorite J2EE framework is
Maverick, which is exceptionally non-intrusive and allows me to choose whatever
components, libraries and templating engines I wish to use for a given project.

But generally I agree that there are so many frameworks without some kind of
comparison documentation (preferrable usage, performance, targeted audience,
etc.) which makes it hard to find the best for the given job or project.

Regards,
Valeri

frameworks have been and continue to offer tons of "out-of-the-box
functionality". I, personally, is trying to avoid this overload of bundled solutions as much as possible. That's why my favorite J2EE framework is
Maverick, which is exceptionally non-intrusive and allows me to choose whatever
components, libraries and templating engines I wish to use for a given project.

Glad to see that there are like-minded people out there. 8-)

Sandeep.

I am always amaized by this argument: the majority is using XYZ product, so it must be the best one around.

Hmmm... I don't really think that was my point. But if I am going to adopt an ambitious framework like this into my projects, it is important to me that there is a large, active user community iterating the codebase in real-world environments.

Fortunately, this thread helps to reinforce that there are a lot of passionate, intelligent people that are invested into the framework.

As a leader of a local frameworks group www.frameworks-boulder.org I must say that everything that is being said in this thread is music to my ears!!

Spring IS next on my list to get to know more about.

<quote>
But generally I agree that there are so many frameworks without some kind of
comparison documentation (preferrable usage, performance, targeted audience,
etc.) which makes it hard to find the best for the given job or project.
</quote>

I really agree with this... Here are my opinions and questions:

- We all working with Java and most of the frameworks try to say: we are following the KISS principle and independent of certain Java implementation technologies like Struts, EJB, Hibernate, etc. My question: if you are following the KISS principle why don't you just say: use interface-based development strategy. That's it. For this purpose you don't need to add a long hierarchie of your framework interfaces and classes. As long as you define everything in standard Java interfaces, you can implement them with different kind of Java implementation technologies independently.

- Now let's take a look at the Business Layer first. I feel that many developers are afraid of EJB. IMO, use EJB (SLSB, MDB, Timer) and JDO/OR-Mapper instead of EB. EJB development is:
-> standard (J2EE),
-> simple because you can learn it everywhere (a lot of good books, docu),
-> cheap (very good Open Source production EJB containers like JOnAS) and
-> easy maintenable (a lot of EJB developers available, slowly but surely)
And if you are using interface-based development strategy (just by adding simple Factory, EJBDelegate and DTO) you are already independent from the EJB technology itself, although sometimes I think that those independencies are useless because the points I already mentioned above. Adding framework dependency like Spring or Keel in your application means adding complexity and it will be difficult to find developers, who can easily understand and maintain the structure of your application.

- This is also applicable with the Presentation Layer. You are dependent on Struts or WebWork or Enhydra or Swing or SWT or whatever but at least you can find developers to maintain your application.

- I also think that nowadays we can write every domain oriented applications (financial, learning, ERP, etc.) with the help of Application Server containers. Why? Because you can just start one application container, which contains:
-> Business Layer: e.g. EJB/Hibernate,
-> Presentation Layer: e.g. Servlet/JSP and Swing.
at one time. And you can distribute this easily (and of course for free) to your client, thanks to Open Source application servers like JOnAS and JBoss. It's indeed very easy to let a Swing application run within the container with help of the service-oriented architecture from JOnAS or JBoss (Yes, one and only one JVM for starting EJB container, Servlet container and standard Java application like Swing on the same time). The advantage of this method is that you can easily use the same application on the server too, so at the end we get the "distribution transparancy" in our application.

- So, I don't see any value added of new containers like Pico, Avalon or other frameworks like Spring or Keel... Do I miss something here? ;-)

- If you want to become independent, then you will have to be independent of Java itself and MDA/UML would be the way.

Cheers,
Lofi.
http://www.openuss.org

> Maverick, which is exceptionally non-intrusive
> and allows me to choose whatever components,
> libraries and templating engines I wish to
> use for a given project.

Another Maverick user here, :-)! I have tried many of these View Layer frameworks, and the Maverick is the most simple one. That's why I like it.

Other tools in my web-app box are:
- Hibernate (+ XDoclet)
- PicoContainer
- Velocity
- SiteMesh (+ JSP 2.0)

One component that I'm missing is some fancy user and permission management component that works great on web environment and is greatly reusable in many pojects. I know OSUser and OSAccess, but I'm not very comfortable with them.

Struts being popular doesn't mean it is the best,
but it means you can get documentation and support.
A friend didn't use Spring because there wasn't enough
documentation to figure out how to use it. A book on
a different version doesn't help. Early adopters will
take a risk, but the early majority wants something
more.

Remember that there are some advantages to being an early adopter. The big one is that you have more ability to influence the way things are done than with a more mature product. For example, your chance of getting something in struts changed to allow you to do something special is extemely low. Its much higher with a newer product. The developers are usually much more responsive to individual users when there are fewer of them, and changes are generally less disruptive.

Documentation is a major priority for the 1.0 release. We're not doing too badly by comparison to many projects, but we aim to improve significantly.

> but it means you can get documentation and support.
> A friend didn't use Spring because there wasn't enough
> documentation to figure out how to use it. A book on
> a different version doesn't help. Early adopters will
> take a risk, but the early majority wants something
> more.

Fair enough, although the documentation is getting better all the time.

Keep in mind however, that Spring support via the mailing list is generally quite good.

There is also an important point which I don't think many people realize in that while Spring is a 'framework', there are lots of useful things in it, and it is quite possible and easy to take advantage of some aspects without understanding others. For example, the bean factory concept is very simple, and coding with it is trivial. The Application Context is just a more powerful version of that, which adds things like interception via AOP, among other capabilities. It is quite easy and useful to use a Spring Application Context without touching the web ui layer, or specialized areas like the JDBC or Hibernate related classes.

Regards,
Colin

Perhaps there need to be more concrete, functional components shipped with the framework so that developers feel like they are getting more out-of-the-box functionality when they begin to play with it.
There have always been lots of concrete, functional components usable in Spring: the many many existing classes that follow JavaBean conventions, like the Commons data source. This is why we say that Spring is "non-intrusive" and feel that JavaBeans is the right approach. In most cases, there's no need for a "Spring component" to jump through any hoops to run in Spring. Another benefit of this is that Spring doesn't force new application code to work with its APIs, minimizing lock-in.

Regards,
Rod

> containers, and would-be Struts replacements, so users may need a more
> compelling reason to switch than "Yeah, but we like our design better."


Juergen, Gavin and others have commented on the usage stats, but from a personal point of view I don't lend a great deal of weight to whether a project has had 2000 or 900000 downloads. The important aspect for me is that it does a job that I need doing and does it well. I actually do believe that the superior design of Spring is a valid enough reason to use it over other more 'popular' options, although I do concede that as a user with very little invested in Struts et al it's easier for me to say that. It's for similar reasons that I've always opt for something other than Entity EJB's and until recently, avoided JSP as much as possible.

The Spring code is well tested and comes complete with circa 80% unit test coverage now, which lends confidence not found elsewhere. At the end of the day, our applications need these services in some form or other. Objects have to be configured, data has to be persisted and web users have to interact with business logic. If the framework does these things in a reliable, testable, elegant fashion and can be proven to be stable under load (which it certainly can in our application tests) then that's good enough for me.

I'm releasing the first phase of a global (15,000+ users) application in the next few weeks that relies on several Spring provided services. The first (and possibly the second phase) will be primetime before 1.0 final of the Spring code is released. I don't think it's a maverick attitude (no pun intended) and it's not a high risk strategy - the proof is in the pudding. Spring saves us many days of additional development and stands up to every test we have so far thrown at it.

Best wishes,
Darren.

I'm contributing to Spring, and using it in a number of live applications. So far, it has met my needs as a developer and the needs of my client. Spring's big plus is that it is focused on real-world applications and helping us (programmers) develop better applications quickly. Standards (such as JSF) are great, but only if they lead to better value. The client (at least the ones I work with) care about on-time, on-budget, inexpensive maintenance, and easy extensibility.

The getter/setters are public, and this is required for wiring everything together (and is similiar but different than the implementations used by both JSF and PicoContainer). However, this "publicness" is solely for configuration. It has been mentioned many times in the Spring forums that you should code to interfaces. The implementation requires the javabean qualities, but these don't need to be exposed inside the app. As far as "refactoring-hostile" this is totally incorrect. If I change some objects, it's very simple to change the single bean reference in Spring's xml files. To be honest, I don't think refactoring can be much easier than Spring except by hard-coding the configuration in the class (which is not something I want to do).

As far as JSF goes, it looks really good (and I look forward to trying it). However, harping on it being "the standard" doesn't buy much in my mind after seeing "the standard" with EJB. It does look promising, but only real-world use will tell. The other thing is that JSF is still early access (as you mentioned). My clients don't want to wait for the standard. There business continues, which mean so does development, even while the debate over the JSR continues.

Some other advantages of Spring have been ignored, and those are consistency and learning curve, especially considering it's broadness. To pick on JSF (only because it was brought up - I actually think it looks pretty good whenever it finally gets released) it doesn't handle the data access layer, transactions, etc. To pick on Hibernate (which I have a great fondness for, and many in the Spring community use/support) it doesn't do gui's. Spring provides a single, consistent way to approach all these different areas. Spring also gives you the choice to use some well-written Spring implementations or to plug-in other best-of-breed projects. This consistency also means that once you learn how to use/configure one area of Spring, you can apply that to other areas of Spring without learning everything again.

We are about to use Spring to clean up the DAO layer of our application. Our JDBC calls (in a haste, of course) were all coded w/the db connection being obtained inside the JDBC method as well as starting/ending the transaction (with setAutoCommit(false)). This effectively precludes us from using multiple DAO API calls in one atomic business transaction. By slapping Spring on top of the DAO, I was able to properly abstract away the transaction manager (basically make the DAO tx agnostic), as well as implement the ThreadLocal JDBC pattern (that I saw on an IBM.com article, it's just differently implemented in Rod's Spring framework, but works well). I _particularly_ enjoy the JDBC templated approach, which guarantees cleanup of resources (no more leaked db connections!). This has bitten us in the ass once or twice when programmers forget to close connections in the finally block due to whatever reason.

I don't particularly care for the MVC aspect of Spring because we use Struts already. I fail to see how Struts will be able to accomplish anything that Struts cannot, or is missing from Struts (please correct me if I'm wrong).

But as far as what it does for the persistence layer, whether you use Hibernate or not, JDBC or not, etc, it's a bliss, as far as I am concerned. What is funny, I embarked on implementing a similar JDBC template myself because I got annoyed at how similar each JDBC method was, w/very little uniqueness in the 'middle', and then midway I discovered Spring (through the Hibernate struts). We use JDBC for persistence, no Hibernate... I was opting for Hibernate, but turned down for it due to purely political reasons and sheer ignorance. Just took me a while to realize that.

You mean how Spring web MVC will be able to accomplish anything that Struts cannot, I assume? It probably doesn't: It mainly offers a different programming style for web controllers and forms, being based on interfaces (instead of having to subclass Action) and freely choosable form objects (instead of having to subclass ActionForm). Furthermore, it applies the bean factory configuration mechanism to the web tier, allowing for a consistent configuration style.

View implementations are pluggable: We offer seamless integration with JSP, Velocity, Tiles, XSLT, even iText and POI! Compared to the Struts/Velocity integration style of going via a VelocityServlet indirection, pluggable views seem much more natural. WebWork and Maverick are similar to Spring in that respect, BTW.

Generally, if Struts is good enough for you, especially if you've got existing investments in it, than stay with it for the time being! Accessing a Spring middle tier from within a Struts action is straightforward, just like with WebWork and Tapestry. Fortunately, Spring allows for easy adoption at all kinds of layers: It is a la carte, not take the whole menu or leave it.

Juergen

Well, Juergen already commented on this, but I'd like to say some more.

The main reason I chose for the Spring MVC framework is it's non-intrusiveness. We developed a major application using Struts. In fact, to be able to judge Spring, I ported the MVC part of the application to Spring. I ended up integrating Tiles into Spring and the infrastructure was ready. Then I threw away all the ActionForms and just implemented formcontroller directly accessing the object in my domain model. This was such a delight! I did not have to write specific model-stuff for the MVC side of things any more except for the controllers! I was able to use the controllers for both my website and for the Swing based management applications, rather than while using Struts, I had two different codebases living alongside eachother (one for the Swing-based apps and one for the website).

Ok, Spring does not _yet_ offer all of the features Struts offers, but a lot of things are done in a very neat way - in my opinion - cleaner and easier than with Struts.

But struts 1.1 dynabeans with validator libs means per form beans are pretty redundant. The action is still needed, but thats true whatever framework you are using....

Again, after as much detail as possible here. There has to be compelling reason to invest in a new framework.

Jonathan

Hi Alef,

It might be interesting to have an example of an controller which drive a web based application and a swing based one.

I have some questions about it.

Do you have some code?

Best regards
A. Rudolf

Spring is unique and brings the benefits that others dont....
Yeah, Yeah... right...

>>Yeah, Yeah... right...

And you know something about Spring, I suppose...

"Yeah, yeah.... right..."







We often joke that criticisms of Hibernate almost always begin with "I've never used Hibernate but ......". There's a lot of "I've never used Spring but ....." going on in this thread.

BUT... we want compelling reasons to try. Time is the item in shortest supply for many of us, so trying stuff on a medium size project is a luxury.

Jonathan

>
> Jonathan

Jonathan, I know where you're coming from.

For me, Spring looks compelling. I've some issues with it, but I could probably learn to live with those.

My main deterrent is that I spent months developing equivalent (sort of)features on my own, and don't want to dump my own heavily tested code for a framework that may be rock solid, but will introduce new paradigms into my development modality that I have to get accustomed to. We are creatures of habit, after all.

Sandeep

Sandeep,

Sure, this is a real issue for many users. If your own solution works well for you, switching to a third-party framework may not help you to deliver better solutions faster. Your code doesn't work any less well because Spring exists. The exact value proposition would depend on how much ongoing enhancement and maintenance you need to do on your own solution, the cost of migration, whether Spring meets your needs out of the box or whether you could potentially customize it or (better still) contribute features of value to all users. From what I've seen with the Spring project, pooling the talents of many good people ends up producing something better than any one (or a typical in-house team) could do alone.

Regards,
Rod

Rod,

I have a lot of respect for your book and your codebase. I think that Spring is one of those frameworks that has crossed the "wannabee" and "also ran" lines to something that needs to be adopted cautiously, but if adopted, can helped write clean, maintainable code. Specifically, architecting a service layer involves resolving a number of problems that Spring addresses in its simple (yet not simplistic) way.

I uses the word "cautiously", because there are design decisions that you make with the adoption that, like any design decisions, have far-reaching consequences both in the short term and long term.

Also, from what I've seen so far, (and I've explored a lot of the codebase, and nearly all of the documentation), I think it is easier to start using Spring on a new project, rather that retro-fitting it into an existing code base. That said, some of the concepts are easily useable "piecemeal".

Sandeep

PS: Looking forward to the new book. Loved the old one. Any projections on timeframes?

> Sandeep,
>
> Sure, this is a real issue for many users. If your own solution works well for you, switching to a third-party framework may not help you to deliver better solutions faster. Your code doesn't work any less well because Spring exists. The exact value proposition would depend on how much ongoing enhancement and maintenance you need to do on your own solution, the cost of migration, whether Spring meets your needs out of the box or whether you could potentially customize it or (better still) contribute features of value to all users. From what I've seen with the Spring project, pooling the talents of many good people ends up producing something better than any one (or a typical in-house team) could do alone.
>
> Regards,
> Rod

Sandeep,

Looking forward to the new book. Loved the old one. Any projections on timeframes?
Probably March 2004. Hopefully we might have some material up for review on TSS late this year.

Regards,
Rod

OK, a new set of whats and whys. My requirement is:

A server side framework which allows reuse for web site and server side scheduled processes. Also coupled to a fit client in c#.

My current solution is 3 code bases. The jcore lib shared between java, and j#. i.e. it cross compiles. I have my own mustering libs so total binary compatability at the protocol level - ie the c# client can share java objects and java biz logic.

Now for the server. The jcore fits into a web site, and also a polling set of server apps/jobs to handle all sorts of tasks. I am using a new O/R tool - an evolution of my own, simply because I'm interested.

So, the 'framework' should share config between website and server. I do not want the web site to run in the same process as the server suite. I may have multiple server instances running on the same machine, to seperate priority jobs - ie the most important will not be crashed by the less important.

All parts of the server will do database access, ftp access, smtp/pop3 access and coordinate via a shared file system or db tables.

I need a management gui to start/stop, pause/resume and generally manage all the jobs within the server.

Spring does the config fine but what else does it do? I already have a bespoke scheduler and emailer - but they are old and unsexy. Given this spec above, why should I use Spring?

Jonathan

Rod, are your evaluations (criticism) of Struts still valid for struts 1.1. I'd be interested in a new comparision of struts 1.1 and you spring framework.



thanx

Hi Robert,

> Rod, are your evaluations (criticism) of Struts still valid for struts 1.1. I'd be interested in a new comparision of struts 1.1 and you spring framework.

You might be interested in reading the article at http://www.springframework.org/docs/web_mvc.html -- it discusses the differences of Spring versus Struts and WebWork, focussing on the programming model. Patrick discusses specific issues in his newest blog entry at http://blogs.browsermedia.com/page/patrick -- I guess you will already have noticed the thread on his Spring vs WebWork2 discussion.

Struts 1.1 has introduced some new extensibility hooks like the RequestProcessor. It's basic programming model is still that of Struts 1.0 though, i.e. having to subclass Action and ActionForm. Spring's web MVC on the other hand is based on interfaces, with as little intrusion into application objects as possible. For example, you can use your domain objects as form objects, with numerous binding conveniences offered by the framework.

Spring's web MVC offers a lot of pluggability: views, mappings, locale resolution -- plugging in other strategies here is much more natural than with Struts. For example, Velocity is a first class view technology with Spring, not something to "integrate" via VelocityServlet redirection. We also support Tiles as view technology BTW, despite its being integrated into the Struts codebase, and iText and POI for PDF and Excel document generation.

And of course, you can adopt Spring as your middle tier framework of choice and still use Struts (or WebWork or Tapestry) as your web framework if you like to. Integration is straightforward; the Web MVC article hints at an easy way to do this. Spring offers a *lot* of functionality that's completely beyond web MVC; after all, it's an application framework for all layers that "just" happens to offer a neat web MVC solution too.

Juergen

Spring Framework 1.0 M2

https://sourceforge.net/project/showfiles.php?group_id=73357&release_id=192989

Robert,

My comments on Struts in my book were already based on 1.1.

Regards,
Rod

That's a full-house on the old buzzword bingo card: extra points to Sandeep for managing to use the words "deterrent", "framework", "paradigm" and "development modality" all in one sentence.

Are there any sample J2EE web apps developed with Spring available for download?
If not, are there any plans to develop one? An "Spring Pet Store" perhaps?

Thanks,

Rogerio

Currently there are some samples available with the project, and live versions are at http://www.springframework.org/demo.html .

Trevor

Currently there are some samples available with the project, and live versions are at

appfuse.dev.java.net

nachete

> If not, are there any plans to develop one? An "Spring Pet Store" perhaps?

We currently have 2 in the distribution: Countries and Petclinic. The former mainly shows web UI features, the latter illustrates data access in a simple web app. Additionally, we provide some web app skeletons to start with.

Actually, a Spring Petstore has been under serious consideration for quite a while! We will definitely provide a full-blown Spring/Hibernate sample web app for 1.0 final, and a Petstore implementation is a promising candidate.

As a side note, there a quite a few Spring/Hibernate apps in development and already in production (it's a popular combo), but unfortunately none of them can serve as direct basis for a sample app.

Juergen

I've been playing around with Spring for a while now and from what I see there is a lot to like. The architecture is nicely layered so you can just use the BeanFactory portion, like I have with some Struts projects (soon to be WebWork 2) projects. And it plays well we others as its completely non-invasive into your code.

For any interested, I has put up a comparsion between the component models of Spring and WebWork 2 here as well.

http://blogs.browsermedia.com/page/patrick/20031016#dueling_ioc_webwork_2_and

Patrick
http://blogs.browsermedia.com/page/patrick

studying codefarms will condition you to recognize this stuff, Spring looks interesting particularly the use of the bean properties to avoid coupling.

The thing that got my interest in codefarms was the claim that it would make my code 5 - 10 times more efficient. All these frameworks need to make similar claims to spark interest.