geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim McConnell <>
Subject Re: Division of responsibilities for annotations to xml and jndi entries
Date Tue, 27 Feb 2007 05:35:55 GMT
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 

-- 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.

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

View raw message