In jbossws we have a unified meta data model that is a subset of the AS meta data model. Together with that we have adapters from the AS model to the unified model. The adapters take care of the differences between AS versions.

We also have different deployers for xml based/annotation based meta data. IMHO, its not a good idea to map xml onto annotations only to be able to use the same annotation deployer (if I understand correctly)

I believe the EJB3 project should decide on it's meta data model and use container specific components that populate that meta data model. The model should be expressed in schema, which can then be reused in the context of AS schemas

The metadata and object factories should be associated with the ejb3 or common AS metadata, and the deployers should be part of the AS since they are a part of the AS.

I have some code from last year that replaces both the EJB2 and EJB3 metadata.
Haven't had time to finish it yet. But it basically replaces the EJB2 metadata
with a facade over the EJB3 data (extending the EJB3 metadata to include
all EJB2 features).

It was originally based on the EJB3 metadata from about October
but that had a number of problems so it is nowhere near exact.

I think we should be moving to a common EjbDeployer with different reference policies controlling how the reference is handled (injected or just a jndi binding). Same for the legacy ejb interceptors vs the spec interceptors and aop interceptors. Ideally we should be able to use the new aop interceptors with ejb 2.x components with the new ejb3 container and just drop the old stuff.

I don't want to get too bogged down in supporting this unified view out of the gate for 5.0.0 though. Let's just start refactoring the ejb3 layer with that as the ultimate goal.

I like the idea of having multiple component deployers like CMP/BMP. I want to be able to remove this code for tighter "lighter" distributions.

"wolfc" wrote:

(It's weird that you had to extend EJB 3 metadata to accommodate EJB 2, because EJB 3 should be 100% backwards compatible.)

"wolfc" wrote:
Doh, a xml parsing deployer has order 2000. An annotation parsing deployer needs to run after classloader deployer (4000), so I now have the AppClientScanningDeployer at POSTPROCESS_CLASSLOADER_DEPLOYER (5000).
But this means that a chain of EjbAnnotationParsingDeployer -> EjbParsingDeployer -> JBossEjbParsingDeployer won't work. How can this be resolved?

IIRC, can't you just programmatically define your own order? Also, an annotation parsing deployer does not necessarily need to happen after classloader deployment so long as you have access to the .class file resources. (Javaassist).

Also I don't see why it matters what order you process meta-data. Why does annotation processing have to happen first?

"scott.stark@jboss.org" wrote:
I don't know if the attachment type ordering is part of the refactoring Adrian has done. Its something we talked about.

"bill.burke@jboss.com" wrote:
IIRC, can't you just programmatically define your own order? Also, an annotation parsing deployer does not necessarily need to happen after classloader deployment so long as you have access to the .class file resources. (Javaassist).

<jboss-classloader>
 <ignore-package>com.acme.notused</ignore-package>
</jboss-classloader>