Hi David, Just a few comments to consider:
-- This interface you mentioned is now complete and attached as a patch to
GERONIMO-2870. The interface basically allows multiple application types (e.g.,
WebAppType, ApplicaitonClient, etc...) to reuse the same XmlBeans code that
exists in the AnnotationHelper classes. This will facilitate adding support for
more than just the Web apps that we're currently supporting for annotations (via
AbstractWebModuleBuilder).
-- I believe there is a problem with the additional classloader added to support
remote/local EJB's--it does seem to work but gets a "java.lang.Exception"
exception in ClassFinder that is likely contributing to and exacerbating the
longer delays when deploying EJBs.
-- The notion I currently have of the AnnotationHelper classes is to encapsulate
as much of the annotation processing as possible and isolate that underlying
function(s) from the consumers of those classes. If that is still the case, I
believe that they can be invoked elsewhere (i.e., in the NamingBuilders as you
suggest) without much adverse impact. If the functions that they provide need to
change though we may want to rethink/revisit what it is that I'm encapsulating.
-- Finally, before we move the annotation processing to the naming builders it
might be useful to step back a little and articulate the 5-10 most critical
usage scenarios that we need to support for annotations. That might help with
the proper placement of the annotation support and uncover the information/data
required to support these usage scenarios. I know this would help me as I've
currently only been considering the most obvious mechanical translation
scenarios, which as suggest may not be sufficient. I shall come up with a short
list of scenarios first thing tomorrow for review.
Thanks,
Tim McConnell
David Jencks wrote:
While working on injections for jetty I ran into a problem with ejb
annotations not indicating whether they are local or remote. I solved
it with a rather brute force attack of just building an additional
ClassFinder and looking for all the ejbs. This is really unpleasant
because openejb has to do the same work all over again. After talking
with David Blevins on IRC for a bit to try to understand the problem
better I've come to the conclusion that our current division of
responsibility between the annotation stuff Tim's been working on and
the NamingBuilders is not very good. Actually figuring out what xml is
the accurate representation of an annotation requires deep understanding
of the meaning of the annotation, not just a mechanical translation. As
such it should be done by the NamingBuilder that is part of the
implementation of the system we are referring to.
This means that the NamingBuilders need more information that just the
xml from the spec dd. They also need information about the annotations
involved and they need to be the code that modifies the spec dd.
IIUC Tim is working on providing an interface that provides for updating
spec dds with additional refs. I think that this can be used by
NamingBuilders to add whatever xml they come up with. I expect a lot of
the code in EjbAnnotationHelper and ResourceAnnotationHelper is going to
need to move to NamingBuilders.
So, I've concluded that the information in the annotations need to be
supplied to the NamingBuilders in some form, but I don't have a clear
idea yet about exactly what form. I think that something like a map
from annotation to Member might be adequate. It might be better so
extract the info into something more like the xml info, or it might be
better to pass in the classes with annotations, or something else.
I expect to be thinking about this over the next day or two and comments
and ideas are more than welcome.
thanks
david jencks
