[jboss-dev-forums] [Design the new POJO MicroContainer] - StructureContext and candidate annotations

[adrian@jboss.org]

https://jira.jboss.org/jira/browse/JBDEPLOY-66

I've done the basic StructureContext stuff.

That's leave Ales to do the JBDEPLOY-67.

The basic idea of JBDEPLOY-67 is introduce a new mode to the candidate
deployment visitor. Where we not only check that we recognise the context,
but also check whether the context has one a given set of annotations.

I'd suggest:

1) Add a property to StructureContext, something like

  | boolean candidateAnnotationScanning;
  | 

2) In MockEARStructureDeployer add code to visit children in this mode

  | structureContext.setCandidateAnnotationScanning(true);
  | addAllChildren(structureContext);
  | 

3) Add a new property to StructureDeployer

  | boolean supportsCandidateAnnotations;
  | 
The default should be false and avoids invoking structural deployers
that don't understand what this means.

4) In StructureDeployerWrapper, ignore StructureDeployers where this
property is false when the candidateAnnotationScanning is enabled.

5) Add support to AbstractStructureDeployer to scan for annotations
i.e. add a 

  | Set<Class<? extends Annotation>> candidateAnnotations;
  | 
with a helper method.

Currently the MockEARStructureDeployer does this wrong because
it is using the vfs resource visitor, which doesn't exist at this point - no classloader.

6) Modify JARStructureDeployer to invoke the additional annotation scan check
when candidateAnnotationScanning is enabled and if it fails, do a
structureContext.removeChild(context);
that it just created.

This check should happen before it itself looks for subdeployments.

It's important that it only includes the root in the scanning since
we don't want to add a jar to an ear if it is a class in one of the manifest
jars that has an annotation.

This seems to me the easiest way to resolve the issue with minimal
disruption to the logic in other structure deployers.
i.e. You have to explicitly write and configure this behaviour on your
structure deployer.

If we decide we should do the same thing for wars in the future
it should be easy to reuse the same code. As long as the helper
code supports multiple roots in the virtual files to scan,
i.e. WEB-INF/classes and WEB-INF/lib/*.jars

It also externalises the annotations that we look for, so we can
add things like JBoss's EJB3 @Service or anything new that comes along.

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

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