I am pleased to announce JBoss EJB 3.0 Beta 1. You can find out more information from our main EJB 3.0 page. This release models as closely as possible to the upcoming Public Draft of the EJB 3.0 specification. The spec was a fast moving target the past few weeks, so we still need to cross the T's and dot the i's as far as spec compliance goes. We plan on doing another release sometime in July to complete some of the minor stuff we are missing. Special thanks goes especially to Emmanuel Bernard, Bill DeCoste, and of course Gavin "guys! guys!" King.
As part of the new Public Draft, standalone persistence is now defined. The Hibernate team has released a standalone distribution.
In the next couple of days a release of JBoss AS 4.0.3 should be out. One of the distros is a full graphical installer that allows you to pick and choose which JBoss components. EJB 3.0 comes distributed with this bundler or you can download it separately if you want to install it on JBoss 4.0.2.
I am pleased to announce the availability of JBoss AOP 1.3.0. We put in a bunch of work to optimize load-time weaving and also pointcut matching in general. You should see huge improvements of boot time when running with load-time weaving and also noticable improvements in overall startup time of JBoss AOP. Special thanks goes out to Miro Technologies for subsidizing this work. You can find the release notes on jira.jboss.com.
What's coming in AOP 2.0?
This summer you should start seeing snippets of JBoss AOP 2.0 arriving. We're planning on multiple alpha releases now and then to introduce people to the technology we're developing for 2.0.
We're working on tight integration of JBoss AOP with the new JBoss 5 Microcontainer. This integration will allow you to configure aspects via our dependency injection microcontainer. Also, weaved aspects will publish and propagate their dependencies up into the microcontainer. For example, let's say you have a service that is using the transaction annotations of our aspect library. JBoss AOP will propagate to the container that this particular service uses the transaction aspect and that that transaction aspect depends on the Transaction Manager. Thus, if the service starts before the Transaction Manager, it will wait to finish initialization until the TM is ready.
Enhanced per-instance dynamic AOP
We are enhancing our per-instance dynamic AOP API (org.jboss.aop.InstanceAdvised) to allow a more parallel feature set to regular class scoped AOP. As part of this, we're writing a proxy architecture for those who do not want to do bytecode weaving, or for when byte-code weaving is not possible. These new redesigns and features are being driven by the JBoss 5 Microcontainer project's requirement to allow overriding of annotations on a per bean basis. The idea is to be able to effect the attached aspects to a particular deployed bean through configuration.
Before/After/After Throwing/After returning
I've long stated that before, after, etc. semantics with advices were not needed as around could handle all of those use cases. I still contend that around is the best model to implement advices. The thing is, around requires an object allocation in JBoss AOP for an Invocation object. So, for performance reasons only, we'll be adding these additional advice features in the next release.
Finally, we're doing a bunch of research with the hot-swapping feature that comes with the JDK 5.0 java.lang.instrument package. There are already some features using it within AOP 1.3 from the great work of Flavia Rainone, one of Francisco Reverbel's students.
I'm pretty excited about the next release of the EJB3 specification. It looks like most of the things promised in the EDR2 draft back in February are coming to fruition. Native SQL support, app-server managed persistence contexts, j2ee packaging, outside of appserver support, and pluggable third-party persistence are amoung some of the features that are getting nailed down.
What particularly excites me is that persistence is will now pluggable into J2EE 5. What I mean by this is that third-party vendors that focus soley on persistence will have a standard mechanism to deploy their products into J2EE 5 compliant application servers. JMS has had this for years and I hope what happened to JMS happens to persistence: that a healthy subcomponent market materializes. This can only serve to strengthen J2EE as a whole and bring more choice to users. As usual, I'll tout a little JBoss arrogance and say that Hibernate will still continue dominate Java ORM, but strong competition keeps everybody honest and on their toes. Anyways...
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.