Craig Walls, author of Spring in Action and XDoclet in Action, has written a blog entry showing how to use Message-Driven POJOs in Spring with ActiveMQ.

Message-driven POJOs offer MDB-like functionality to simple JavaBeans. I have found message-driven POJOs to be a compelling alternative to MDBs, especially if you're already a big fan of Spring and are using it to develop your applications. Message-driven POJOs can take advantage of all of the features provided by Spring (such as dependency injection and AOP).

One of the claims about using POJOs as MessageListeners is that they're "lighter than MDBs." This is clarified in a later section:

• MDBs must be run within an EJB container. Depending on the architecture of your app, this may be an excessive requirement, especially if you aren't use any other EJBs and do not require the features of a full-blown EJB container. Message-driven POJOs, on the other hand, can run anywhere, even (as shown here) in a simple main() method. The only requirement is an ActiveMQ message queue.
• MDBs require that you implement the lifecycle methods of javax.ejb.MessageDrivenBean. Often these lifecycle methods aren't needed and are left as empty implementations. This isn't a real problem, except that it's simply unnecessary.
• Although it may not be apparent from the simple HelloBean example, message-driven POJOs can take full advantage of the dependency injection and AOP support offered by Spring (including Spring's support for declarative transactions and Acegi's support for declarative security). In short, you can do anything with the POJO that you can do with any other bean in a Spring context.
• The XML used to declare a message-driven POJO is slightly more verbose then for an MDB. You should, however, keep in mind that you'll only need to declare one JCAContainer bean, regardless of how many message-driven POJOs your application has.

What do you think of the idea? What about the requirement for a Java EE container? Is the replacement of a JEE container with a JMS container a worthwhile trade-off?

I don't think lighter weight is the main problem for me, it's function.

What would be useful is if you could dynamically create these at runtime. Thats the main trouble with MDBs for me, they are static beasts. Applications need to be able to create new MDBs while they are running for a Destination that was unknown when the application was deployed. This pattern is used all the time by customers of WebSphere XD who are using the partition facility. When a partition is activated, the application typically creates one or more JMS destination listeners specific to the partition which has the effect of routing partition specific messages to the cluster member where the partition was activated.

The J2EE spec doesn't help here either with it's banning of certain JMS APIs required to do useful stuff in an application. We've worked around this in WebSphere when the application uses an async bean proxy for the MessageListener but still so at least you can use async message delivery albeit non transactionally.

The other question on efficiency is the threading model used to inject the messages in to the listener, this needs to be flexible/customizable also.

These would be my main gripes w.r.t. MDBs.

Billy (IBM)
http://www.billynewport.com

I don't think lighter weight is the main problem for me, it's function.What would be useful is if you could dynamically create these at runtime. Thats the main trouble with MDBs for me, they are static beasts.

Agreed, the static nature of MDBs is painful.

FWIW with Message Driven POJOs, because its all just Spring and you can make as many BeanFactory / ApplicationContexts whenever you wish, in a hierarchy and you get completely dynamic message driven POJOs. So you could have a single parent context with the JCA container and resource adapters & thread pools configured; then create child contexts with different sents of dynamically created MDPs in them.

The other really nice thing is you get to use full dependency injection on the MDPs - which is a big win - as well as other goodies like interceptors etc.

Applications need to be able to create new MDBs while they are running for a Destination that was unknown when the application was deployed.

Agreed! Its surprisingly common to need to, say, query a registry or database to find all the topics you need to consume etc.

This pattern is used all the time by customers of WebSphere XD who are using the partition facility. When a partition is activated, the application typically creates one or more JMS destination listeners specific to the partition which has the effect of routing partition specific messages to the cluster member where the partition was activated.

Agreed. Though for partitioning, you can use 'exclusive queues' as TibCo calls them or 'message groups' as others call them, to basically create consumers on all destinations everywhere, then let the JMS provider perform the partitioning on your behalf (so some subscriptions are really inactive, until there are failures and things are repartitioned.

The J2EE spec doesn't help here either with it's banning of certain JMS APIs required to do useful stuff in an application. We've worked around this in WebSphere when the application uses an async bean proxy for the MessageListener but still so at least you can use async message delivery albeit non transactionally.The other question on efficiency is the threading model used to inject the messages in to the listener, this needs to be flexible/customizable also.These would be my main gripes w.r.t. MDBs. Billy (IBM)http://www.billynewport.com

I'm in complete agreement Billy. You might like Message Driven POJOs then :)

Here's hoping Java EE version 5 fixes this stuff and provides a standard - and dynamic - message driven POJO standard. Until then, message driven POJOs are very useful.

James
LogicBlaze

Will a Spring MD POJO consume messages serially or can a pool of these objects service a queue/topic?

Of not, that is definitely one advantage of using MDB's over Spring's consumer template.

-Michael

Will a Spring MD POJO consume messages serially or can a pool of these objects service a queue/topic?Of not, that is definitely one advantage of using MDB's over Spring's consumer template.-Michael

Yes it can process messages concurrently and using an embedded JCA container can pool JMS connections, sessions and threads - along with performing all of the local or XA transaction handling, retry and exception processing. So it has all of the features of MDBs - its just that

* its simple and embeddable in any JVM or servlet engine or app server
* it works just fine on Java 1.4
* you can use Spring for dependency injection and AOP in your message listeners
* if you wanna hide the JMS API you can use Lingo a Spring remoting implementation for JMS
* you can reuse Spring's ability to dynamically deploy contexts/factories to dynamically depoy MDPs at runtime - whereas EJB only supports static registration.

James
LogicBlaze

Is the replacement of a JEE container with a JMS container a worthwhile trade-off?

BTW one minor nitpick. Its not a JMS container per se; its a JCA container (one piece of a JEE container) which just happens to be lightweight and embeddable inside any JVM be it J2SE, a servlet engine or a full blown JEE container.

Also there's no reason why other JEE servers can't support Message Driven POJOs too with dependency injection, interceptors and allow them to be dynamically deployed at runtime inside an application.

James
LogicBlaze

The tibco stuff goes some of the way towards whats possible with the partitioning facility in XD but it's no where near as flexible as whats possible with XD plus it's coupling the partitioning to a single destination which isn't typical also. Plus there are lifecycle events around a partition activating on a particular application server which are critical also.

Billy

Has anybody tried to use the POJO listening to tibco's ems server (E4JMS). How is the error recover in this approach i.e. what happens if the jms server goes down and comes back up. MDB seems to recover atleast with weblogic server we are using.

Most application servers, WebSphere for sure, will attempt to periodically reconnect to a failed JMS connection factory using by MDBs. WebSphere by default tries to reconnect every 30 seconds.

Billy

Has anybody tried to use the POJO listening to tibco's ems server (E4JMS). How is the error recover in this approach

Does TibCo EMS have a JCA Resource Adaptor? If so it should work.

i.e. what happens if the jms server goes down and comes back up. MDB seems to recover atleast with weblogic server we are using.

Handling auto-reconnection with the JMS server is normally an issue for the JMS client or JMS resource adapter rather than the JCA container per se.

e.g. if you use ActiveMQ with the reiiable:tcp://host:port transport then the JMS connections are automatically reconnected for you when using message driven POJOs - or when using regular JMS client applications as well.

James
LogicBlaze

I'd like to take this opportunity to compare Spring MDP do EJB3 MDB and also JBoss MEssage Driven POJOs

    * MDBs must be run within an EJB container. Depending on the architecture of your app, this may be an excessive requirement, especially if you aren't use any other EJBs and do not require the features of a full-blown EJB container. Message-driven POJOs, on the other hand, can run anywhere, even (as shown here) in a simple main() method. The only requirement is an ActiveMQ message queue.

This will be remedied by JBoss EJB 3.0 implementation as we will be releasing an Embeddable version later this summer. We an embeddable EJB3 container working in CVS, but it is not fully featured yet. Ping our forum if you want to try it out and help us work on the API.

    * MDBs require that you implement the lifecycle methods of javax.ejb.MessageDrivenBean. Often these lifecycle methods aren't needed and are left as empty implementations. This isn't a real problem, except that it's simply unnecessary.

Completely unneccessary in EJB 3.0. Actually, your example HelloBean class can be used *as is* in EJB 3.0 if you use an EJB 3.0 deployment descriptor.

    * Although it may not be apparent from the simple HelloBean example, message-driven POJOs can take full advantage of the dependency injection and AOP support offered by Spring (including Spring's support for declarative transactions and Acegi's support for declarative security). In short, you can do anything with the POJO that you can do with any other bean in a Spring context.

The EJB 3.0 specification has dependency injection and support for interceptors.

If you want more fully-featured AOP, JBoss EJB 3.0 is built on top of JBoss AOP (a much richer AOP framework than Spring). JBoss EJB 3.0 is also integrated with our Microcontainer/Kernel. Later this summer, we'll be even offering Spring integration with our EJB3 implementation.

JBoss Message Driven POJOs, really are POJOs. Unlike Spring MDP, there is no MessageListener interface you have to implement. You define Java methods, expose them through a Producer interface. Your invocations are turned into JMS messages underneath.

Bill

I'd like to take this opportunity to compare Spring MDP do EJB3 MDB and also JBoss MEssage Driven POJOs

    * MDBs must be run within an EJB container. Depending on the architecture of your app, this may be an excessive requirement, especially if you aren't use any other EJBs and do not require the features of a full-blown EJB container. Message-driven POJOs, on the other hand, can run anywhere, even (as shown here) in a simple main() method. The only requirement is an ActiveMQ message queue.

This will be remedied by JBoss EJB 3.0 implementation as we will be releasing an Embeddable version later this summer. We an embeddable EJB3 container working in CVS, but it is not fully featured yet. Ping our forum if you want to try it out and help us work on the API.

    * MDBs require that you implement the lifecycle methods of javax.ejb.MessageDrivenBean. Often these lifecycle methods aren't needed and are left as empty implementations. This isn't a real problem, except that it's simply unnecessary.

Completely unneccessary in EJB 3.0. Actually, your example HelloBean class can be used *as is* in EJB 3.0 if you use an EJB 3.0 deployment descriptor.

    * Although it may not be apparent from the simple HelloBean example, message-driven POJOs can take full advantage of the dependency injection and AOP support offered by Spring (including Spring's support for declarative transactions and Acegi's support for declarative security). In short, you can do anything with the POJO that you can do with any other bean in a Spring context.

The EJB 3.0 specification has dependency injection and support for interceptors. If you want more fully-featured AOP, JBoss EJB 3.0 is built on top of JBoss AOP (a much richer AOP framework than Spring). JBoss EJB 3.0 is also integrated with our Microcontainer/Kernel. Later this summer, we'll be even offering Spring integration with our EJB3 implementation.JBoss Message Driven POJOs, really are POJOs. Unlike Spring MDP, there is no MessageListener interface you have to implement. You define Java methods, expose them through a Producer interface. Your invocations are turned into JMS messages underneath.Bill

Here is a question. If I want richer AOP than Spring, why wouldn't I go with AspectJ/AspectWerkz? Neither are tied to JBoss. Also, from what I've heard(and it is still early) the dependency injection of EJB3 is not as full-featured as Spring.

So basically, if I want top-notch IOC and tons of third-party integration AND AOP go with Spring which can run in any app server. If I want better AOP, Spring integrates with AspectJ and you still get vendor independence and can run on something as small as tomcat?

Why JBoss?

Here is a question. If I want richer AOP than Spring, why wouldn't I go with AspectJ/AspectWerkz? Neither are tied to JBoss. Also, from what I've heard(and it is still early) the dependency injection of EJB3 is not as full-featured as Spring.So basically, if I want top-notch IOC and tons of third-party integration AND AOP go with Spring which can run in any app server. If I want better AOP, Spring integrates with AspectJ and you still get vendor independence and can run on something as small as tomcat?Why JBoss?

It is a common misconception that JBoss AOP requires JBoss AS. JBoss AOP can run on any app server or standalone application or Tomcat. It has been able to do this for years.

Our EJB3 solution is scheduled to have an embeddable release that can run in JUnit, standalone apps, Tomcat standalone, or other vendor app servers. Much of it is already functional within CVS and we'll be releasing soon. I've already gotten trememdous feedback that this will be a popular option and predict other EJB3 vendors will follow with their own embeddable solutions or risk falling behind the competition.

I think you will find that EJB 3.0 has some nice persistence integration that Spring does not, not to mention it is *much* easier to deploy than Spring.

If you're so concerned about vendor lock-in, I think you'd be better off writing things like MDB's in EJB 3.0 and using Spring to compliment EJB 3.0. Remember, Spring is a vendor too and they want you to be as dependent as possible on them so that their services are more attractive. Interface21 can flame me all they want, but the fact remains, they are a business. Nothing wrong with that, but you should at least be aware of it.

Bill

One more thing, like Spring, EJB3, JBoss AOP are technologies that glue together middleware services like ORM, TransactionManagement, messaging, security, servlet containers, etc... Spring/Interface21 are dependent on vendors and/or open source projects to provide these services. So, I don't think the argument is "Should I use Spring or JBoss?", but rather "Do I need to use Spring with JBoss?".

JBoss can pretty much stand on its own as a middleware stack. Spring and Interface21 cannot. This is not to say that Spring doesn't add value, they do, but this isn't a Spring vs. JBoss App server thing. Its a Spring vs. EJB3, Spring vs. JBoss AOP, Spring vs. JBoss Microcontainer. Not Spring vs. JBossMQ, Spring vs. JBoss TM, Spring vs. Tomcat., Spring vs. JCA, etc...

If you're using Hibernate + Spring, that's JBoss Inc. If you're using Tomcat, that's JBoss Inc as we fund development for both Apache Tomcat and ModJK.

Bill

One more thing, like Spring, EJB3, JBoss AOP are technologies that glue together middleware services like ORM, TransactionManagement, messaging, security, servlet containers, etc... Spring/Interface21 are dependent on vendors and/or open source projects to provide these services. So, I don't think the argument is "Should I use Spring or JBoss?", but rather "Do I need to use Spring with JBoss?". JBoss can pretty much stand on its own as a middleware stack. Spring and Interface21 cannot. This is not to say that Spring doesn't add value, they do, but this isn't a Spring vs. JBoss App server thing. Its a Spring vs. EJB3, Spring vs. JBoss AOP, Spring vs. JBoss Microcontainer. Not Spring vs. JBossMQ, Spring vs. JBoss TM, Spring vs. Tomcat., Spring vs. JCA, etc... If you're using Hibernate + Spring, that's JBoss Inc. If you're using Tomcat, that's JBoss Inc as we fund development for both Apache Tomcat and ModJK.Bill

Spring, wisely, in my opinion integrates with various products. If I use JBoss' transactions, persistence, etc, I'm stuck with JBoss. With Spring, I can use vendor A's transactions, Vendor B's persistence, Vendor C's security.

Many companies would have to fail for Spring's stack to fall, right? Or will you say that only Spring would have to fall, in which case, only JBoss would have to fall?

What arguement can be presented about a Spring tie-in that cannot be used as a JBoss tie-in? Standards? Well, as we all know, all standards don't succeed. Heck, EJB3 isn't even finalized.

Regardless, I'll bite. Why should I write to JBoss instead of Spring, when the Spring stuff is so much more portable? Why should I select JBossAOP instead Spring/AspectJ?

So I

One more thing, like Spring, EJB3, JBoss AOP are technologies that glue together middleware services like ORM, TransactionManagement, messaging, security, servlet containers, etc... Spring/Interface21 are dependent on vendors and/or open source projects to provide these services. So, I don't think the argument is "Should I use Spring or JBoss?", but rather "Do I need to use Spring with JBoss?". JBoss can pretty much stand on its own as a middleware stack. Spring and Interface21 cannot. This is not to say that Spring doesn't add value, they do, but this isn't a Spring vs. JBoss App server thing. Its a Spring vs. EJB3, Spring vs. JBoss AOP, Spring vs. JBoss Microcontainer. Not Spring vs. JBossMQ, Spring vs. JBoss TM, Spring vs. Tomcat., Spring vs. JCA, etc... If you're using Hibernate + Spring, that's JBoss Inc. If you're using Tomcat, that's JBoss Inc as we fund development for both Apache Tomcat and ModJK.Bill

Spring, wisely, in my opinion integrates with various products. If I use JBoss' transactions, persistence, etc, I'm stuck with JBoss. With Spring, I can use vendor A's transactions, Vendor B's persistence, Vendor C's security.

And you can do the same with JBoss. You can plug in Vendor A's transactions (Arjuna), message (any JCA compliant vendor), persistence (EJB3 is pluggable persistence and we have deployers for Hibernate), Security (through JAAS). Really, you can plug in *any* packaged component type by writing a JBoss Deployer. Even Spring Deployer could be (and is being) written.

Many companies would have to fail for Spring's stack to fall, right?

Same with JBoss as, unlike Spring, we're standards based as you point out.

Well, as we all know, all standards don't succeed. Heck, EJB3 isn't even finalized.

Another myth propagated by the likes of Interface21 and the Spring crowd. Even though Rod likes to give talks like "Why J2EE Projects Fail" (why? becuase you're not using Spring obviously!) and "J2EE without EJB" (so what do I use instead? Spring of course!), the fact remains that there are a huge amount of applications that have SUCCEEDED on top of EJB and J2EE.

The fact of the matter remains is that the Spring crowd prefers to push their own custom solutions based on their framework rather than working with standards bodies.

Why should I write to JBoss instead of Spring, when the Spring stuff is so much more portable?

So you're saying Spring has a persistence solution more portable than JBoss's? It's messaging solution? Transaction solution?

Or are we just talking about EJB3?

 Why should I select JBossAOP instead Spring/AspectJ? So I

Dynamic per-instance AOP, hot deployment that works without a special VM. Richer type expressions. Remotable proxying and integrated remote capabilities. When JBOSS MC is released, full dependency propagation (exists in CVS now). I'm not talking about DI, I'm talking about disallowing a service to start because the aspect that cross-cuts it hasn't been initialized yet. Currently being developed is the ability to disable/enable beans at runtime (like Windows service manager).

Bill

Even though Rod likes to give talks like "Why J2EE Projects Fail" (why? becuase you're not using Spring obviously!)

Please, Bill, if you're going to try to make any points based on my presentations, actually listen to them, or get the slides, first. Otherwise readers might assume that it's your agenda that is coming out.

There was very little (if anything) about Spring in that presentation. Much of it is not even about technology at all.

So you're saying Spring has a persistence solution more portable than JBoss's? It's messaging solution? Transaction solution?

I'm puzzled as to where this over-reaction came from, and why the focus on "Spring vs JBoss". A thread based on this false premise is going to produce more heat than light, so a flame war seems pointless. There is no need to choose between the two products.

JBoss is an application server, and JBoss Group are trying to build other products around it. Spring is an application framework that runs on all application servers, and runs equally outside an application server. The majority of Interface clients--and, presumably the majority of Spring users overall, based on market share--are running Spring on application servers other than JBoss. Or on web containers. So while Spring runs happily on JBoss, Spring is not dependent on JBoss technology.

Spring and JBoss are not in the same space, and therefore not mutually exclusive products.

One more thing, like Spring, EJB3, JBoss AOP are technologies that glue together middleware services like ORM, TransactionManagement, messaging, security, servlet containers, etc... Spring/Interface21 are dependent on vendors and/or open source projects to provide these services. So, I don't think the argument is "Should I use Spring or JBoss?", but rather "Do I need to use Spring with JBoss?". JBoss can pretty much stand on its own as a middleware stack. Spring and Interface21 cannot. This is not to say that Spring doesn't add value, they do, but this isn't a Spring vs. JBoss App server thing. Its a Spring vs. EJB3, Spring vs. JBoss AOP, Spring vs. JBoss Microcontainer. Not Spring vs. JBossMQ, Spring vs. JBoss TM, Spring vs. Tomcat., Spring vs. JCA, etc... If you're using Hibernate + Spring, that's JBoss Inc. If you're using Tomcat, that's JBoss Inc as we fund development for both Apache Tomcat and ModJK.Bill

Spring, wisely, in my opinion integrates with various products. If I use JBoss' transactions, persistence, etc, I'm stuck with JBoss. With Spring, I can use vendor A's transactions, Vendor B's persistence, Vendor C's security.

And you can do the same with JBoss. You can plug in Vendor A's transactions (Arjuna), message (any JCA compliant vendor), persistence (EJB3 is pluggable persistence and we have deployers for Hibernate), Security (through JAAS). Really, you can plug in *any* packaged component type by writing a JBoss Deployer. Even Spring Deployer could be (and is being) written.

Many companies would have to fail for Spring's stack to fall, right?

Same with JBoss as, unlike Spring, we're standards based as you point out.

Well, as we all know, all standards don't succeed. Heck, EJB3 isn't even finalized.

Another myth propagated by the likes of Interface21 and the Spring crowd. Even though Rod likes to give talks like "Why J2EE Projects Fail" (why? becuase you're not using Spring obviously!) and "J2EE without EJB" (so what do I use instead? Spring of course!), the fact remains that there are a huge amount of applications that have SUCCEEDED on top of EJB and J2EE.The fact of the matter remains is that the Spring crowd prefers to push their own custom solutions based on their framework rather than working with standards bodies.

Why should I write to JBoss instead of Spring, when the Spring stuff is so much more portable?

So you're saying Spring has a persistence solution more portable than JBoss's? It's messaging solution? Transaction solution?Or are we just talking about EJB3?

 Why should I select JBossAOP instead Spring/AspectJ? So I

Dynamic per-instance AOP, hot deployment that works without a special VM. Richer type expressions. Remotable proxying and integrated remote capabilities. When JBOSS MC is released, full dependency propagation (exists in CVS now). I'm not talking about DI, I'm talking about disallowing a service to start because the aspect that cross-cuts it hasn't been initialized yet. Currently being developed is the ability to disable/enable beans at runtime (like Windows service manager). Bill

Okay. So first you say JBoss is good because it is standalone,(which ties you to JBoss), but then JBoss is good because it allows you to use other vendors tools? Which is it? Is it a virtue to be able to switch between third-party implementations or not?

Two, JBoss AOP, to my knowlege isn't a standard. Neither is JBoss Microcontainer. Neither is JBossMQ(I've never heard of that). So, you are not just standard's based, are you. Also, without bring Rod into this(I have done EJB work so I can draw my own conclusions about how well people like EJBs,especially given how even YOU mention that EJB3 copies Spring), what doesn't working with a standard body have to do with anything?

Hibernate didn't become a jewel in JBoss' crown because of any cooperation with a standards body, right? And it took the standards body years to come out with something to displace Struts(which still hasn't happened). So, considering the amount of seemingly non-standard code you've mentioned, how exactly can you tout being standards based when you list so much non-standard code?

What I'm saying about Spring persistence, is that Spring integrates with pretty much every major form of persistence available to Java. Does JBoss or EJB3? Can I use EJB3 to integrate with JDO or JDBC? I'm asking.

I've got to check on your AOP stuff. I wasn't aware that running AspectJ required any special VM support.

David

Okay. So first you say JBoss is good because it is standalone,(which ties you to JBoss), but then JBoss is good because it allows you to use other vendors tools? Which is it? Is it a virtue to be able to switch between third-party implementations or not?

Which is it? The answer is both. We're aiming to do both. We've had a pluggable, integrated app server from day one, now we're aiming to offer our middleware stack in other environments.

Hibernate didn't become a jewel in JBoss' crown because of any cooperation with a standards body, right?

True, but we brought Hibernate to a standards body (EJB3).

Or should I trust that I am as capable of seeing through exaggeration as I am through unsubtle jabs at a perceived competitor?

Yes, I was exaggerating to prove a point.

Bill

Hibernate didn't become a jewel in JBoss' crown because of any cooperation with a standards body, right?

True, but we brought Hibernate to a standards body (EJB3).

Hibernate is quickly becoming the underdog in JCP politics, and is no longer "the" EJB3 source.

David

Okay. So first you say JBoss is good because it is standalone,(which ties you to JBoss), but then JBoss is good because it allows you to use other vendors tools? Which is it? Is it a virtue to be able to switch between third-party implementations or not?

Which is it? The answer is both. We're aiming to do both. We've had a pluggable, integrated app server from day one, now we're aiming to offer our middleware stack in other environments.

Hibernate didn't become a jewel in JBoss' crown because of any cooperation with a standards body, right?

True, but we brought Hibernate to a standards body (EJB3).

Or should I trust that I am as capable of seeing through exaggeration as I am through unsubtle jabs at a perceived competitor?

Yes, I was exaggerating to prove a point.Bill

I guess Spring has a different opinion. Don't duplicate unless it adds value. I'm still not sure why I should use JBoss over Spring. You really haven't explained why tying myself to JBoss' versions of certain technology is more desirable than Spring nor have you really addressed the issue that a "standard" is not necessarily a slamdunk.

In addition, since Spring abstracts the very middleware stack you value and thus allows me to use it fairly seamlessly coupled with the fact that if I need such things(like JTA for example), I'll use an app server, I can still use Spring, but not necessarily JBoss. What would be better? Moving my Spring enabled JTA app from say Weblogic to SunOne or tying myself to JBoss and not being able to move as easily?

Now, you may have brought Hibernate to a standards body, but it didn't gain popularity from that move nor is Hibernate a standard. By your apparent feelings about non-standard technology both of us should drop Hibernate. Yet, JBoss purchased it because...I guess I'm not sure. It was not a standard. Where's the value?

As for your exaggeration, I'm didn't get your point.

Here is a question. If I want richer AOP than Spring, why wouldn't I go with AspectJ/AspectWerkz? Neither are tied to JBoss. Also, from what I've heard(and it is still early) the dependency injection of EJB3 is not as full-featured as Spring.So basically, if I want top-notch IOC and tons of third-party integration AND AOP go with Spring which can run in any app server. If I want better AOP, Spring integrates with AspectJ and you still get vendor independence and can run on something as small as tomcat?Why JBoss?

It is a common misconception that JBoss AOP requires JBoss AS. JBoss AOP can run on any app server or standalone application or Tomcat. It has been able to do this for years.Our EJB3 solution is scheduled to have an embeddable release that can run in JUnit, standalone apps, Tomcat standalone, or other vendor app servers. Much of it is already functional within CVS and we'll be releasing soon. I've already gotten trememdous feedback that this will be a popular option and predict other EJB3 vendors will follow with their own embeddable solutions or risk falling behind the competition.I think you will find that EJB 3.0 has some nice persistence integration that Spring does not, not to mention it is *much* easier to deploy than Spring.If you're so concerned about vendor lock-in, I think you'd be better off writing things like MDB's in EJB 3.0 and using Spring to compliment EJB 3.0. Remember, Spring is a vendor too and they want you to be as dependent as possible on them so that their services are more attractive. Interface21 can flame me all they want, but the fact remains, they are a business. Nothing wrong with that, but you should at least be aware of it. Bill

I'm aware that both JBoss and Interface21 offer professional services for their products. Of course, the difference is that I can run even Spring-integrated EJB code on any app server including JBoss. JBoss would be just JBoss. However, I am interested in how your EJB3 is "much easier" to deploy than Spring. I mean, Spring doesn't do persistence. It integrates wraps JDBC, integrates with Hiberate 2.x,3, Toplink, JDO, and IBatis. Does EJB3 do the same? What does EJB3 integrate with?

Also, I'm still asking WHY I would choose JBoss AOP over AspectJ. Assuming one can run JBoss AOP without the container, why tie myself to the JBoss version?

Now, my concern with vendor lock-in is in terms of the app server, not a specific library. After all, If, for example, my transactions can be configured via Spring and run on any or no app server at all, why be concerned with the app server? A standard is no guarantee. Look at entity beans. A disaster. Or in my case, we have to support JRun 4.0 of all things. I would say that Spring-integrated persistence would have been a better, easier, more portable choice than say JRun 4 EJB 2.0 entity beans(which we didn't use, BTW).

Bill

JBoss Message Driven POJOs, really are POJOs. Unlike Spring MDP, there is no MessageListener interface you have to implement. You define Java methods, expose them through a Producer interface. Your invocations are turned into JMS messages underneath.

Ignoring the blatant product plug, this shows a rather peculiar idea of what a POJO is. Since when were interfaces bad? javax.jms.MessageListener is a JMS interface, and nothing to do with Spring--it's perfectly reasonable that message listeners should implement it. And, of course, implementing it does not tie user code to Spring. I point this out (obvious as it is) to clear up the FUD elsewhere in this thread about the Spring team wanting code to depend on Spring APIs. In fact, we make a big point about the fact that Spring is designed to minimize the amount user code depends on its APIs.

Obviously it's trivial to create an abstraction that hides the MessageListener interface and invokes a method--we've considered it and will probably do so at some point--but it really doesn't add a huge amount of value in most cases. A relatively simple routing class could do this, and then work behind any MessageListener, and be portable between messaging solutions.

Rgds
Rod

Rod

JBoss Message Driven POJOs, really are POJOs. Unlike Spring MDP, there is no MessageListener interface you have to implement. You define Java methods, expose them through a Producer interface. Your invocations are turned into JMS messages underneath.

Ignoring the blatant product plug, this shows a rather peculiar idea of what a POJO is. Since when were interfaces bad? javax.jms.MessageListener is a JMS interface

By this definition, EJB 2.1 MDB is a POJO. It implements a tiny interface and has a little bit of XML to glue it the destination. Spring MDP is not very POJO because you're dealing with untype JMS specific message format and implementing a JMS specific interface, where JBoss MDPs are pure business interfaces.

, and nothing to do with Spring--it's perfectly reasonable that message listeners should implement it. And, of course, implementing it does not tie user code to Spring.

Yes, I think I already said that the same HelloBean class could be used in EJB3 land.

I point this out (obvious as it is) to clear up the FUD elsewhere in this thread about the Spring team wanting code to depend on Spring APIs. In fact, we make a big point about the fact that Spring is designed to minimize the amount user code depends on its APIs.

Then why the propagation and proliferation of all your template and helper classes? Also, just because something is a POJO doesn't mean its not dependendant on the framework. For example, Why on a Spring 1.2RC release thread months ago did you not recommend people move to Hibernate 3 because Spring 1.2 wasn't ready yet? Sounds like lock-in to me...

Obviously it's trivial to create an abstraction that hides the MessageListener interface and invokes a method

Same thing could be said about most of Spring technology(that it's trivial), but together it is a compelling story isn't it? We feel the same about JBoss EJB3, AOP, and MC, which is why I'm here in the first place, to show an alternative to the Spring marketing machine.

Bill

together it is a compelling story isn't it? We feel the same about JBoss EJB3, AOP, and MC, which is why I'm here in the first place, to show an alternative to the Spring marketing machine.Bill

What marketing machine? I'm stunned by this reaction? There seems to be more post coming from the JBoss side than from the Spring side. Just because Spring's technology allows you to run on JBoss' competitors is no reason to huff. :-)

together it is a compelling story isn't it? We feel the same about JBoss EJB3, AOP, and MC, which is why I'm here in the first place, to show an alternative to the Spring marketing machine.Bill

What marketing machine? I'm stunned by this reaction? There seems to be more post coming from the JBoss side than from the Spring side. Just because Spring's technology allows you to run on JBoss' competitors is no reason to huff. :-)

Good! I'm glad somebody picked up on my "Spring marketing machine" comment. It's annoying isn't it?

together it is a compelling story isn't it? We feel the same about JBoss EJB3, AOP, and MC, which is why I'm here in the first place, to show an alternative to the Spring marketing machine.Bill

What marketing machine? I'm stunned by this reaction? There seems to be more post coming from the JBoss side than from the Spring side. Just because Spring's technology allows you to run on JBoss' competitors is no reason to huff. :-)

Good! I'm glad somebody picked up on my "Spring marketing machine" comment. It's annoying isn't it?

????? I don't think there is any Spring marketing machine. TSS' main function is to talk about technology, so what the big deal. I use Spring. I also use Hibernate and Struts. Should I toss them out because some people write articles and talk about the things and oh, BTW, they are not standard?

Or should I trust that I am as capable of seeing through exaggeration as I am through unsubtle jabs at a perceived competitor? You don't see BEA knocking Spring? Or Oracle. They just stepped up and supported a popular piece of software that has saved many developers many thousands of man-hours.

jeebus, this guy bill burke is such an _sshole it's unbelieveable. i mean, you just see the topic posted on here and you know it's not long before he'll be around telling everyone what a piece of sh_t product xyz is and why jboss is so much better. it's amazing anyone uses their server with public relations like this.

together it is a compelling story isn't it? We feel the same about JBoss EJB3, AOP, and MC, which is why I'm here in the first place, to show an alternative to the Spring marketing machine.Bill

What marketing machine? I'm stunned by this reaction? There seems to be more post coming from the JBoss side than from the Spring side. Just because Spring's technology allows you to run on JBoss' competitors is no reason to huff. :-)

Good! I'm glad somebody picked up on my "Spring marketing machine" comment. It's annoying isn't it?

No, actually you are the annoying one. Congratulations, now I'm even less interested in trying JBOSS or EJB3 before you jumped into this thread. I don't know, maybe its just me but I get a little wary when new and untested technologies like EJB3 get hyped so much before they are even released. I remember when EJB 1.0 was going to be the be-all end-all solution too.

Seriously, tone down the evangalising man. At this point you and the JBOSS crowd are just annoying people. JBOSS could cure cancer and I wouldn't want to hear about it now.

together it is a compelling story isn't it? We feel the same about JBoss EJB3, AOP, and MC, which is why I'm here in the first place, to show an alternative to the Spring marketing machine.Bill

What marketing machine? I'm stunned by this reaction? There seems to be more post coming from the JBoss side than from the Spring side. Just because Spring's technology allows you to run on JBoss' competitors is no reason to huff. :-)

Good! I'm glad somebody picked up on my "Spring marketing machine" comment. It's annoying isn't it?

No, actually you are the annoying one.

I was trying to be subtle and it failed miserably. It is annoying to be called a "marketing machine" was my point. Especially when you deliver on your marketing vision. Is that too subtle again?

Seriously, tone down the evangalising man.

This *is* a discussion forum, not a pat-you-on-the-back forum. If Spring is such a Holy Icon to you where nobody can criticize it or offer alternatives, then you really have serious issues man.

I really see no difference, other than being a JBoss employee, in my postings compared to other more frequent lurkers on different threads.

Bill

Then why the propagation and proliferation of all your template and helper classes?

Users choose to use Spring APIs if they add value. For example, consider JDBC. You can choose to use raw JDBC, or another JDBC abstraction library, but the class library that Spring provides over JDBC adds a lot of value, and many users like it. There is simply no practicable solution in that space that has no API, and it's worth noting that we don't reinvent core JDBC concepts such as PreparedStatements and ResultSets, just make them easier to use.

Some parts of Spring are class libraries, some are not. Spring APIs are not normally necessary for the important areas of configuration management and transaction management, for example. You can configure much legacy code that was written without knowledge of Spring, and you can make many existing objects transactional. The example in this thread (since we may at least make some attempt to stay on topic) shows a dependence on the JMS API, rather than the Spring API.

You really do seem very worked up about Spring today...

Rod wrote: You really do seem very worked up about Spring today...

Yeah, i don't know what happened...

Rod wrote: You really do seem very worked up about Spring today...

Yeah, i don't know what happened...

Something in the koolaid? ;-)

Peace.

I am writing applications using both Spring and JBoss. They are both great, and I'm grateful that such excellent software is available at no charge.

I have no connection to either organisation, and no axe to grind.

However I can safely say that what I read from those involved in Spring increases my respect for them; what I read from those involved in JBoss does the opposite.

Bill

JBoss Message Driven POJOs, really are POJOs. Unlike Spring MDP, there is no MessageListener interface you have to implement. You define Java methods, expose them through a Producer interface. Your invocations are turned into JMS messages underneath.

Ignoring the blatant product plug, this shows a rather peculiar idea of what a POJO is. Since when were interfaces bad? javax.jms.MessageListener is a JMS interface, and nothing to do with Spring--it's perfectly reasonable that message listeners should implement it. And, of course, implementing it does not tie user code to Spring.

Amen. All this Spring bashing by JBoss guys has been unbelievably obnoxious for days, now, but it's clear that with this kind of arguments it is also being ridiculous. I imagine they are coming out with a pojolet and start claiming that servlets are heavyweight components because they have to implement service(ServletRequest, ServletResponse) in order to work ("all other application servers lock you into their proprietary extensions to the simple pojo without interfaces!")...

All this Spring bashing by JBoss guys has been unbelievably obnoxious for days, now...

i personally haven't read any bashing by the JBoss, Inc. folks around these parts, specifically twords the spring product. Bill even stated that the two products (spring and jboss) serve a different space.

imo, jboss continues to innovate their products and delivers that innovation to the consumers at a rate that far surpasses the competition. they had a small bypass to become j2ee certified, and continued to stay on top of the customer demands (simplified integrating of software into the container) the entire time.

All this Spring bashing by JBoss guys has been unbelievably obnoxious for days, now...

i personally haven't read any bashing by the JBoss, Inc. folks around these parts, specifically twords the spring product.

Try scrolling up ;-)

Bill has been totally paranoid about Spring (and Interface21) for months now, and hasn't missed an opportunity to be downright nasty about it. Combine that with his "all your base are belong to us" rhetoric, such as:

Bill: If you're using Hibernate + Spring, that's JBoss Inc.

It's just plain childish. It's deliberately false. It's purposefully insulting. It's also a shame, because it makes Jboss look completely unprofessional and it detracts from any good technical work occurring in Jboss.

imo, jboss continues to innovate their products

Exactly. So why the pointless attacks on Spring? Especially since Rod (& co.) has put lots of work into supporting the Jboss server, Hibernate, etc.

Peace,

Cameron Purdy
Tangosol Coherence: Clustered Shared Memory for Java

Take a look at this blog entry (and the comments by Christian Bauer and Gavin King):

http://www.logemann.org/blojsom/blog/default/2005/07/07/oops_JBoss_did_it_again_or_how_to_say_forget_Spring.html?page=comments

Read this one that talks about this thread (I totally agree with what is said)

http://www.logemann.org/blojsom/blog/default/2005/07/21/JBoss_Inc_continues_attacking_Spring_I21.html

I don’t even try to search some material written by Marc Fleury because I really don’t have patience anymore... I used to read this kind of stuff to amuse myself, but now I'm really tired of this playground level behaviour.

Pedro Costa

Since we're all doing product plugs here... :-)

I've got a framework built on XWork and JMS which allows you to take JMS messages and map them to XWork actions so you can reuse your XWork actions across your web-app and your asynchronous backend code. The message dispatcher can be deployed as either an MDB or as just a plain MessageListener, so you can make the MDB vs. MDP decision a runtime deployment decision, rather than an architectural decision.

Ignoring the blatant product plug, this shows a rather peculiar idea of what a POJO is. Since when were interfaces bad? javax.jms.MessageListener is a JMS interface, and nothing to do with Spring--it's perfectly reasonable that message listeners should implement it. And, of course, implementing it does not tie user code to Spring. I point this out (obvious as it is) to clear up the FUD elsewhere in this thread about the Spring team wanting code to depend on Spring APIs. In fact, we make a big point about the fact that Spring is designed to minimize the amount user code depends on its APIs.Obviously it's trivial to create an abstraction that hides the MessageListener interface and invokes a method--we've considered it and will probably do so at some point--but it really doesn't add a huge amount of value in most cases. A relatively simple routing class could do this, and then work behind any MessageListener, and be portable between messaging solutions.RgdsRod

The EJB 3.0 specification has dependency injection and support for interceptors. If you want more fully-featured AOP, JBoss EJB 3.0 is built on top of JBoss AOP (a much richer AOP framework than Spring).

This is surely like Microsoft saying "if you want fully-featured GUI, we do it better than Java can". You're comparing your own AOP on JBoss to an open framework that works on any J2EE platform including JBoss, not to mantion several non J2EE platforms. I'll stick to the open framework, that way I can choose if I want EJB3 or something more efficient. I might even choose JBoss but at least I have a choice.

Unlike Spring MDP, there is no MessageListener interface you have to implement.

Oh great, you've saved an "implements MessageListener" and "onMessage()" method. We're not talking complex here.

You define Java methods, expose them through a Producer interface. Your invocations are turned into JMS messages underneath.

Sounds OK, so can I run it on my WebLogic and WebFear servers?

-John-

JBoss Message Driven POJOs, really are POJOs. Unlike Spring MDP, there is no MessageListener interface you have to implement. You define Java methods, expose them through a Producer interface. Your invocations are turned into JMS messages underneath.Bill

Often in JMS/MOM applications you actually want to use the JMS API to see the various headers of the message (has it been redelivered, if so how many times, whats the reply to destination, its time to live, priority and so forth). So being dependent on a simple JMS interface MessageListener is not a big deal.

Though if you want to hide the JMS API and MessageListener interface, you can use Lingo which is a Spring remoting library for JMS which works great with Spring MDPs to hide the JMS API. Whats more, Lingo works great on the client side too - providing a clean, load balanced and clustered POJO based remoting solution using the performance and reliability of JMS. In addition Lingo can handle asynchronous one way method calls or asynchronous request/response queries as well as the regular synchronous request/response of remoting/RMI.

Its worth highlighting again that Spring MDBs work great today, in any JVM 1.4 or later, in any servlet engine or in any ap server 1.4 onwards. EJB 3.0 only really works in Java 5 onwards with Java EE 5.0. I don't know about you but few of our customers can move to Java 5 yet.

Incidentally Bill, its kinda funny you see being dependent on 1 well established JMS interface as being somehow bad; yet are happy to promote a solution which adds exactly the same kind of runtime dependency - but this time on a number of annotations which are defined in EJB 3.0, which is still early draft and only works on Java 5. Thats way more restrictive and risky than using a MessageListener :).

Remember if you're using JMS you are already dependent, in jar form at least, on the JMS API - so EJB 3.0 actually adds more dependencies - Java 5, an EJB 3.0 application server and the EJB 3.0 annotations plus the added risk of the specification still being an early draft.

James
LogicBlaze

I think i have somewhat unique prospective here having run the product that was similar in certain sense to Spring. As much as I openly and frequently disagree with some technical decisions behind Spring, the idea behind Spring is sound and solid (and market penetration of it says it all).

But it is hard to imagine where people do take these ideas of comparing Jboss AS and Spring which obviously are completely different species with different goal, applications, etc. As Spring growths, however, I suspect there will be naturally more and more overlapping.

Out current client, for example, uses Jboss/Spring/iBatis mix. Jboss is used for Web and clustering, Spring is used for static configuration (potentially something else). It is a vanilla setup that can be found in thousands of projects.

Nikita.
GridGain Systems.

Has anyone compared the two ? Any links would be appreciated.

Has anyone compared the two ? Any links would be appreciated.

We're completely biased of course but here is one comparison.

But don't take our word for it - I suggest you try them both. Certainly try to benchmark them in your own environment to see how they perform.

James
LogicBlaze

I just discovered this framework today http://lingo.codehaus.org/ It's by the same guys of ActiveMQ. Looks really cool.

I just read thru all the comments and discussion.
I find that incredible.
I already was bluffed by the logemann blog incident and by the way the hibernate guys were almost barking answers (and yes beginners ask beginners questions) in their forum.

I guess it can't be only be professionnal...Rod ? Which JBoss staff member's wife did you stole ? wow !!! wow !!! it was only a joke...don't let Bill come after me.

I really enjoy Jboss AS, hibernate...but guys you really try hard to loose support of the community.