Chris Richardson has made the source code for his Arid POJOs library available. Arid POJOs defines a custom namespace for Spring 2, that allows users to automatically define Spring bean references based on AspectJ naming conventions, instead of having to manually create each one. For example, to define Spring references for every bean in the net.chrisrichardson.arid.example.dao package, he shows the following node in Spring's XML configuration:

He says that there's an algorithm that determines the Spring name based on the concrete class, so that "AccountDaoImpl" would be created in Spring's application context as "accountDao." This is a very simple example; Arid POJOs can do more, from specifying more concise rules about what beans are created in Spring's context to managing specific injection cases. See Chris' site for more details on using Arid POJOs until the Google Code project is more fleshed out; you can also use Maven to pull down Arid POJOs.

First thing that strikes me is that for a project you could easily whip up your own "configure-by-convention" scheme a la (Ruby on Rails/Grails). Spring configuration bloat is a yucky side-effect of a beneficial platform. I'm wondering how far you could take this idea on a decent sized project. Note, I'm not talking about just web apps here but any spring-based application. 1) Decide on a packaging layout that will enable configure by convention 2) Use Arid POJOS to make a minimal Spring file to enforce that convention 3) Put your daos, services, business logic, controllers, etc in the correct packages with the correct naming scheme and never need to touch the Spring configuration file again. (yeah, right - but you see where I'm going?)

I agree with that way of thinking. Most of the time, our beans are in 2 or 3 packages : xxx.daos, xxx.managers, xxx.services. That's a fact. Arid should even be included in Spring, as it has the Spring state of mind: find simple solutions

I agree with that way of thinking. Most of the time, our beans are in 2 or 3 packages : xxx.daos, xxx.managers, xxx.services.
That's a fact.
Arid should even be included in Spring, as it has the Spring state of mind: find simple solutions

Spring 2.0 has Aspect J built in, right? I've recently started playing with 2.0 so I'm not sure how far this goes. Just wondering if Arid needs to exist or if it builds off of what is in Spring? I'm planning on spending some time this week digging into this a bit to see what the easiest way to get some CbC (configuration by convention) goin'on in Spring.

I agree with that way of thinking. Most of the time, our beans are in 2 or 3 packages : xxx.daos, xxx.managers, xxx.services.
That's a fact.
Arid should even be included in Spring, as it has the Spring state of mind: find simple solutions

Spring 2.0 has Aspect J built in, right? I've recently started playing with 2.0 so I'm not sure how far this goes. Just wondering if Arid needs to exist or if it builds off of what is in Spring? I'm planning on spending some time this week digging into this a bit to see what the easiest way to get some CbC (configuration by convention) goin'on in Spring.

Configuration by convention is one of a few concepts I believe can help make developers much more productive. Maven embraces this (Although Maven isn’t perfect) and because of that, productivity in the build process increases. Spring utilizes configuration by convention in its wiring mechanism which also improves productivity in developing applications. Other things I believe are powerful and productive include: 1. Keeping components lightweight – Good examples of this are Hibernate, EJB 3, Spring, and Mule. They employ good practices and help make developing applications easier and faster. 2. Design by Contract – I can't stress enough about how important contracts are. Contracts/Interfaces are not easy to change. I strongly recommend reading/watching the presentation "How to Design a Good API & Why it Matters" by Joshua Bloch 3. Utilize patterns consistently – Use patterns in a consistent manner. If you look how the Spring source code is written, you’ll see patterns being used consistently making learning the API easier. I think this extension to Spring is a very good one and worth while. I can't wait to see how Annotations will be abused in the year to come. Let's see, we have JPA + Guice + 100 other frameworks that will embrace Annotations instead of XML. I hope people start to understand there needs to be a balance. XML + Annotations + Java Code. Best regards, Richard L. Burton III

Configuration by convention is one of a few concepts I believe can help make developers much more productive. Maven embraces this (Although Maven isn’t perfect) and because of that, productivity in the build process increases. Spring utilizes configuration by convention in its wiring mechanism which also improves productivity in developing applications.

Other things I believe are powerful and productive include:

1. Keeping components lightweight – Good examples of this are Hibernate, EJB 3, Spring, and Mule. They employ good practices and help make developing applications easier and faster.
2. Design by Contract – I can't stress enough about how important contracts are. Contracts/Interfaces are not easy to change. I strongly recommend reading/watching the presentation "How to Design a Good API & Why it Matters" by Joshua Bloch
3. Utilize patterns consistently – Use patterns in a consistent manner. If you look how the Spring source code is written, you’ll see patterns being used consistently making learning the API easier.

I think this extension to Spring is a very good one and worth while. I can't wait to see how Annotations will be abused in the year to come. Let's see, we have JPA + Guice + 100 other frameworks that will embrace Annotations instead of XML. I hope people start to understand there needs to be a balance. XML + Annotations + Java Code.

Best regards,
Richard L. Burton III

I think I agree with everything you wrote. Spring has auto-wiring conventions but it doesn't go quite as far as what I was proposing. You still have to manually configure the beans themselves, Spring only auto-wires the dependencies. What I was proposing was that you wouldn't even have to specify the beans either - that just placing a DAO/DAOImpl in the correct package would make it known to Spring.

Keeping components lightweight – Good examples of this are Hibernate, EJB 3, Spring

If Hibernate, EJB 3, Spring are lightweight what's heavy?

If Hibernate, EJB 3, Spring are lightweight what's heavy?

J2EE 1.4

+1

Keeping components lightweight – Good examples of this are Hibernate, EJB 3, Spring

If Hibernate, EJB 3, Spring are lightweight what's heavy?

I never said Spring, Hibernate, EJB 3.x were lightweight themselves. Look at anything < EJB 3.x and they rely on implementing interfaces and such. Best Regards, Richard L. Burton III

I never said Spring, Hibernate, EJB 3.x were lightweight themselves. Look at anything < EJB 3.x </blockquote> That's the point. You need to compare them to something even more complicated. Java EE development as such has become needlessly intricate and clumsy. Many frameworks praise their simplicity but just add more layers of framework interfaces and configuration mess to the game.

and they rely on implementing interfaces and such.

I know what you mean but implementing interfaces is not per se considered a bad thing in OO languages.

Keeping components lightweight – Good examples of this are Hibernate, EJB 3, Spring

If Hibernate, EJB 3, Spring are lightweight what's heavy?

Arg. This is what I don't like about TSS. Too many trolls that like to go off topic and pretend ignorance. Don't feed the trolls.