Granny's Programming Pearls
"inside of every large program is a small program struggling to get out"
JavaRanch.com/granny.jsp
Win a copy of Re-engineering Legacy Software this week in the Refactoring forum
or Docker in Action in the Agile forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

JBoss inner workings and JMX to microcontainer shift

 
jim cato
Greenhorn
Posts: 21
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Fransesco,

How do you think the move in JBoss 5 from JMX managed beans to microcontainer POJOs, will encourage application development? Is the thinking that application developers will build applications as services to be deployed under JBoss5? Or are microcontainer POJOs just a better architecture for the JBoss core? Either way, why do you think it was necessary to develop a custom IOC framework rather than just use an existing one?

About the book specifically, how deep into the JBoss 5 workings do you delve in the book?

Cheers,
Jim
 
jim cato
Greenhorn
Posts: 21
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Apologies Francesco, I misspelt your name.
 
Francesco Marchioni
author
Ranch Hand
Posts: 194
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
jim cato wrote:Hi Fransesco,

How do you think the move in JBoss 5 from JMX managed beans to microcontainer POJOs, will encourage application development? Is the thinking that application developers will build applications as services to be deployed under JBoss5? Or are microcontainer POJOs just a better architecture for the JBoss core? Either way, why do you think it was necessary to develop a custom IOC framework rather than just use an existing one?

About the book specifically, how deep into the JBoss 5 workings do you delve in the book?

Cheers,
Jim

Hi Jim,
thanks for your inquiry. Well the earlier JMX container was an excellent modular solution which was one of the reason of the application server's success. Even if it was an excellent kernel, it was still tying the user to the application server interfaces. Also another problem was that JMX might not be available in all environments.
With a POJO kernel you have simple Java classes. This removes any lock-in to the application server thus allowing even testing services outside of the application server.
Related to your last question: the book covers concrete programming examples with the application server: in many points it is intentionally showed a solution/advice introduced with the 5.X release so that the reader takes advantage to learn new stuff.
hope it helps
kind regards
Francesco
 
jim cato
Greenhorn
Posts: 21
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Francesco,
Thanks for the reply.

It seems logical that an IOC framework would be more flexible than the JMX based kernel for the future development of the server itself.

But how does this benefit developers; how can application developers make use of the JBoss IOC model to develop better applications?
And why would they do this instead of just writing standard applications with other IOC frameworks, i.e. what benefit does developing a JBoss service bring?

I am thinking your book will answer this question?


Thanks,
Jim
 
Ales Justin
Greenhorn
Posts: 4
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
jim cato wrote:
But how does this benefit developers; how can application developers make use of the JBoss IOC model to develop better applications?
And why would they do this instead of just writing standard applications with other IOC frameworks, i.e. what benefit does developing a JBoss service bring?

This is one of the main reasons we decided to do our own IoC:
* http://soa.dzone.com/articles/a-look-inside-jboss-microconta

Atm we're working on (transparently) adding OSGi services to the mix as well:
* http://jaxlondon.com/conferences/trackssessions/?tid=1453#session-13375
* http://anonsvn.jboss.org/repos/jbossas/projects/jboss-osgi/projects/runtime/framework/trunk/src/test/java/org/jboss/test/osgi/service/ServiceMixUnitTestCase.java
 
jim cato
Greenhorn
Posts: 21
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Ales,
Thanks for the links, it is very interesting. I am still a little confused; I think because I don't understand enough about the new features to see how they can be usefully applied.

But it seems as though the microcontainer brings JBoss closer to a Spring-like IoC container, whilst still maintaining the JEE application server umbrella. Therefore, I would write an application or a suite of applications that, whilst independent, can be connected together more easily than in a standard JEE AS, using the micro container features. Is that right, what do you think?

In this case, would I not be writing applications that are locked in to JBoss?

Thanks,
Jim
 
Ales Justin
Greenhorn
Posts: 4
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
jim cato wrote:
In this case, would I not be writing applications that are locked in to JBoss?

No.
You still just code against POJOs -- the default component model in MC.
Others are MBeans or OSGi services (which are again just POJOs).
So, as you can see, no JBoss lock-in what-so-ever.

And with the component model abstraction, you can easily support any future model.
e.g. Weld, Guice, Spring, ...
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic