In JBoss 5, Adrian Brock, our Chief Scientist, is rearchitecting our microkernel. Why do this? There's a bunch of features we want to be able to support. Much of the new microcontainer is complete and we will gradually introduce these features into JBoss 5 via tech preview and alpha releases.
Additionality there's some other cool features not mentioned in the wiki page. For instance, we want to be able to load components and/or subsystems on demand, or manually at runtime (like Microsoft's Services GUI). We also want to have the ability to have sub-components. For instance, when you deploy an EJB, you might also want to configure classloading, log4j, aspects, etc... for that particular EJB deployment.
There's also the ability to configure aspects and have aspects publish their dependencies up through the classes that they crosscut. For example, if you have a security aspect that crosscuts a particular service, that service will not startup until the aspect has finished initializing. If you have another aspect that crosscuts a particular class, that class will throw an exception on static initialization if any of its cross-cutting aspects. We also want the ability to override or apply aspects on a per service/bean basis as well. Overall, AOP gives us a way to assign functionality to JDK 5 annotations and the glue to apply it to a pojo, component, or service and the microcontainer gives us a way to configure AOP. They compliment eachother nicely.
As a side effect of rearchitecting our kernel, we will be able to support embeddable J2EE. We already have a prototype of embeddable EJB3 within CVS and will be extending over this year and next to cover the rest of JEMS stack so that JEMS could be embedded in any environment. By embeddability I mean, within JBoss, Tomcat standalone, a swing app, a Junit test, you get the picture.
We will continue to support JBoss 4 and earlier JMX service beans. What you won't see is that the new JBoss microcontainer will be under the covers instead of the older JMX-based kernel. Speaking of integration support, because of the flexibility of our Abstract Deployer architecture, we may also, as time permits, support other XML deployment formats for our POJO microcontainer. This could allow developers in the Spring community for instance, to hook into the JBoss runtime if they are running in a JBoss environment.
Finally, on a related note, later this month with the release of JBoss 4.0.3 we'll be introducing a graphical installer that allows you to pick and choose the components you want to run with the JBoss application server. This will drastically reduce both the download size of JBoss as well as the size of JBoss deployments. JBoss always allowed you to "use what you need", but now, you'll have a much easier path to achieve custom JBoss installations.
This blog is a bit early as much of this stuff is still in development, but expect to see announcements later this month on a lot of this stuff and over the summer and fall. BTW, there's also a webex on this stuff that was done end of 2004.
Happy Hunting,
Bill
