Home » Eclipse Projects » Equinox » Classloading and Serialization
| Classloading and Serialization [message #46579] |
Fri, 04 February 2005 04:59  |
Eclipse User |
|
|
|
Originally posted by: pnehrer.freeshell.org
Hi,
this post is related to a previous one by Scott Lewis (12/15/04), which
didn't generate any discussion, so I'm trying again.
First of all, has anyone attempted to use inter-plugin Java object
serialization? We (the ECF project) face the following challenge:
1. we have a plugin which facilitates inter-process communication
2. we have client plugin(s) which use that communication plugin to pass
around messages (arbitrary serializable objects)
The communication plugin is responsible for (de)serialization of client
messages, which creates an inverse runtime dependency to the client
plugins. Presently, we adress this by using the OSGi Export-Package
directive in client plugins (to expose the message classes) and the
DynamicImport-Package: * in the communication plugin, which makes the
client-exported packages visible to the plugin at runtime.
This approach falls short when the client plugin needs to include a
third-party object (e.g., an EMF/SDO data graph) in its messages --
these third-party objects fail to deserialize as they are not exported
by their own plugins. Re-exporting them from the client plugin doesn't
seem to work.
Is there something the Platform runtime can do to help with inter-plugin
serialization? A brief investigation suggests that the
EclipseClassLoader could expose the id of the bundle to which it
belongs. Then, our communication plugin could use a special
ObjectInput/OutputStream, which would:
1. store the bundle id for each class whose instances it serializes (in
the class descriptor)
2. load the class using the appropriate bundle, whose id is restored
from the serialized class descriptor
The lowest-impact alternative would be for us to push serialization into
client plugins, but that puts a heavy constraint on our design (we
think). Besides, the approach proposed above would be generic enough to
be used by whoever needs it (anyone?)
Any comments and/or suggestions would be appreciated. Thanks!
--Peter
|
|
|
| Re: Classloading and Serialization [message #46604 is a reply to message #46579] |
Fri, 04 February 2005 14:05  |
| Eclipse User |
|
|
|
Originally posted by: chaves.inf.no.ufsc.spam.br
The fix for bug:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=65438
should give you all you need. Beware that if a new version of an
existing bundle is installed, it will have a different (numeric) id.
Unless you are talking about symbolic names (a.k.a. plug-in ids). In
this case, note that currently OSGi bundles do not declare symbolic names.
Rafael
Peter Nehrer wrote:
> Hi,
>
> this post is related to a previous one by Scott Lewis (12/15/04), which
> didn't generate any discussion, so I'm trying again.
>
> First of all, has anyone attempted to use inter-plugin Java object
> serialization? We (the ECF project) face the following challenge:
>
> 1. we have a plugin which facilitates inter-process communication
>
> 2. we have client plugin(s) which use that communication plugin to pass
> around messages (arbitrary serializable objects)
>
> The communication plugin is responsible for (de)serialization of client
> messages, which creates an inverse runtime dependency to the client
> plugins. Presently, we adress this by using the OSGi Export-Package
> directive in client plugins (to expose the message classes) and the
> DynamicImport-Package: * in the communication plugin, which makes the
> client-exported packages visible to the plugin at runtime.
>
> This approach falls short when the client plugin needs to include a
> third-party object (e.g., an EMF/SDO data graph) in its messages --
> these third-party objects fail to deserialize as they are not exported
> by their own plugins. Re-exporting them from the client plugin doesn't
> seem to work.
>
> Is there something the Platform runtime can do to help with inter-plugin
> serialization? A brief investigation suggests that the
> EclipseClassLoader could expose the id of the bundle to which it
> belongs. Then, our communication plugin could use a special
> ObjectInput/OutputStream, which would:
>
> 1. store the bundle id for each class whose instances it serializes (in
> the class descriptor)
>
> 2. load the class using the appropriate bundle, whose id is restored
> from the serialized class descriptor
>
> The lowest-impact alternative would be for us to push serialization into
> client plugins, but that puts a heavy constraint on our design (we
> think). Besides, the approach proposed above would be generic enough to
> be used by whoever needs it (anyone?)
>
> Any comments and/or suggestions would be appreciated. Thanks!
>
> --Peter
|
|
|
| Re: Classloading and Serialization [message #46628 is a reply to message #46604] |
Fri, 04 February 2005 14:08 |
| Eclipse User |
|
|
|
Originally posted by: chaves.inf.no.ufsc.spam.br
To be clear: I meant to say "currently *plain* OSGi bundles" (as opposed
to Eclipse plug-ins).
Rafael Chaves wrote:
> In
> this case, note that currently OSGi bundles do not declare symbolic names.
|
|
|
| Re: Classloading and Serialization [message #46649 is a reply to message #46604] |
Fri, 04 February 2005 14:26 |
| Eclipse User |
|
|
|
Originally posted by: pnehrer.freeshell.org
Rafael,
thanks for the reply -- that's great! I looked at the proposed API in
the last comment and that is exactly what we need. Re: bundle id -- yes,
I was referring to the symbolic name, so I guess this restricts the
solution to plugin bundles... I'll start with that.
--Peter
Rafael Chaves wrote:
> The fix for bug:
>
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=65438
>
> should give you all you need. Beware that if a new version of an
> existing bundle is installed, it will have a different (numeric) id.
> Unless you are talking about symbolic names (a.k.a. plug-in ids). In
> this case, note that currently OSGi bundles do not declare symbolic names.
>
> Rafael
|
|
|
| Re: Classloading and Serialization [message #46668 is a reply to message #46604] |
Fri, 04 February 2005 14:27 |
| Eclipse User |
|
|
|
Originally posted by: pnehrer.freeshell.org
Rafael,
thanks for the reply -- that's great! I looked at the proposed API in
the last comment and that is exactly what we need. Re: bundle id -- yes,
I was referring to the symbolic name, so I guess this restricts the
solution to plugin bundles... I'll start with that.
--Peter
Rafael Chaves wrote:
> The fix for bug:
>
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=65438
>
> should give you all you need. Beware that if a new version of an
> existing bundle is installed, it will have a different (numeric) id.
> Unless you are talking about symbolic names (a.k.a. plug-in ids). In
> this case, note that currently OSGi bundles do not declare symbolic names.
>
> Rafael
|
|
|
| Re: Classloading and Serialization [message #46679 is a reply to message #46668] |
Fri, 04 February 2005 17:22 |
| Eclipse User |
|
|
|
Originally posted by: slewis.composent.com
Hi Rafael,
Where/when will this API addition appear?
Thanks,
Scott
Peter Nehrer wrote:
> Rafael,
>
> thanks for the reply -- that's great! I looked at the proposed API in
> the last comment and that is exactly what we need. Re: bundle id -- yes,
> I was referring to the symbolic name, so I guess this restricts the
> solution to plugin bundles... I'll start with that.
>
> --Peter
>
> Rafael Chaves wrote:
>
>> The fix for bug:
>>
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=65438
>>
>> should give you all you need. Beware that if a new version of an
>> existing bundle is installed, it will have a different (numeric) id.
>> Unless you are talking about symbolic names (a.k.a. plug-in ids). In
>> this case, note that currently OSGi bundles do not declare symbolic
>> names.
>>
>> Rafael
|
|
|
| Re: Classloading and Serialization [message #46712 is a reply to message #46628] |
Fri, 04 February 2005 23:07 |
| Eclipse User |
|
|
|
Originally posted by: slewis.composent.com
Hi Rafael,
Question about this...we would like to build a mechanism that is able to
run on servers that may or may not be written to run under the eclipse
runtime. So we would like to use a guaranteed-to-be-globally-unique
symbolic name for the bundle...but something that is supported by OSGI
alone and not require the eclipse platform runtime...if such a thing
exists or will exist.
I noticed that the Bundle interface declares 'getSymbolicName' which is
marked as 'EXPERIMENTAL'. Is this supported in non-eclipse OSGI
runtimes? Please point me to relevant OSGI spec if that's where the
definitive answer lives.
Thanks,
Scott
Rafael Chaves wrote:
> To be clear: I meant to say "currently *plain* OSGi bundles" (as opposed
> to Eclipse plug-ins).
>
> Rafael Chaves wrote:
>
>> In this case, note that currently OSGi bundles do not declare symbolic
>> names.
|
|
|
| Re: Classloading and Serialization [message #46725 is a reply to message #46679] |
Sat, 05 February 2005 00:48 |
| Eclipse User |
|
|
|
Originally posted by: chaves.inf.no.ufsc.spam.br
Scott Lewis wrote:
> Where/when will this API addition appear?
It should be in for i20050202. Look for the PackageAdmin service
interface defined in org.eclipse.osgi.
Rafael
|
|
|
| Re: Classloading and Serialization [message #46762 is a reply to message #46712] |
Sat, 05 February 2005 00:56 |
| Eclipse User |
|
|
|
Originally posted by: chaves.inf.no.ufsc.spam.br
Symbolic names were added in the context of moving Eclipse to a OSGi
based runtime. I believe they will be part of the OSGi spec version 4.0
(still to be released, available only to OSGi members before released).
So no, today other OSGi implementations do not support symbolic names.
Other options you have:
- the numeric id (see Bundle.getBundleId())
- the bundle location (see BundleContext.installBundle(String)), which a
URL or some string a framework implementation understands
As far as I know, they uniquely identify a bundle in a system but not
accross systems.
Rafael
Scott Lewis wrote:
> Hi Rafael,
>
> Question about this...we would like to build a mechanism that is able to
> run on servers that may or may not be written to run under the eclipse
> runtime. So we would like to use a guaranteed-to-be-globally-unique
> symbolic name for the bundle...but something that is supported by OSGI
> alone and not require the eclipse platform runtime...if such a thing
> exists or will exist.
>
> I noticed that the Bundle interface declares 'getSymbolicName' which is
> marked as 'EXPERIMENTAL'. Is this supported in non-eclipse OSGI
> runtimes? Please point me to relevant OSGI spec if that's where the
> definitive answer lives.
>
> Thanks,
>
> Scott
>
> Rafael Chaves wrote:
>
>> To be clear: I meant to say "currently *plain* OSGi bundles" (as
>> opposed to Eclipse plug-ins).
>>
>> Rafael Chaves wrote:
>>
>>> In this case, note that currently OSGi bundles do not declare
>>> symbolic names.
|
|
|
| Re: Classloading and Serialization [message #47641 is a reply to message #46762] |
Wed, 20 April 2005 14:50 |
 Joel Kamentz
Messages: 30
Registered: July 2009 |
Member |
|
|
What's the difference (within OSGi) between Bundle-Name and
Bundle-SymbolicName? To me, it seems like they are the same concept (and I
don't know why Eclipse added Bundle-SymbolicName). According to OSGi v3,
Bundle-Name doesn't contain spaces. I would expect it to be a unique
identifier. There is a separate Bundle-Description for human-readable
stuff. I would expect Bundle-Name to map to plugin id not plugin name. So,
why can't Bundle-Name be treated as a textual identifier?? Why do we (or do
we) need both Bundle-Name and Bundle-SymbolicName?
Joel
"Rafael Chaves" <chaves@inf.no.ufsc.spam.br> wrote in message
news:cu15jq$oa0$1@www.eclipse.org...
> Symbolic names were added in the context of moving Eclipse to a OSGi based
> runtime. I believe they will be part of the OSGi spec version 4.0 (still
> to be released, available only to OSGi members before released).
>
> So no, today other OSGi implementations do not support symbolic names.
> Other options you have:
> - the numeric id (see Bundle.getBundleId())
> - the bundle location (see BundleContext.installBundle(String)), which a
> URL or some string a framework implementation understands
>
> As far as I know, they uniquely identify a bundle in a system but not
> accross systems.
>
> Rafael
>
> Scott Lewis wrote:
>> Hi Rafael,
>>
>> Question about this...we would like to build a mechanism that is able to
>> run on servers that may or may not be written to run under the eclipse
>> runtime. So we would like to use a guaranteed-to-be-globally-unique
>> symbolic name for the bundle...but something that is supported by OSGI
>> alone and not require the eclipse platform runtime...if such a thing
>> exists or will exist.
>>
>> I noticed that the Bundle interface declares 'getSymbolicName' which is
>> marked as 'EXPERIMENTAL'. Is this supported in non-eclipse OSGI
>> runtimes? Please point me to relevant OSGI spec if that's where the
>> definitive answer lives.
>>
>> Thanks,
>>
>> Scott
>>
>> Rafael Chaves wrote:
>>
>>> To be clear: I meant to say "currently *plain* OSGi bundles" (as opposed
>>> to Eclipse plug-ins).
>>>
>>> Rafael Chaves wrote:
>>>
>>>> In this case, note that currently OSGi bundles do not declare symbolic
>>>> names.
|
|
|
| Re: Classloading and Serialization [message #47672 is a reply to message #47641] |
Wed, 20 April 2005 18:32 |
| Eclipse User |
|
|
|
Originally posted by: chaves.inf.no.ufsc.spam.br
We wanted something we could map Eclipse plug-in identifiers into, and
Bundle-Name was too weakly specified to be adopted. Some differences I
remember:
- plug-in identifier rules are more strict (w.r.t. characters accepted)
than bundle names;
- bundle names can change during an update, whereas plug-in identifiers
cannot
Basically, instead of proposing changing the semantics of an existing
header, we opted for adopting a new one for which new rules could be
defined.
Rafael
Joel Kamentz wrote:
> What's the difference (within OSGi) between Bundle-Name and
> Bundle-SymbolicName? To me, it seems like they are the same concept (and I
> don't know why Eclipse added Bundle-SymbolicName). According to OSGi v3,
> Bundle-Name doesn't contain spaces. I would expect it to be a unique
> identifier. There is a separate Bundle-Description for human-readable
> stuff. I would expect Bundle-Name to map to plugin id not plugin name. So,
> why can't Bundle-Name be treated as a textual identifier?? Why do we (or do
> we) need both Bundle-Name and Bundle-SymbolicName?
>
> Joel
|
|
|
Goto Forum:
Current Time: Fri Apr 19 22:33:24 GMT 2024
Powered by FUDForum. Page generated in 0.04350 seconds |
] 
Search
Help
Register
Login
Home
