Title: RE: EJB ClassCastException problem
Thanks Karl. I missed the parent attribute because I've been looking at older docs in my
1.2.9 install area which don't have it. Maybe it was put in since 1.2.9. The udated docs
on orionserver.com contain the parent attribute.
I probably should've been more clear in my response. I really wasn't trying to say the concept
of application namespace domains was a limitation in of itself. It does make sense. I was really trying
to say that if you can't access or share components across apps, then that would be a limitation. The
parent attribute looks like that will do what we want. I'll try it out. Hopefully my ejb-refs
will work as well.
-Original Message-
From: Karl Avedal [mailto:[EMAIL PROTECTED]]
Sent: Saturday, September 30, 2000 7:04 AM
To: Orion-Interest
Subject: Re: EJB ClassCastException problem
Hello Erin,
Look at
http://www.orionserver.com/docs/auto/attributes/parent_(server.xml_-_application).html
The parent attribute is used for exactly what you want, a child application sees
the objects of its parents, so you can have an application hierarchy where you
have shared EJBs in the root node and more specialized in the children. By
default every application has the global application as their parent (just like
all Java classes inherit java.lang.Object).
Example:
application name=utils path=../applications/utils.ear auto-start=true/
application name=webshop path=../applications/webshop.ear auto-start=true
parent=utils/
(This is in server.xml btw)
The rationale behind having a domain/application based JNDI tree is the same as
the rationale behind OO. You want to hide the different applications from
eachother, so that they don't interfere with eachother.
This is especially useful when you deploy 3rd party applications or in hosting
environments when an Orion instance is possibly shared between more than one
user.
Regards,
Karl Avedal
Erin Hill wrote:
I have had that same problem. Like you, I have been pulling my hair out
trying to figure out
how to access a component in one application from a component in another. I
too stumbled
upon the RMIInitialContextFactory as well but I cannot cast/narrow objects
obtained via JNDI.
I always get a ClassCastException. I have temporarily gotten around the
problem by using
reflection to call methods but it's not a solution. I think it's a bug in
Orion. I believe it's a class loader
issue. The object returned from JNDI and the class object you pass to narrow
have different
class loaders - it appears to me each application has its own class loader.
I am frustrated by the fact that I cannot access beans across application
domains without resorting
to proprietary incantations. ejb-refs do not work either across domains -
deployment fails.. I think this
feature is a non-comformance of the J2EE/EJB specs. The spec says nothing
about partitioning the
namespace. The container should resolve the ejb-ref no matter where the
referenced bean resides. Other application servers I have tried employ a
flat namespace and do not have these issues.
Overall I think Orion is a good product but I see application namespace
domains as a limitation.
I really don't see the rationale behind the design. You cannot see another
apps namespace with
the JNDI context provided by the container but you CAN using another context
(RMIInitialContextFactory).
Seems inconsistent to me.
Ill be interested to see how they handle domains when they implement
IIOP/CosNaming for EJB 2.0.
Will C++ CORBA clients see a flat namespace?
