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