[alesj]

Then JARStructure does something like:

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

This 'visitor pattern' definitely looks better.

But in this case the context used in JARStructure
looks useless to me, since I don't have any access to it
from EARStructure code - in EARStructure::scanEar.

Unless I access parent context's callbacks.
Which is too impl specific - ear contains jars notion.

[adrian.brock]

"alesj" wrote:

Unless I access parent context's callbacks.
Which is too impl specific - ear contains jars notion.

Why would you want to run your own callbacks,
you would just execute the code directly. ;-)

I'll leave it to you on how much of a generic framework
you want to put in place for a parent "interfering" with child structure.
It could easily be "over-engineered", with callbacks for every critical decision
in structure determination that nobody uses and instead just leads to extra complication
and bugs.

To be honest I can't guess how many other use cases there are or will be in future,
either from the javaee spec committees or users.

My preference would be to have a simple "template" that can be extended
as new requirements are identified.

Refactoring ever policy decision of the structure deployers
into protected methods so users can subclass and add/change behaviour,
(e.g. add their own callbacks) would help with "forward compatiblity",
but its not something that needs to be done immediately.