Geiger, Marco (FF) wrote:
Hi Berin,
an Info :
the using of the Reflection-API in Fortress
isn?t generally denied. The EJB-Spec does only not allow to access
information
about security, but normal Reflection for Classes is therefore allowed.
(the classloading-mechanism is the bigger problem, and knock-down-criteria
for me)
Ok, so the klass.newInstance() and method.invoke(...) _are_ allowed?
How about Proxy or Byte Code generation?
Fortress uses whatever classloader is given to it, or the
Thread.currentThread().getContextClassLoader() if it is not explicitly
given. The major problem I have run into is that there is no _real_
standard on what the ClassLoader allows. For instance IBM WebSphere
(last I used it was 3.5) did not allow you to get resources from the
classloader.
However, in the future, we may try to gather the meta information from
the classes themselves--which would definitely require a special
classloader.
Binding Fortress to JNDI does not solve the problem.
(that?s what I understand without any problems).
Because one thing that is missing the Spec is the
"fortress-lookup"-Method inside an EJB, although I
get the reference to fortress by JNDI.
I was talking about either binding the components Fortress manages to
JNDI or binding the ServiceManager to JNDI. Not Fortress itself.
But, how would you bind the services to JNDI that an EJB can use it without
missing
the Spec ?
That seems not clear to me.
Any hints to me ?
You can get better information from the Cocoon team on this, because
they are using ECM in J2EE environments, and have cross this bridge
before. However, the basic idea is that you bind the ServiceManager
to JNDI in the Servlet space where it can do all it needs to do, and
access it from EJB space.
You may have to use something other than the "java://" base lookup
protocol because that is reserved for J2EE.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
