-----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
