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.
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...
Happy Hunting
Bill
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
Since we started our EJB 3.0 implementation, I've written a lot of unit tests and tutorials for it. Other than actually actually enjoying writing an EJB for a change, I thought alot about when and where XML should be used over annotations and in what situations annotations should probably be used over XML. I came up with these rules:
So, let's do a little exercise and walk through a few of the EJB 3.0 annotations. Let's start off with Session bean annotations.
What about table/column mappings? If you're not auto-generating tables, then Rule 3 probably doesn't apply. Table and column names should be portable across databases. Rule 3 is triggered if you're using annotation attributes like @Column.columnDefinition or annotations like @Lob (since some databases do not support blobs and/or clobs) though.
Rule 3 is also triggered when you're doing primary key generation. It would probably be best to use a generator and define the generator in XML so that it could be changed on a per-deployment basis. Some databases don't support Sequences or Identity generation for PKs.
@Entity public class Customer {
@Id(generate="PLUGGABLE_GENERATOR") long pk;
}
Does Rule 4 apply to table mappings? It could. The same class could be needed in multiple O/R mappings for different legacy systems or databases.
@OneToMany(mappedBy="item")
Collection<Bid> getBids() {...}
is much less verbose than
/**
* This is a OneToMany relationship to the Bids class. It is also
* bidirectional with the owning side of the relationship being maintained
* by the "item" property on the Bid class
*/
Collection<Bid> getBids() {...}
Check out Hibernate's Annotation page for more information on downloading and documentation.
Check out JBoss's EJB 3.0 site for details on documentation and downloading.
At AOSD this week, I had the pleasure of sitting down with the manager of the JRockit team so that he could show me a demo of JRockit. It was so impressive, I had to blog about it.
First of all, there is a nice GUI management that has all the sexy stuff like graphs and gauges. There are about 50 JMX stats that you can monitor, set thresholds on, and setup alerts (and send an email when that alert happens). Not much different than jconsole, so not THAT interesting...
Ya know OptimizeIt? JProbe? Well....Memory profiling, heap analysis, CPU analysis, lock analysis, all that stuff is embedded in the VM and tightly integrated with the JRockit VM. It has a much friendlier interface than OptimizeIt.
But...that's not the coolest thing. The coolest thing is that you can do this analysis on a live system! The overhead is so tiny and there are no special VM switches you have to turn on to use it. This is because the GC and VM in general already have this information. You can take CPU or heap snapshots and analyze the java code that ran within the snapshots. Really cool stuff.
Check it out.
Bill
A few critical bug fixes in this release. Also, we've done some prototyping of some extensions to EJB 3.0. Specifically:
Goto: The main EJB3 Site for more details
Here's the release notes:
With the addition of annotations in JDK 5 and EJB3 in J2EE, I think we have an opportunity to totally ditch XML-based configuration. This includes EJB deployment descriptors and XML-based IoC "lightweight" containers. So how will you do fine-grain configuration of your components? How will you do the Inversion of Control that you-all just can't live without? This is what I want to talk about in this blog.
The Pico Container/Nanning guys put out an interesting concept awhile ago. Why do you have to use XML to configure your components/interceptors/aspects? Why not configure your services and components within pure Java? Configuring things in pure Java allows you to let the Java compiler typecheck your configuration. Sometimes, with XML you have to wait until deploy time/runtime to see if your XML document is valid. This kind of pure-Java-configuration can be done using EJB3 with inheritance, constructors, method overrides, and annotations.
@javax.ejb.Local
public interface OrderConfirmation {
public void sendOrderConfirmation(String to, Order order);
}
public class OrderConfirmationService implements OrderConfirmation
{
private String from;
private String subject;
private MessageStyle style;
private javax.mail.Session mailer;
public (String from, String subject, MessageStyle style) {
this.from = from;
this.subject = subject;
this.style = style;
}
public void setMailer(Session session) {
this.mailer = session;
}
@MethodPermission({"customer"})
public void sendOrderConfirmation(Order order) {
Message msg = createMessage(mailer, style,
from, subject, order);
Transport.send(msg);
}
private static createMessage(...) {...}
}
So above we have a security constraint set on our bean method and 4 configurable properties.
@Stateless
public class ToyStoreOrderConfirmationBean extends OrderConfirmationService
{
public ToyStoreOrderConfirmationBean() {
super("bozo.clown@toys.com",
"Your Toy Order Confirmation",
new ToyStoreMessageStyle());
}
@Inject("java:/Mail")
public void setMailer(Session session) {
super.setMailer(session);
}
@MethodPermission({"ValuedCustomer"})
public void sendOrderConfirmation(Order order) {
super.sendOrderConfirmation(order);
}
}
So, the constructor is used to set the configurable objects. We override the setMailer method and inject the Mail Service via the EJB3 @Inject annotation. We only allow "ValuedCustomer"s to get an email confirmation by overriding sendOrderConfirmation and retagging it with a new @MethodPermission.
Anyways, that's it for now...
Happy hunting,
Bill
I'd like to elaborate on Anil's blog post about JBoss' new Web Services stack and why we went this route instead of Apache AXIS.
More than a year ago, JBoss licensed the J2EE TCK from Sun to get JBoss ceritified. Web Services is an integral part of the J2EE 1.4 specification. At about this same time, the AXIS project was in flux because IBM had forked AXIS for their own proprietary products and left AXIS development entirely. We needed a compliant web services implementation immediately and AXIS 1.1 and 1.2 just wasn't even close to compliance, so we decided to fork AXIS 1.1 (the 1.2 branch was really unstable at the time). After we had passed certification, we did not officially give the code back to the AXIS project, but it remained ASL licensed so its there for the taking if Apache is interested. Since then, we decided to ramp up our own webservices team and create our own stack. This effort is well underway.
Personally, I'm glad this happened. I feel that the LGPL license and JBoss brand will do a much better job at holding our web services community together. As Anil said, Thomas Diesler will be giving a presentation at JBossWorld on our new Web Services stack.
Happy Hunting
Bill
Over the past week, I implemented a prototype of Transaction Recovery for our transaction manager. It is probably a bit naive and doesn't perform very well, but it does seem to work with my very minimal testing. We're looking for somebody to drive this, so if you, dear reader, are interested, let us know.
More information can be found here on our JTA TX Recovery WIKI page.
How's this for irony though? Tuesday night I was finishing up the impl of the prototype when my laptop crashed with the blue-screen-of-death. It took me about 4 hours to get my laptop up long enough to recover the work I had done on TX Recovery. It would have been even more ironic if I wasn't able to recover the code. After a wasted day of setting up email and a development environment on one of my desktops, I'm finally back to being productive.
Happing Hunting,
Bill
There was a recent dicussion on TSS about overriding annotations. Somebody wrote.
Am I the only one who feels that if annotations need overriding, it's probably a wrong use of annotations? Or is it becoming accepted practice to use annotations as if they're configuration parameters?Just wondering.
In our EJB 3.0 implementation, we're actually using annotations as our configuration object model. Since you are allowed to extend and implement an annotation in Java, this allows us to have one object model instead of having an annotation processor that takes annotations and converts them to an intermediary object model.
The way we will have it working is that the XML processor for the ejb-jar.xml file will allocate annotations and add those annotations as needed to the annotation override facility. Then the EJB container works with annotations as the configuration object model delegating to the annotation override facility.
Using our AOP framework, we define the default annotations for a given container type (Stateless, Stateful, etc...).
i.e.:
<annotation expr="!class(@org.jboss.ejb3.PoolClass)">
@org.jboss.ejb3.PoolClass (org.jboss.ejb3.ThreadlocalPool.class)
</annotation>
This says that if the PoolClass annotation is not defined on the bean class, provide a default value.
All this makes the of our EJB 3 container very very simple in regards to configuration as all the interceptors and components that make up the EJB container have a consistent way to obtain configuration from a variety of sources while having the same configuration model.
Another thing is that we can support quite easily configuration from a varietary of sources. EJB 3 and other middleware will require configuration from XML, annotations, and even a mixture of both at the same time. Annotations provide a great domain model for this and an annotation override facility makes supporting this mixture of XML and annotation configuration much easier to support.
Bill
From a recent discussion on the merits of AOP on the TSS:
From those results, I could come to the following conclusions:-AOP is the best way to patch the original code they had-'Hacked' Java out performed the AOP solution (which is why I believe they added # of images created to strengthen their AOP argument), yet they could still tweak the AOP implementation and beat the 'Hacked' Java version.-Their AOP solution could have just has easily been modeled in Java in an OO way using pipes/filters, and java.io.*-like implementations.-AOP introduces another learning hurdle into the maintenance of the program by other programers-- K.I.S.S.In summary, while the AOP solution worked, you could have just as easily modeled the same solution in straight Java using stateless filters and pipes. The 'fusing' optimizations they are talking about with AOP could easily be modeled in OOP through dependencies/comparators within a pipe of transformations. I don't think you can necessarily say that an OOP solution is ever better than an AOP solution, but why introduce it if you don't need to?
All good points. The main problem is that the AOP community has not focused on the Why, but rather too much on the What. We tried to focus on the why in JBoss AOP's The Case for Aspects user guide.
I think AOP will first be used by the framework developers to make coding easier for framework users. The masses won't know they're using AOP, but using the framework will be butt-simple. From this, the framework developers will discover design patterns. The users will learn from these patterns and be able to apply them to their code. It is a natural evolution.
AOP + Annotations is a perfect example of simpler design. It allows the framework developers to easily encapsulate the functionality their annotations are supposed to introduce without relying on messy unmaintainable code generation (I've written an IDL compiler, so I know what I'm talking about). Users get an easy way to apply these annotations. They just tag their code and use it.
A perfect example of AOP + Annotations is the Asynchronous Aspect Clause Haussenet contributed to JBoss AOP. You tag a method as @Asynchronous which introduces an advice that runs the method in the background, and a mixin that allows you to access an API to get the response of the method asynchronously. I've recently extended this to work remotely. Clean encapsulation of asynchronous behavior combined with the ease-of-use a middleware user expects.
JBoss' EJB 3.0 implementation is based entirely on JBoss AOP. The aspect-oriented design has given us a container that is completely extendible.
JBoss Cache is another example of a framework using AOP for its design internally. They needed to aspectize their code because it was becoming too bloated. And also used AOP to provide transparent caching to their users.
One large problem with AOP is that the ordering of advices is critical in applications of it. For instance, the Asynchronous aspect needs to come before transaction demarcation, but after security. This is where IDE integration can be very important as you need to see what aspects are applied to a specific joinpoint and what order they are in. Advice ordering, IMO, is the one significant hurdle that may make AOP hard to adopt in many situations.
All and all, I find the HUGE adoption problem with AOP is that its hard to understand by reading about it. You need to see examples before you make the connections. Maybe OOP had the same problem. I can't remember back that far.
Another interesting discussion was as follows. Somebody posted this:
OO is not the end all. Different ways to solve different problems. AOP and OOP are not mutually exclusive.
To which an opponent of AOP replied
Correctly used, the two are fairly mutually exclusive. It would be improper to write a whole domain model in aspects or declare all of your intrinsic business behavior in aspects.
I agree with this statement in principal that it is probably incorrect to use aspects to model your domain model, but...Last week I had an interesting dinner meeting with a JBoss user. He was telling me that he scopes out the easy, simple, monotonous work to his offshore team and is starting to use AOP to weave in the more complex stuff he needs to write that the offshore team can't handle. I'll have to get back to him a few months from now to see if this approach was successful. Gotta admit, I'm skeptical, but it is an interesting thought.
Anyways...Thanks for reading this really long post.
Bill
Greetings from Boston, former city of underdogs!
I just think it's so crazy that Pop was 86 when he died and it took 86 years
for the Red Sox to win another world series . . .
that my Dad, Tyler, and I went to a Sox game this year and
that Tyler took dirt from the hallowed grounds of Fenway Park to sprinkle on Pop's grave . . .
I couldn't help but remember him sitting on the porch listening to Jerry Remy
announce a game, or rooting for the Sox in his old recliner, with the volume turned way, way up . . .
I couldn't help but smile when the town was going crazy last night. I hope that
all the yells and cheers, however obscene and drunken, were making it up to his
deaf ol' ears!
Love,
Angela