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
