[jboss-dev-forums] [Design of POJO Server] - Re: JavaEE Deployers need redoing again

[scott.stark@jboss.org]

"adrian at jboss.org" wrote : 
  | I don't know why standardjboss.xml has to be an attachment. A single
  | deployer that does both the parsing (during bootstrap) and merge
  | would suffice.
  | It should be after all the other mechanisms to create ejb deployment metadata
  | including the annotation build.
  | 
It could be moved into the MergedJBossMetaDataDeployer.

"adrian at jboss.org" wrote : 
  | 2) MISUSE OF createMetaData()
  | 
  | JBossAppParsingDeployer does ...
  | 
  | This processing should be in a seperate deployer it is not parsing work.
  | 
  | I want to kill the allowReparse() option once we have the parsing
  | deployers that can parse multiple metadata files.
  | 

"adrian at jboss.org" wrote : 
  | 3) AbstractVFSRealDeployer is deprecated
  | 
  | Anything that is not following the deployer model and is accessing the 
  | VFS/ deployer structure in undefined ways should extend this deprecated deployer.
  | 
  | It means we haven't thought hard enough about how to include what is
  | going on in the deployer model and we need to come up with some abstraction
  | such that it can be done safely and others can share the working code.
  | 
  | AnnotationMetaDataDeployer does not extend the class, ...
  | 
Obtaining the annotations that affect deployment is a basic feature of deployment that needs to be supported.

"adrian at jboss.org" wrote : 
  | 4) Scalability and error proneness
  | 
  | AnnotationMetaDataDeployer has this horrible code:
  | ...
  | a) There is no way to add new deployment types.
  | e.g. Where do I include aop checking for isMetadataComplete()
  | and looking at the classes as they are visited?
  | 
  | b) Where I do add/modify the processors either for my own custom
  | annotations that create metadata or to replace a buggy processor
  | to fix a problem?
  | 
Currently the annotation to metadata processors require the root classes to build the associated metadata structure. It cannot be integrated into a visitor pattern. Whether this becomes an extensible annotation based deployer, or deployers for each deployment type is added is the question. We need better support for annotations in the base deployment layers.

"adrian at jboss.org" wrote : 
  | 6) PostClassLoader
  | 
  | If we need a seperate stage before the REAL deployers to analyse the whole
  | deployment, we should define a new stage, e.g. PRE-REAL or something.
  | This would also be the point where add dependencies to the REAL
  | stage of a deployment for things like ejb-ref dependencies. 
  | 
Yes, we need this stage. 

"adrian at jboss.org" wrote : 
  | GOING FORWARD:
  | I'd like to fix all this, but I guess it is too close to Beta3.
  | Instead this is something I'm going to work on for RC1 once Beta3 is out.
  | 
  | One thing this does show is that we really need some tests that
  | simulate what the profile service is going to do when it is fully up and running.
  | i.e. programmatic deployments from the modifications of the attachments
  | created from an initial deployment.
  | I'm pretty sure this is all broken with the current state of the deployers. :-(
  | 
Yes, the current deployment tests in the mc are way too simple. We need tests that exercise deployers at every stage.


View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4110292#4110292

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4110292