Skip navigation
2004

Bill Burke's Blog

September 2004 Previous month Next month
bill.burke

JBoss AOP 1.0 RC2

Posted by bill.burke Sep 24, 2004
I'm pleased to announce the release of JBoss AOP 1.0 RC2. We're getting closer to our 1.0 release next month. Kabir Khan joined the team fulltime September 1st and has done an amazing job helping out. We put a lot of effort into documentation this release and have written a reference guide in docbook. Also, a number of things have been added to the framework. We've added an annotation model so that you can use that instead of XML. We've also added Java-Bean style configuration for aspects and the ability to plug in any IOC framework you wish.

Here's full RELEASE NOTES: 
--------------
JBossAOP 1.0 RC2
--------------
* Added DTD finally and DTD parsing
* <annotation> tag has been renamed to <metadata> as we're not defining an annotaton, but rather metadata.
* <annotation-loader> tag has been enamed to metadata-loader
* Added integration with JDK 5.0 java.lang.instrument.  Very clean classloader integration now.  
No need for SystemClassLoader plugin for JDK 5.0.
* <aspect> can take a factory now
* <aspect> class can no longer be XmlLoadable
* <interceptor> can take a scope now <interceptor scope="PER_INSTANCE"/>
* InterceptorFactory should only be used if you are inserting them directoy within AdviceBinding.  
AspectFactory should be used now for all InterceptorFactory's as <interceptor> now supports SCOPE.
* <mixin>'s can now be declared as non-transient fields by doing:  <mixin transient="false";gt;.  This allows mixins to be serialized.
* If you don't specify a factory, you can configure your aspects/interceptors as
 java beans.  See the beanstyleconfig tutorial item.
* Added annotation replacement for XML.  @Aspect, @Bind, @PointcutDef, etc...  See tutorial/docs for more info.
* Created full complete reference manual available in PDF and HTML.
* Fixed debugger bug.  AOPC was overwriting debugger information

Have fun,
Bill

We have some interesting things going on in CVS that will be in the RC2 release later this month. Let's take a look

 

Configuration

Kabir Khan is doing some great work. Recently he added the ability to configure Aspects and Interceptors like Java Beans. (In the past Aspects/Interceptor classes or their factories had to implement XmlLoadable and parse XML themselves) Here's a simple example:

 

   <aspect class="SomeAspect" scope="PER_INSTANCE">
      <attribute name="IntegerAttribute">5555</attribute>
      <attribute name="StringArray">aspect,per,class</attribute>
 
      <advisor-attribute name="MyAdvisor"/>
      <instance-advisor-attribute name="MyInstanceAdvisor"/>
      <joinpoint-attribute name="MyJoinpoint"/>  
   </aspect>


The advisor-attribute, instance-advisor-attribute, and joinpoint-attribute allow you to inject the JBoss AOP manager classes so that the aspect can obtain additional information about the objects/joinpoints it is intercepting.

We have also refactored interceptor and aspect configuration so that you can plug in your own factories to delegate to insert-your-favorite-IOC-framework-here.

 

 

Annotation configuration model

We're also providing an annotation alternative to XML. You can declare your pointcuts, bindings, introductions, etc... within an annotated Java class.

 

@Aspect(scope=Scope.PER_VM)
public class MyAspect {
   
   @PointcutDef("call(public * Foo->*(..))")
   public static Pointcut fooPublicMethods;
 
   @Bind(pointcut="MyAspect.fooPublicMethod OR get(* Foo->*)")
   public Object myAdvice(Invocation invocation) throws Throwable {
     ... advice implementation ...
   }
}


Annotated aspect configuration can also be done with JDK 1.4 and our Annotation Compiler.

 

/** @@org.jboss.aop.Aspect(scope=org.jboss.aop.advice.Scope.PER_VM) */
public class MyAspect {
   
   /** @@org.jboss.aop.PointcutDef("call(public * Foo->*(..))") */
   public static Pointcut fooPublicMethods;
 
   /** @@org.jboss.aop.Bind(pointcut="MyAspect.fooPublicMethod OR get(* Foo->*)") */
   public Object myAdvice(Invocation invocation) throws Throwable {
     ... advice implementation ...
   }
}


@Aspect, @PointcutDef, and @Bind are already supported in CVS. We'll be adding support for the rest for the scheduled RC2 release later this month.

Enjoy,

Bill

 

 

 

 

bill.burke

EJB is not dead

Posted by bill.burke Sep 10, 2004

 

I was around for the DCE days in the early 90's. Worked at Iona during the CORBA years in the late 90's. Contributed to JBoss and J2EE in the millenium. So, I'm starting to gain some perspective on the evolution of middleware specifications.

 

The evolution of DCE and CORBA was an interesting one. They both solved complicated problems, but each iteration of the specification added more and more features, but never really tried to step back and refactor the architecture to simplify the programming model. This is why I'm very excited about J2EE 1.5. It is quite refreshing to see that the main focus of J2EE 1.5 and EJB 3.0 is simplifying development.

 

I'm also impressed at Sun's stewardship. They recognized from XDoclet and .Net the power of Annotations, changed the Java language, and are now trying to leverage this within J2EE and other specifications. You may think : "Hey, if they don't simplify J2EE, J2EE is dead. So, of course they would do this." But, recognizing and accepting that that your specification needs serious revision is half the battle. The OMG failed to do this.

 

Its funny the lack of perspective some individuals have. Some bozo on TSS said in regards to EJB: "This is one of the key and most disturbing points about EJBs... This is why specs should start slim (or just wait) and build out as there's a consensus on best practices, not try to codify an architecture front-to-back first, then see how they're used."

 

As an industry, it could be said that EJB was the consensus of best practices at the time. O/R had been around for awhile in Java and even further back, in C++. People were doing it in various proprietary products or within in-house IT infrastructure groups. Same goes for distributed computing as the industry tried to take best practices in that area to create the DCE and CORBA specifications.

 

Best practices change and improve over time. If we took the approach of not standardizing, the industry would not be able to unify and evolve. Software evolution consists of iteration upon iteration. Without a specification, it is much harder for the industry as a whole to iterate. It also allows organizations who cannot bet their business on bleeding edge technologies so that they can code to some agreed-upon best practice and API even though it may or may not be the best.

 

That doesn't mean innovation should be relegated to a standards body. Organizations like the JCP should be a place to standardize innovations, not create them.

 

Bill

Filter Blog

By date: