RE: [ecf-dev] Distributed OSGi with ECF

["Rellermeyer Jan Simon" <rellermeyer@xxxxxxxxxxx>]

My apologies, I have a close paper deadline and will not be able to look at this in the next days. 

Cheers, 

Jan.


------------------------------------------------------------
MSc Jan S. Rellermeyer, Systems Group, Department of Computer Science, ETH Zurich 
IFW B 47.1, Haldeneggsteig 4, CH-8092 Zürich, Switzerland
http://www.systems.ethz.ch
------------------------------------------------------------ 



> -----Original Message-----
> From: Scott Lewis [mailto:slewis@xxxxxxxxxxxxxxxxx]
> Sent: Freitag, 2. Oktober 2009 16:58
> To: Eclipse Communication Framework (ECF) developer mailing list.;
> Rellermeyer Jan Simon
> Subject: Re: [ecf-dev] Distributed OSGi with ECF
> 
> Hi Eugen,
> 
> Thanks for the answers, at this point I'm going to have to ask Jan
> Rellermeyer to comment on these r-OSGi subleties.
> 
> Scott
> 
> Eugen Reiswich wrote:
> > Oh, forgot to mention I'm using ECF 3.0.1.v20090916-2238
> >
> > Cheers,
> > Eugen
> >
> > Am Oct 2, 2009 um 14:51  schrieb Scott Lewis:
> >
> >> Hi Eugen,
> >>
> >> Eugen Reiswich wrote:
> >>> Hi folks,
> >>>
> >>> I'm just trying to get familiar with Distributed OSGi with ECF. I
> >>> followed the instructions here:
> >>> http://bryanhunt.wordpress.com/2009/06/20/remote-declarative-osgi-
> services/
> >>>
> >>>
> >>> But when I try to launch my example I get the following error:
> >>> java.lang.LinkageError: loader constraint violation: loader
> >>> (instance of
> >>> org/eclipse/osgi/internal/baseadaptor/DefaultClassLoader)
> previously
> >>> initiated loading for a different type with name
> >>> "de/c1wps/winterschool/domain/kunde/material/Kunde"
> >>> at java.lang.ClassLoader.defineClass1(Native Method)
> >>> at java.lang.ClassLoader.defineClass(ClassLoader.java:700)
> >>> at
> >>>
> org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.defineClass(De
> faultClassLoader.java:183)
> >>>
> >>> at
> >>>
> org.eclipse.osgi.baseadaptor.loader.ClasspathManager.defineClass(Classp
> athManager.java:576)
> >>>
> >>> at
> >>>
> org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findClassImpl(Clas
> spathManager.java:546)
> >>>
> >>> at
> >>>
> org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClassImpl
> (ClasspathManager.java:477)
> >>>
> >>> at
> >>>
> org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClass_Loc
> kClassLoader(ClasspathManager.java:465)
> >>>
> >>> at
> >>>
> org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClass(Cla
> sspathManager.java:445)
> >>>
> >>> at
> >>>
> org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.findLocalClass
> (DefaultClassLoader.java:211)
> >>>
> >>> at
> >>>
> org.eclipse.osgi.internal.loader.BundleLoader.findLocalClass(BundleLoad
> er.java:381)
> >>>
> >>> at
> >>>
> org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleL
> oader.java:457)
> >>>
> >>> at
> >>>
> org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.ja
> va:410)
> >>>
> >>> at
> >>>
> org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.ja
> va:398)
> >>>
> >>> at
> >>>
> org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.loadClass(Defa
> ultClassLoader.java:105)
> >>>
> >>> at java.lang.ClassLoader.loadClass(ClassLoader.java:254)
> >>> at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:399)
> >>> at
> >>>
> proxy.fbipcahacoinformatikouni_hamburgode_jcicfc.de.c1wps.winterschool.
> domain.kunde.service.IKundenServiceImpl.erzeugeKunde(Unknown
> >>> Source)
> >>> at
> >>>
> de.c1wps.winterschool.kundekontoverwalter.KundenVerwalter._erstelleKund
> e(KundenVerwalter.java:26)
> >>>
> >>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> >>> at
> >>>
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.ja
> va:39)
> >>>
> >>> at
> >>>
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccesso
> rImpl.java:25)
> >>>
> >>> at java.lang.reflect.Method.invoke(Method.java:597)
> >>> at
> >>>
> org.eclipse.osgi.framework.internal.core.FrameworkCommandInterpreter.ex
> ecute(FrameworkCommandInterpreter.java:155)
> >>>
> >>> at
> >>>
> org.eclipse.osgi.framework.internal.core.FrameworkConsole.docommand(Fra
> meworkConsole.java:303)
> >>>
> >>> at
> >>>
> org.eclipse.osgi.framework.internal.core.FrameworkConsole.console(Frame
> workConsole.java:288)
> >>>
> >>> at
> >>>
> org.eclipse.osgi.framework.internal.core.FrameworkConsole.run(Framework
> Console.java:224)
> >>>
> >>> at java.lang.Thread.run(Thread.java:637)
> >>>
> >>>
> >>> I've already double checked that it's not the same error described
> >>> here:
> >>>
> http://dev.eclipse.org/newslists/news.eclipse.technology.ecf/msg01329.h
> tml
> >>>
> >>>
> >>> Everything seem to work fine when I use primitive data types as
> >>> service interface parameters. By when I change the parameter types
> >>> to more complex one the above exception is thrown.
> >>
> >> A question:  which distribution provider are you using?  (i.e.
> >> r-osgi, ecf generic, jms...something else)?   Also...what version of
> >> ECF are you currently using?
> >>
> >> And are the service types in exported packages?  In general, the
> >> types of the service interface parameters have to be in exported
> >> packages so that the distribution provider can dynamically load the
> >> class during parameter marshalling/unmarshalling.  And finally...are
> >> your service types declared as implementing Serializable?
> >>
> >> The classloading error you are getting:
> >>
> >> java.lang.LinkageError: loader constraint violation: loader
> (instance
> >> of org/eclipse/osgi/internal/baseadaptor/DefaultClassLoader)
> >> previously initiated loading for a different type with name
> >> "de/c1wps/winterschool/domain/kunde/material/Kunde"
> >>
> >> makes me suspect that the service parameter types *are* exported,
> but
> >> that somehow you have more than one copy of the given class
> >> (de/c1wps/winterschool/domain/kunde/material/Kunde) in your
> >> runtime...so when the distribution provider goes to load a class
> with
> >> DynamicImport-Package, it finds the wrong version/copy of
> >> de/c1wps/winterschool/domain/kunde/material/Kunde...since perhaps
> >> there are two (or more) available to the classloader (resulting in
> >> this LinkageError).  If this is true (that there is more than one
> >> copy/version of this service class in your runtime...perhaps in more
> >> than one bundle), then this duplication should be eliminated.
> >>
> >> This may be some other issue/bug with the provider, however...e.g.
> >> something associated with the service parameter type not being
> >> Serializable...so please do let know which one is being used and
> >> whether the service types are Serializable.
> >>
> >> Scott
> >>
> >> _______________________________________________
> >> ecf-dev mailing list
> >> ecf-dev@xxxxxxxxxxx
> >> https://dev.eclipse.org/mailman/listinfo/ecf-dev
> >
> > _______________________________________________
> > ecf-dev mailing list
> > ecf-dev@xxxxxxxxxxx
> > https://dev.eclipse.org/mailman/listinfo/ecf-dev