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

adrian@jboss.org do-not-reply at jboss.com
Wed Aug 6 09:43:52 EDT 2008


"alesj" wrote : "adrian at jboss.org" wrote : I don't really understand what you are trying to do,
  |   | but children are described by the ContextInfos of the StructureMetaData.
  |   | 
  | I need a place to store found annotations.
  | Or, a way to get additional information about deployment,
  | e.g. it's an EJB deployment since there is some class annotated with @Stateless.
  | 
  | In the case of EAR I need to check all sub deployments that are not explicitly described in application.xml.
  | First they need to be recognized by some strucuture deployer, in our case currently only JARStructure can recognize it (combination of StructureContext.isCandidateAnnotationScanning() && Deployer.isSupportsCandidateAnnotations() == false).
  | After it is recognized, I need to add additional type information to the EarModule metadata (EJB, Client, Connector, Service, ...).
  | 
  | So, I was thinking of keeping found annotation classes in the StructureContext instance.
  | But in EAR's case, I have access to top level structure context, where I actually need to check sub context's found annotations.
  | 
  | I don't see how ContextInfo can help me there.
  | Unless I keep this annotation lookup info there.
  | 

Looking at the MockEARStructureDeployer, isn't the issue
that you need to be able to do some extra processing once you've
found the annotations?

i.e. not only does the EARStructure need to setCandidateAnnotationScanning(true)
it also needs to be able to pass a callback such as


  | public EARCandidateAnnotationsCallback implement CandidateAnnotationsCallback
  | {
  |    List<EARModule> modules;
  | 
  |    public EARCandidateAnnotationsCallback(List<EARModule> modules)
  |    {
  |        this.moduleMetaData = moduleMetaData;
  |    }
  |    
  |    public void annotationScanningCallback(StructureContext context, AnnotationEnvironment env)
  |    {
  |          EARModule module = determineModuleFromAnnotations(context, env);
  |          modules.add(module);
  |    }
  | }
  | 

Then JARStructure does something like:


  | if (annotationScanningEnabled && deploymentRecognised && annotationPresent)
  | {
  |    addChild();
  |    context.runAnnotationScanningCallbacks(context, env);
  | }
  | 

I'm not suggesting this is the exact way you should do it,
since I haven't looked at the problem domain, but
this kind of "visitor pattern" is usually preferable to trying
to hack some kind of state into stateless designs
which always gets very messy and hacky.

Especailly in cases like this where the JARStructure should not
need to know anything about EARs. 
The EARStructure may not even be deployed in some environments!
There could be other top level structures that also want this behaviour in future.

P.S. In case you haven't already spotted it (its not mentioned in my
original blurb), you also need some logic to avoid visiting candidates
and doing annotation scannning on modules that are already known
by the EARStructure from the xml.

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

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



More information about the jboss-dev-forums mailing list