| LinkageError / IncompatibleClassChangeError [message #47362] |
Tue, 29 March 2005 20:47  |
Eclipse User |
|
|
|
Originally posted by: tai.qnamic.com
My problem in detail is:
- plugin c depends on b; and b on a (a the is the base-plugin-project)
- The c-class (from the c-plugin) implements an interface from the a-plugin
- The c-class has a method getMethodReturningABaseInterface()
- I pass a c-Object to a a static helper-class (from a-plugin)
- The a-Object calls c.getMethodReturningABaseInterface().
The interface is of course ONLY stored in the a-project! I checked all
existing jars in all projects to make sure there's no older version of that
interface. But I still get the LinkageError / IncompatibleClassChangeError!
I use jdk 1.4.2_07... And the interface is also not in the jars within the
jdk and jdk-ext!
Is it possible that the c-Object is another version in the c-"environment"
compared to the a-"environment" (as far as I know osgi encapsulates its
bundles in their own environment with a dynamic classloader...)?
I have also implemented a special Eclipse-Classloader to load classes from
the c-project in the a-project. But I don't think the problem correlates
with my classloader...
I've research for eclipse-bugs and found somethin about invocation and
compilation-problems:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=80780
The problem came from the invocation of the annotation.... It requires an
invokeinterface bytecode and not an invokevirtual.
https://bugs.eclipse.org/bugs/show_bug.cgi?id=45441
So we finally figured what changed between 3.0M3 and 3.0M4: the Java
Compiler
options changed to having 1.4 compliance as the default for generated class
files. (We found this out through the circuitous route of inspecting the
class
file attributes of an M4 compile vs a working command-line one.
But this doesn't give me any clue for my problem.
Regards,
Tai
|
|
|
| Re: LinkageError / IncompatibleClassChangeError [message #47391 is a reply to message #47362] |
Tue, 29 March 2005 22:53  |
| Eclipse User |
|
|
|
Originally posted by: chaves.inf.no.ufsc.spam.br
eclipse wrote:
>
> I have also implemented a special Eclipse-Classloader to load classes from
> the c-project in the a-project. But I don't think the problem correlates
> with my classloader...
>
Can you provide your classloader here? From where is it called?
Have you tried exporting the package that contains c-Class (let's say:
package_c) and using "DynamicImport-Package: package_c;" in plugin a's
manifest?
As an unrelated note: the architecture you describe looks a lot like
what Eclipse runtime provides with org.eclipse.core.runtime.IAdaptable.
Not knowing your requirements, I cannot tell for sure, but it seems you
may not have to create these mutual dependencies.
Rafael
|
|
|
| Re: LinkageError / IncompatibleClassChangeError [message #47421 is a reply to message #47391] |
Wed, 30 March 2005 09:32 |
| Eclipse User |
|
|
|
Originally posted by: tai.qnamic.com
The classloader is pretty simple. I use the property osgi.adaptor to create
(a factory which then creates) my classloader.
My classloader extends the classpath (provided by the property
PROPERTY_QNAMIC_CLASSPATH) by overiding the method buildClasspath:
public class QnamicClassLoader extends EclipseClassLoader {
protected ClasspathEntry[] buildClasspath(String[] classpath,
AbstractBundleData bundledata, ProtectionDomain domain) {
ClasspathEntry[] entries = super.buildClasspath(classpath,
bundledata,
domain);
String qnamicClasspath =
System.getProperty(PROPERTY_QNAMIC_CLASSPATH);
if (qnamicClasspath != null) {
StringTokenizer token = new StringTokenizer(qnamicClasspath,
File.pathSeparator);
while (token.hasMoreElements()) {
String path = token.nextToken();
File file = new File(path);
BundleFile bundlefile = null;
try {
bundlefile =
hostdata.getAdaptor().createBundleFile(file,
bundledata);
} catch (IOException e) {
System.out.println("Cannot create classpath entry " +
file.getPath());
e.printStackTrace();
}
if (bundlefile != null) {
ClasspathEntry[] newEntries = new
ClasspathEntry[entries.length + 1];
ClasspathEntry newEntry =
createClassPathEntry(bundlefile, domain);
System.arraycopy(entries, 0, newEntries, 1,
entries.length);
newEntries[entries.length] = newEntry;
return newEntries;
}
}
}
return entries;
}
}
Tai
"Rafael Chaves" <chaves@inf.no.ufsc.spam.br> wrote in message
news:d2cmb4$t9p$1@news.eclipse.org...
> eclipse wrote:
> >
> > I have also implemented a special Eclipse-Classloader to load classes
from
> > the c-project in the a-project. But I don't think the problem correlates
> > with my classloader...
> >
>
> Can you provide your classloader here? From where is it called?
>
> Have you tried exporting the package that contains c-Class (let's say:
> package_c) and using "DynamicImport-Package: package_c;" in plugin a's
> manifest?
>
> As an unrelated note: the architecture you describe looks a lot like
> what Eclipse runtime provides with org.eclipse.core.runtime.IAdaptable.
> Not knowing your requirements, I cannot tell for sure, but it seems you
> may not have to create these mutual dependencies.
>
> Rafael
|
|
|
| Tried using Manifest.mf [message #47451 is a reply to message #47391] |
Wed, 30 March 2005 10:07 |
| Eclipse User |
|
|
|
Originally posted by: tai.qnamic.com
Hi Rafael,
thanks for the support. I also tried to add in my a_project's manifest the
entry:
DynamicImport-Package: *
The Problem is that a_project might have access to the b_ and c_project.
Reasons for that are:
- a basereader reads an xml-file with defined classes from c_project
- RMI: an instance needs to make remotable via
UnicastRemoteObject.exportObject (creates an stub-instance. and the stub may
rely in c_project!)
Because a_project might have access to all classes I have to export all
classes in the b_ and c_project's manifest. Is there a simple way to export
all classes like "Export-Package: *" instead of declaring all packages
"Export-Package: package1, package2,..."?
Nevertheless I tried editing the manifest and now I get a
"java.lang.NoClassDefFoundError: org/eclipse/core/runtime/IPath". That's
weird because I have the required plugin org.eclipse.core.runtime?! Probably
my eclipse projects are dirty ;-)
Tai
|
|
|
| Re: Tried using Manifest.mf [message #47481 is a reply to message #47451] |
Wed, 30 March 2005 20:56 |
| Eclipse User |
|
|
|
Originally posted by: chaves.inf.no.ufsc.spam.br
In recent builds, the plug-in manifest editor has a nice GUI for
exporting packages. BTW, there is no support in OSGi for
"Export-package: *".
For DynamicImport-Package to work, the packages in plugin B and C have
to be exported (!= provided, which has been recently deprecated).
Note that for performance reasons, "DynamicImport-Package: *" is not
recommended. If there is no other choice, at least a more restricted
package name pattern should be used.
Rafael
eclipse wrote:
> Hi Rafael,
>
> thanks for the support. I also tried to add in my a_project's manifest the
> entry:
>
> DynamicImport-Package: *
>
> The Problem is that a_project might have access to the b_ and c_project.
> Reasons for that are:
>
> - a basereader reads an xml-file with defined classes from c_project
> - RMI: an instance needs to make remotable via
> UnicastRemoteObject.exportObject (creates an stub-instance. and the stub may
> rely in c_project!)
>
> Because a_project might have access to all classes I have to export all
> classes in the b_ and c_project's manifest. Is there a simple way to export
> all classes like "Export-Package: *" instead of declaring all packages
> "Export-Package: package1, package2,..."?
>
> Nevertheless I tried editing the manifest and now I get a
> "java.lang.NoClassDefFoundError: org/eclipse/core/runtime/IPath". That's
> weird because I have the required plugin org.eclipse.core.runtime?! Probably
> my eclipse projects are dirty ;-)
>
> Tai
>
>
|
|
|
| Re: Tried using Manifest.mf [message #47511 is a reply to message #47481] |
Thu, 31 March 2005 09:00 |
| Eclipse User |
|
|
|
Originally posted by: tai.qnamic.com
"Rafael Chaves" <chaves@inf.no.ufsc.spam.br> wrote in message
news:d2f3su$93v$1@news.eclipse.org...
> In recent builds, the plug-in manifest editor has a nice GUI for
> exporting packages. BTW, there is no support in OSGi for
> "Export-package: *".
>
Are talking about 3.1? I am using 3.0.2 and I can't find the GUI. Where
exactly is it? I can see only the tabs "Overview", "Dependencies" ...
Tai
|
|
|
| Re: Tried using Manifest.mf [message #47541 is a reply to message #47511] |
Thu, 31 March 2005 17:07 |
| Eclipse User |
|
|
|
Originally posted by: chaves.inf.no.ufsc.spam.br
Yes, that is for recent integration builds (post M5). In 3.0.1, you will
be able to use PDE UI to add provided packages, but provided !=
exported, so a [Dynamic]Import-package could only see Export-Packages.
The UI is in the Runtime tab.
eclipse wrote:
> "Rafael Chaves" <chaves@inf.no.ufsc.spam.br> wrote in message
> news:d2f3su$93v$1@news.eclipse.org...
>
>>In recent builds, the plug-in manifest editor has a nice GUI for
>>exporting packages. BTW, there is no support in OSGi for
>>"Export-package: *".
>>
>
>
> Are talking about 3.1? I am using 3.0.2 and I can't find the GUI. Where
> exactly is it? I can see only the tabs "Overview", "Dependencies" ...
>
> Tai
>
>
|
|
|
Powered by
FUDForum. Page generated in 0.01892 seconds
] 
Search
Help
Register
Login
Home
