geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim McConnell <tim.mcco...@gmail.com>
Subject Re: Division of responsibilities for annotations to xml and jndi entries
Date Tue, 27 Feb 2007 15:45:05 GMT
This is the error I'm getting from the new EJB classloader....

java.lang.Exception: Could not load 
calculator-stateless-war-2/0-SNAPSHOT/war/WEB-INF/classes/org/apache/geronimo/samples/calculator/CalculatorServlet.class
         at org.apache.xbean.finder.ClassFinder.readClassDef(ClassFinder.java:690)
         at org.apache.xbean.finder.ClassFinder.<init>(ClassFinder.java:139)
         at org.apache.xbean.finder.ClassFinder.<init>(ClassFinder.java:95)
         at org.apache.xbean.finder.ClassFinder.<init>(ClassFinder.java:84)
         at 
org.apache.geronimo.web25.deployment.AbstractWebModuleBuilder.processAnnotations(AbstractWebModuleBuilder.java:772)
         at 
org.apache.geronimo.web25.deployment.AbstractWebModuleBuilder.makeMetadataComplete(AbstractWebModuleBuilder.java:696)

Thanks,
Tim McConnell


Tim McConnell wrote:
> 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
>>
>>
> 

Mime
View raw message