Hi Armin,
Sorry I'm late getting back to you.
At this point we're getting beyond the scope of Remoting. I would suggest that
you try the EJB 3.0 forum,
http://www.jboss.com/index.html?module=bb&op=viewforum&f=221
or the Installation, Configuration & DEPLOYMENT forum,
http://www.jboss.com/ind
The exception occurs right during the lookup. Not before.
I had a look at my exception. It states that the RMIClassLoader tries to
loadProxy classes. It tries to load the interfaces that i dont have in my ear.
I had enabled the WebService (DownloadServerClasses=true).
I have a RMISecurityManager
Ok. It sounds like I misunderstood when I thought you wanted to reference the
unknown interfaces *in your code*. The problem is occurring before you even
get there, in the JNDI lookup, right?
It looks like the JNDI lookup is using RMI, so it seems like you want to enable
RMI dynamic classload
let me explain my situation:
i'd like to have ejb behave polymorphic like with plain java classes. I know
ONE interface of my ejbs but not ALL - and i don't need to know them all.
All my ejbs implement one common remote interface. I create ejb instances with
a lookup and assign the ejb proxy
If I understand correctly, what you're asking for isn't going to be solved in
Remoting. The Remoting remote classloading facility is used only to unmarshal
classes coming from the server.
But you're up against Java typing. To be able to use an interface, you would
need to refer to it in your
Thank you, Ron.
Yet, one thing remains, perhaps based on my missconception:
I took your ScopedTest and changed according to my use case:
TravelAgentBean now implements another @Remote interface, namely
SpecialTravelAgent. This interface is not available in the clients class loader.
When the cli
I've fixed this issue for Remoting release 2.2.2.SP8.
org.jboss.remoting.marshal.MarshallerLoaderHandler, which is the
ServerInvocationHandler for the classloader Connector, now is able to search
org.jboss.mx.loading.HeirarchicalLoaderRepository3s, which allows it to find
scoped classes. In ord
Ok, i found that the reason actually was my using isolated ears with dedicated
loader repositores, enabled in the jboss-app.xml
http://www.jboss.org/j2ee/dtd/jboss-app_4_2.dtd";>
|
|
| palmyra-bsp-bestandsdaten-1.0:loader=bsp-bestandsdaten-1.0.EAR
|
|
