Hi David,
The problem you describe is a result of the interaction between the
java.rmi.server.RMIClassLoader and the OSGi classloader. I'm only
aware of two projects that have that have done serious work with RMI
and OSGi which are R-OSGi [1] and Newton [2]. I can only comment
specifically on Newton as I am one of the main developers on this
project.
In Newton we very quickly (i.e. about two years ago) ran into exactly
the problem you are describing and I can tell you that the generic
solution is pretty difficult - due to the number of possible routes
into the OSGi classloading space from an external classloader - lots
of reverse lookups and indexing is required to make this work at
anywhere near a useful speed in a real world situation.
However our solution (which is in use in production environments) is
seamless to the developer in all but the most complex of scenarios
and
does not require modification of third party jars to include
DynamicImport-Package: *. I mention complex scenarios as there is a
situation which is a little difficult to describe in email (needs a
diagram - but I'll try) where implementation classes that are not
declared in a public api bundle need some extra help to get across
the
wire. In this complex situation we have a work around based on the
notion of codebases (used extensively in Jini [3] (now Apache River
[4]) but less well known outside of that community. We are currently
exploring making even this last case seamless to the developer but is
not yet a part of our release.
Our work has been fed back into the OSGi enterprise expert group, but
as far as I'm aware this is not yet included in the fourth coming
OSGi
4.2 specification.
In summary the Newton project makes RMI and OSGi work together and we
support Spring-DM as a core part of our platform. Newton is
opensource
(licensed under the AGPL) but we also have a commercial product
Infiniflow [4] which provides a wealth of extended features such as
security, management and resilience capabilities.
Hope that's of interest/use.
Regards,
Dave
[1] http://r-osgi.sourceforge.net/
[2] http://newton.codecauldron.org
[3] http://www.jini.org/wiki/Main_Page
[4] http://www.paremus.com
On Wed, Jan 21, 2009 at 2:37 PM, David Baker
<[email protected]> wrote:
Hi
I'm having a problem making an RMI call using Spring DM when I
pass my
domain objects as method arguments. RMI calls work fine when I call
methods that don't take arguments, or ones that take Java types as
arguments. However when I pass my own domain objects as arguments, I
get the error shown at the end of this post. It appears to be a
classloading issue where the Spring classes can't find my domain
classes. My domain objects are stored in a single bundle with the
necessary packages exported in the manifest. All my bundles are
running in the same OSGi container.
As a test I added DynamicImport-Package: * to the manifests of the
Spring jars shipped with Spring DM (spring-beans, spring-context,
spring-core etc.), and this resolved the problem. I tested this with
both the 2.5.5 and 2.5.6.A versions of the jars, with the same
results
in both cases.
I also tested with version 2.5.6 of spring.jar, and the tests failed
unless I added DynamicImport-Package: * to its' manifest. When I ran
my tests using the org.springframework.bundle.spring_2.5.6 bundle
that
ships with Spring IDE, they worked. The manifest of that bundle
already has a DynamicImport-Package: * entry. Do the spring-beans,
spring-core jars etc need this line to be added too? (Or at least
some
fix to be made, as I know dynamic imports are not OSGi best
practice).
I know the stack trace below indicates I've no security manager
enabled, but this is not the source of the issue. The server is
attempting to download the class because it can't find it, but it
should be able to find it as it is exported by my domain bundle.
Has anyone come across this issue before? Is this a Spring issue, a
core OSGi issue, or is it an error on my behalf? In general there
seems to be very little on the web about OSGi + RMI, has anyone used
it and if so have you had any problems?
Thanks in advance for your help.
David
org.springframework.beans.factory.BeanCreationException: Error
creating bean wit
h name 'rmiTestClient' defined in URL [bundleentry://16/META-INF/
spring/bundle-c
ontext.xml]: Error setting property values; nested exception is
org.springframew
ork.beans.PropertyBatchUpdateException; nested
PropertyAccessExceptions (1) are:
PropertyAccessException 1:
org.springframework.beans.MethodInvocationException:
Property 'rmiTestService' threw exception; nested exception is
org.springframewo
rk.remoting.RemoteAccessException: Could not access remote service
[rmi://localh
ost:50042/rmiTestServiceRmi]; nested exception is
java.rmi.ServerException: Remo
teException occurred in server thread; nested exception is:
java.rmi.UnmarshalException: error unmarshalling arguments;
nested excep
tion is:
[B]java.lang.ClassNotFoundException:
rmitest.common.RmiTestBean [/B](no securit
y manager: RMI class loader disabled)
at
org
.springframework.beans.factory.support.AbstractAutowireCapableBean
Factory
.applyPropertyValues(AbstractAutowireCapableBeanFactory.java:1279)
at
org
.springframework.beans.factory.support.AbstractAutowireCapableBean
Factory.populateBean(AbstractAutowireCapableBeanFactory.java:1010)
at
org
.springframework.beans.factory.support.AbstractAutowireCapableBean
Factory.doCreateBean(AbstractAutowireCapableBeanFactory.java:472)
at
org
.springframework.beans.factory.support.AbstractAutowireCapableBean
Factory$1.run(AbstractAutowireCapableBeanFactory.java:409)
at java.security.AccessController.doPrivileged(Native Method)
at
org
.springframework.beans.factory.support.AbstractAutowireCapableBean
Factory.createBean(AbstractAutowireCapableBeanFactory.java:380)
at
org.springframework.beans.factory.support.AbstractBeanFactory
$1.getOb
ject(AbstractBeanFactory.java:264)
at
org
.springframework.beans.factory.support.DefaultSingletonBeanRegistr
y.getSingleton(DefaultSingletonBeanRegistry.java:222)
at
org
.springframework.beans.factory.support.AbstractBeanFactory.doGetBe
an(AbstractBeanFactory.java:261)
at
org
.springframework.beans.factory.support.AbstractBeanFactory.getBean
(AbstractBeanFactory.java:185)
at
org
.springframework.beans.factory.support.AbstractBeanFactory.getBean
(AbstractBeanFactory.java:164)
at
org
.springframework.beans.factory.support.DefaultListableBeanFactory.
preInstantiateSingletons(DefaultListableBeanFactory.java:429)
at
org
.springframework.context.support.AbstractApplicationContext.finish
BeanFactoryInitialization(AbstractApplicationContext.java:728)
at
org
.springframework.osgi.context.support.AbstractDelegatedExecutionAp
plicationContext
.completeRefresh(AbstractDelegatedExecutionApplicationContext.ja
va:288)
at
org
.springframework.osgi.extender.internal.dependencies.startup.Depen
dencyWaiterApplicationContextExecutor
$CompleteRefreshTask.run(DependencyWaiterAp
plicationContextExecutor.java:145)
at java.lang.Thread.run(Unknown Source)
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
--
-------------------------------------------------------------------------------------
Paremus Limited. Registered in England. Registration No. 4181472
Registered Office: 22-24 Broad Street, Wokingham, Berks RG40 1BA
Postal Address: 107-111 Fleet Street, London, EC4A 2AB
The information transmitted is intended only for the person(s) or
entity to which it is addressed and may contain confidential and/or
privileged material. Any review, retransmission, dissemination or
other use of, or taking of any action in reliance upon, this
information by persons or entities other than the intended recipient
is prohibited.
If you received this in error, please contact the sender and delete
the material from any computer.
-------------------------------------------------------------------------------------
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
