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?
