AOP 1.3.0 Available
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.
Propagating Dependencies
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.
Hot Swapping
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...
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:
- Use an annotation if the metadata you are applying changes the design of your class.
- Use an annotation if the metadata changes the design of code interacting with your class.
- If your application needs to be portable between app-servers or databases, don't use an annotation that will not allow you to be portable
- Use XML when you want to configure on a per-deployment basis.
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.
@Stateless, @Stateful
Rule 1 is triggered here. You need to know if the EJB you are working with can hold state or not. Pretty obvious that this should always be used.
@Remote, @Local
At first glance, I thought that this possibly triggered Rule 4. Then I thought that it is important to know the semantics of the interface you are invoking on. Going through a @Remote interface forces call-by-value semantics. @Local forces call-by-reference. You'll probably want your application code to realize this just by navigating to the definition of the interface.
@TransactionAttribute
Rule 1 definately applies to @TransactionAttribute. Whether or not your code is invoked in the context of a transaction usually effects the design of your code. For example, you cannot access an EntityManager service when you aren't within a transaction. I don't think Rule 3 applies here since you probably don't even want to allow deployers to change your transaction boundaries at deployment time as the design of your code may depend on it. @TransactionAttribute looks like a good candidate for always being used.
Security annotations
For security annotations I think Rule 4 applies. Rule 1 isn't triggered because security probably has little to no effect on the design of the Session bean you are writing. Rule 3 isn't triggered because your application will remain portable, but you may want to configure security on a per-deployment basis. Then again, how often does one change XML DDs after the JAR is built? How often to operations people actually modify XML DDs?
Persistence
First let's look at purely logical Entity bean annotations. @OneToOne, @OneToMany, @ManyToOne, @ManyToMany, @Basic, @Serialized, @Transient. The relationship annotations give information about the bi or unidirectionalnes of a given relationship. This effects how you wire the relationships at runtime when creating or merging. The FetchType tells you whether or not the property will be lazily loaded or not. THis effect code interacting with your beans as to be totallyl performant, queries might have to use the "fetch" keyword to preload relationships in the same query. @Transient is important because you'll need to know whether something can be accessed within a query or not. @Transient properties might also something you'll want to initialize in a @PostLoad callback. So, all and all, I think these mappings fall under Rules 1 and 2.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.
Conclusion
It looks like for Session/MDBs, annotations might be preferrable over XML, while for persistence it is less clear. For persistence I think the general case will be to use annotations except for primary-key generator definition and the case where a class is needed to be mapped to more than one relational structure. Annotations will also be really nice when you have tools that generate Java code from relational schemas as you won't have to continually be referencing verbose XML documents to figure out how to interact with your persistent objects. Annotations are not only useful to describe metadata for frameworks, but are also a form of documentation. I remember Gavin talking at the NEJug saying that
@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() {...}
Hibernate Annotations Alpha 4
The Hibernate 3.0 annotations project provides standalone EJB 3.0 annotation mappings for persistent objects. Some of the new features in this release include:- Mostly complete EDR2 support including default sensitive values of association mappings
- Hibernate extensions. New Hibernate specific annotations to provide more mapping flexibility (caching strategy, type overriding...)
- Better and more complete test suite and documentation
Check out Hibernate's Annotation page for more information on downloading and documentation.
JBoss EJB 3.0 Preview 5
JBoss EJB 3.0 provides an implementation of both the EJB and Persistence specifications of EDR2. New features in the release include:- Tight integration with Hibernate Annotations project
- Application Transactions. Test out long-lived persistence contexts.
- Hibernate 3.0 Integration. Mix and match EJB 3.0 annotated class files with .hbm.xml mapped class files all managed by EJB 3.0 EntityManager service. Get access to hibernate specific APIs.
- Full clustering support
- Richer documentation set.
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:
- Service EJBs. Singleton services that can publish Local, Remote and new JMX @Management interfaces. Also support JBoss service lifecylce callbacks and dependencies.
- Message Drive POJOs. MDBs with a typed interface. No more verbose messaging code.
- Lightweight local/remote Asynchronous proxies. Any local or remote EJB reference of any EJB type can be transformed into an asynchronous interface so that you can invoke EJB methods asynchronously.
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.
Plain classes as base
The key is to model your beans as plain classes at first. These plain classes will be the base for all your service beans. Let's define a Stateless Bean that is will be used to confirm orders in an e-commerce application via email.
@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.
- From and subject are self-explanatory.
- style is a pojo that defines how our email message will look.
- mailer is a reference to our Mail session. A reference to a service
Configuring with Inheritance
In this example, we are defining a stateless bean for order confirmation for each one of the business units of our e-commerce application. We will use constructors and method overrides to modify the configuration.
@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.
Disadvantages
Ok, so I lied...So you can't use this approach for everything. Here's some example:- You can't use this approach for Entity beans. Entity beans are POJOs in EJB3 and must be allocated with with the new operator. So, if you need to override persistence mappings per deployment, you'll have to use XML.
- There's really no standard way of configuring domain objects like MessageStyles and sharing this standard configuration between various components.
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
BillJBoss AOP 1.1 has been released. A lot of bug fixes and features have been added since the 1.0 release. See the release notes below for more detail.
http://www.jboss.org/products/aop/release11
http://www.jboss.org/products/aop/release11
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
This is an example of what the Red Sox winning the world series means to its fans. This is a blast email from my cousin Angela to the 14 sons and daughters of my late grandfather, Harold "Pop" Burke, to his 40 some-odd grandchildren, and 20 something great-grandchildren. It brought tears to my eyes.
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
Actions
Filter Blog
By date: