Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 367689

Summary: DuplicateBundleException is not serializable
Product: [Eclipse Project] Equinox Reporter: Harald Wellmann <hwellmann.de>
Component: FrameworkAssignee: Thomas Watson <tjwatson>
Status: RESOLVED FIXED QA Contact:
Severity: normal    
Priority: P3 CC: tjwatson
Version: unspecified   
Target Milestone: Juno M5   
Hardware: PC   
OS: Linux   
Whiteboard:

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.