Jeff
Peter Kriens wrote:
The big issue I have is if OSGi needs to do anything in this area? The APIs are available to solve this problem (as you show). As far as I can see, any company can make an RMI product that solves this problem? What kind of specification would be useful here? On the sending site you need to annotate with the version of the package (or bsn) that contains the class. On the receiving site you need to take this information and use the right bundle to load the class.So would it suffice to define the annotation format? Kind regards, Peter Kriens On 23 jan 2009, at 12:49, David Savage wrote:Seems this has started a political storm...ah well should be fun to watch ;) I'm gonna concentrate on the technical issues and not get involved... Just a couple of clarifications/comments following on my previous mail: * The work around part of the solution we provide is only required if a class being sent across the wire is not directly imported by the client. i.e. if the client bundle and the server bundle communicate via an API bundle and the data objects in the API are defined as interfaces. In this case it is very likely for the class that implements the data object to be outside of the clients classpath scope of visibility - hence the need to magically get the classes from elsewhere - we use codebases - OSGi currently has no defined standard. * The work around may not be necessary in your architecture if you use a simple bundle structure. If this is the case you have no problems. However if it is needed we'll obviously do our best to concurrently support our existing solution and the OSGi specification when it becomes available. So in the long term you wouldn't be locking yourself into our model - though I can't rule out some migration steps when you do decide to switch to the OSGi standard. Our goal is that you would like our solution on it's own merits vs lock in etc... * There is a webinar on our website about using Spring-DM with Infiniflow "Distributing and Managing Spring Dynamic Modulesfor OSGi Services with Infiniflow" and can be found at:http://www.paremus.com/downloads/downloads_presentations.html#ddwebinars.This may save you some time in your evaluation etc. Regards, DaveOn Thu, Jan 22, 2009 at 10:14 AM, David Baker <[email protected]> wrote: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 DavidOn 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.comOn Wed, Jan 21, 2009 at 2:37 PM, David Baker <[email protected]> wrote:HiI'm having a problem making an RMI call using Spring DM when I pass mydomain 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 withboth the 2.5.5 and 2.5.6.A versions of the jars, with the same resultsin 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 ranmy tests using the org.springframework.bundle.spring_2.5.6 bundle thatships 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. Davidorg.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: RemoteException occurred in server thread; nested exception is:java.rmi.UnmarshalException: error unmarshalling arguments; nested exception 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.AbstractAutowireCapableBeanFactory.populateBean(AbstractAutowireCapableBeanFactory.java:1010)at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:472)at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory$1.run(AbstractAutowireCapableBeanFactory.java:409) at java.security.AccessController.doPrivileged(Native Method)at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:380)at org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:264)at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:222)at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(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.finishBeanFactoryInitialization(AbstractApplicationContext.java:728)at org.springframework.osgi.context.support.AbstractDelegatedExecutionAp plicationContext.completeRefresh(AbstractDelegatedExecutionApplicationContext.java:288)at org.springframework.osgi.extender.internal.dependencies.startup.Depen dencyWaiterApplicationContextExecutor$CompleteRefreshTask.run(DependencyWaiterApplicationContextExecutor.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---------------------------------------------------------------------------------------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
_______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
