[jboss-dev-forums] [Design the new POJO MicroContainer] - Re: Annotation Tests in deployers-vfs

[adrian@jboss.org]

My guess is that these deployers needs rewriting such the flow goes something like:

1) Deployer that collects Bean/BeanFactory annotations as attachments
2) KernelDeploymentDeployer is ammended to create components
for any Bean/BeanFactory (if metadata doesn't exist).

The association between the two deployers would be some collection
of annotations or the annotation itself with an associated factory for each.

In pseudo code:


  | An abstraction that defines how to create a BeanMetaData
  | from a Bean or collection of Beans (or in fact something more generic)
  | 
  | public interface AnnotationProcessor<Class<A extends A>, Class<B extends Collection<A>>, C>
  | {
  | ...;
  | }
  | 
  | With a concrete implementation for BeanMetaData
  | 
  | public class BeanProcessor implements AnnoationProcessor<Bean, Beans, BeanMetaData>
  | {
  | ...;
  | }
  | 
  | KernelDeploymentDeployer would take the processor(s)
  | This could probably be done generically in the abstract component deployer
  | 
  |    public KernelDeploymentDeployer(List<AnnotationProcessor> processors)
  |    {
  |       setDeploymentVisitor(new KernelDeploymentVisitor());
  |       setComponentVisitor(new BeanMetaDataVisitor());
  | 
  |       // Add setInput for Bean/Beans, i.e. processor.getAnnotation/s()
  |       // Add setOutput for processor.getOutput(), i.e. BeanMetaData
  |       setProcessors(processors);
  |    }
  | 

The component deployer would then visit the Bean/Beans annotations
invoke run the processor then call the relevant the addComponent method 
of the normal visitor.

Of course you need a way to handle duplicate names but that should be
known by the processor.

With this generic processing in place, we are back to a more reasonable flow.

* A proper depdendency between deployers
* You can easily insert between the deployers and understand what is happening
* You can replace deployers to get different behaviour
* Using a visitor pattern for the processors makes error handling easy/less error prone
* Other deployers can reuse the new metadata in an understandable way

e.g. There would be nothing to stop me writing a deployer that does

  | Bean bean = AnnotationFactory.createAnnotations("@Bean ...");
  | unit.addAttachment(Bean.class, bean);
  | 
and it would get processed naturally.

Although I don't know why you want to do this. :-)

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

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