Hi Dave Thanks a lot for your reply. I'll try out Newton in the next few days. The first sentence of your reply ties in with a forum posting I found from February of last year at http://markmail.org/message/qt2n7pcvlq2pcijy in which Hal Hildebrand says:
"There is a well known issue with RMI downloading of classes with OSGi which is being worked on in the OSGi core platform group" Can anyone confirm that the group is working on this issue, and if so what the latest is with it? If we knew that the problem is going to be resolved, we would consider going with the workaround solution until then, as the timelines on our project are tight. Thanks David On Thu, Jan 22, 2009 at 9:21 AM, David Savage <[email protected]> wrote: > 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 > _______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
