There are the main javaee module types (web, ejb, client, etc) and
then there are additional things that go into one of these that also
have annotations that indicate injection, such as JSF and jaxws.
Just as with the main module types, we can divide the annotation
processing work into two phases:
1 identifying the classes to search for (additional) annotations
2 scanning each of these classes for the additional annotations that
indicate something needs to be injected. In general this will result
in some representation of the annotations ending up in xml.
3 actually injecting stuff at runtime.
I made a suggestion for (3) in an earlier email today so I won't
discuss that further here.
(2) can be covered by our existing NamingBuilders.
That leaves (1). Identifying the classes is not really a problem,
but how to plug this identification into our deployment framework is
a little less clear. I think that all the extension types go into
web modules (can ejb web services be identified solely by
annotations?). I see 2 choices:
a. the extension module shares a ClassFinder with the enclosing (web)
module, in which case all the injection annoations found in (2) will
be in one big set, probably shared among 2 or 3 classes that do the
injecting.
b. each extension module has a separate ClassFinder, also separate
from the enclosing modules' ClassFinder. This _might_ work better
for ejbs and would make constructing the classfinder easier, since
each module can simply figure out its classes and proceed without
reference to any other submodule or parent module.
In either case having the submodule deployer be a
ModuleBuilderExtension seems reasonable to me: with choice (b) it
needs little interaction with the parent module. I'm not sure if it
would be useful but we might want to create additional Module
subclasses to track information for the submodules. It may be that
all the work happens in addGBeans and that an extra module would have
nothing to do.
Comments?
thanks
david jencks
