Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 367689 - DuplicateBundleException is not serializable
Summary: DuplicateBundleException is not serializable
Status: RESOLVED FIXED
Alias: None
Product: Equinox
Classification: Eclipse Project
Component: Framework (show other bugs)
Version: unspecified   Edit
Hardware: PC Linux
: P3 normal (vote)
Target Milestone: Juno M5   Edit
Assignee: Thomas Watson CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-01-01 10:26 EST by Harald Wellmann CLA
Modified: 2012-01-18 16:06 EST (History)
1 user (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Harald Wellmann CLA 2012-01-01 10:26:48 EST 
Build Identifier: 3.7.0.v20110613

DuplicateBundleException implements Serializable (inherited from Throwable) but is not serializable, since the "duplicate" member of type Bundle (implemented by BundleHost) is not.

I ran into this problem when using a Framework via a thin RMI wrapper. The remote caller only receives a NotSerializableException for BundleHost and never sees the DuplicateBundleException indicating the real cause.

Reproducible: Always

Steps to Reproduce:
Install the same bundle twice with different locations using an RMI wrapper.
Comment 1 Thomas Watson CLA 2012-01-06 14:23:04 EST 
There are a few implementers of org.eclipse.osgi.framework.adaptor.StatusException that all have a similar issue.  Looking at them I am thinking the most simple thing to do is to make the status object transient for all the cases:

org.eclipse.core.runtime.internal.adaptor.EclipseLazyStarter.TerminatingClassNotFoundException

org.eclipse.osgi.framework.internal.core.AbstractBundle.BundleStatusException

org.eclipse.osgi.framework.internal.core.Framework.DuplicateBundleException

In the TerminatingClassNotFoundException case it likely doesn't need to be transient, because the status object should always be another Throwable which is serializable.

The status object is really only important in the exact context the exception was thrown.  Even if we could serialize the status object it likely would have little meaning on the other end where you de-serialize it.