This forum is now a read-only archive. All commenting, posting, registration services have been turned off. Those needing community support and/or wanting to ask questions should refer to the Tag/Forum map, and to http://spring.io/questions for a curated list of stackoverflow tags that Pivotal engineers, and the community, monitor.

Comparision JMX Spring

I read many articles, Book (J2EE without EJB) and presentations on spring. I found Spring framework very interesting and I am still studying it.

I found Spring framework very useful at business layer and its Dependency Injection concepts.

Now I need to develop a web base application which has following characteristics:

We will use POJO at business layer.
Multiple client/devices need to support. i.e. the application should be accessible from WML/XHTML/ and normal browser.
We are planning to use JMX for configurable object at runtime, so we can configure them from JMX Console.
We need to use JMS for asynchronous messaging
We are using Jboss as application server and want use Jboss specific feature.
My application will have very light weight UI (thin client).

Now I have many doubts regarding using Spring framework in my application. Like I feel that we can do the same things using JMX and decouple objects and can make them configurable at runtime. So Iím a little confused with comparison Spring beans and JMX Mbeans. If I use my mbeans with Spring framework, it seems There will be overhead of configuration with Spring framework.

So can you help me to compare JMX mbeans with spring beans OR redirect to a good article where JMX and Spring framework comparisons is discussed.

I read the following tech talk of Craig McClanahan regarding JSF, where the 2nd questions raise the same thing and I think you can better answer this question. Please help me to clear out the things

When would someone use Managed Beans?

Managed Beans is one of the extension points that is the framework capability of JSF that when you make an expression that references a bean, for instance, an event handler in your Java code that responds to the submit button, if you're familiar with Struts, you know that Struts will create an action form for you on demand if it needs to and then start using it. Managed Beans generalizes that capability to take any variable reference from any place in a JSF-based application, create the bean for you and request session scope or application scope and it goes a step beyond what Struts does because it can initialize the properties as well as instantiate the bean for you. You can set the property values to either literal strings or integers or whatever your appropriate data type is or you can use an expression at that point. In effect Managed Beans give you a very simple dependency injection inversion of control framework for instantiating back-end objects.

But why Managed Beans? Why not use an existing IoC framework?

Existing IoC frameworks like Spring and HiveMind exist and you're certainly free to use them in your back-end business logic for its own purposes, but out of the box, we need the capability in JSF to instantiate what JSF calls the back-end bean. What has been interesting is, you can also tie existing IoC frameworks together. The Spring folks have done this for instance, so that you can use JSF Managed Beans, syntax and APIs but you're really talking to a Spring Bean factory behind the scenes transparently to create the object for you so you can even use both together if you like.

Now I have many doubts regarding using Spring framework in my application. Like I feel that we can do the same things using JMX and decouple objects and can make them configurable at runtime... If I use my mbeans with Spring framework, it seems There will be overhead of configuration with Spring framework.

As far as I know, you need to configure your JBoss MBeans using a jboss-service.xml. So I don't think you are adding any additional work, you are simply trading one configuration task for another.

So can you help me to compare JMX mbeans with spring beans OR redirect to a good article where JMX and Spring framework comparisons is discussed.

There should be no difference between the MBeans deployed using JBoss and Spring. The question is, do you find it convenient to develop your MBeans as POJOs?

As you've no doubt noticed by now, attribute and operation invocations are a pain in the ass on regular MBeans. On the other hand, such invocations on POJOs are incredibly simple. If you are going to want to do any programmatic invocations on your MBeans (or may in the future), you should look at Spring JMX configuration.

I worked on one large JBoss application for a couple of years, and as the application requirements and architecture evolved over time, I found that sometimes we decided to change non-JMX components into JMX components and vice-versa. This, too, was a pain in the ass. I would have killed to accomplish this with a simple configuration file change rather than making extensive error-prone source changes. Once again, an advantage of Spring JMX configuration.

Comment

Yes, I need to use MBeans in code, so does Spring proivdes easy way to access them in code?

Does we need any additional configuration for spring to access MBeans which are configured using jobss-service.xml

Unless you are willing to write a pretty fancy bean factory, Spring is not going to be able to access beans that are instantiated and configured through jboss-service.xml.

So it's pretty much an either-or situation. Either you deploy through jboss-service.xml, or you deploy through Spring. If you're going to be referencing your MBeans through code, I would strongly recommend Spring.