You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by "Hawkins, Joel" <Jo...@compuware.com> on 2006/11/15 20:37:06 UTC
Bundles and OSGi
Moving a private conversation about OSGi support to the mailing list, in
case anyone's interested.
-----Original Message-----
From: Wengatz, Nicole [mailto:nicole.wengatz@siemens.com]
Sent: Wednesday, November 15, 2006 10:23 AM
To: Hawkins, Joel
Cc: Jim Marino; Wengatz, Nicole; Jasny, Robert
Subject: RE: Bundles and OSGi
Hi Joel,
I'm not completely sure what an extension could contain. My
understanding is that an extension could
be a simple JAR wrapped as bundle as discussed yesterday (e.g. Spring,
Axis), but also a binding like
the OSGi-Binding.
If I have a look to the 'old' prototype (the one you sent me) we have
the tuscany.osgi.core bundle and the
tuscany-binding-osgi bundle. My understanding was that the
tuscany-binding-osgi bundle is an extension?
The tuscany.osgi.core bundle requires classes from the
tuscany-binding-osgi to load SCDLs or SCA
components with configured OSGi-Binding and the tuscany-binding-osgi
requires classes from
tuscany.osgi.core.
The tuscany.osgi.core does not know in advance (e.g. at deploy time)
which extensions
e.g. bindings will be available. Therefore I thought the dynamic import
is required between core and extensions.
Am I missing something?
Between extensions I thought we could use standard import/export. Or do
we really have the case that an
extension bundle does not know which packages are required?
> Like compile-time type checking vs runtime type checking, right?
Yes, lazy loading I would say.
I performed now some tests with BuddyClassLoader. The core bundle gets
an entry 'Eclipse-BuddyPolicy: registered'
and the other bundles register at the core bundle. If the core bundle
requires classes it searches in the registered
buddies. The performance seems to bad a little bit worser (but still in
milliseconds). After the core bundle loaded a class
from one of the other bundles (e.g. B) you cannot refresh bundle B. If
you would like to update bundle B you have to
refresh the core and again all bundles get refreshed.
BuddyClassLoading is not part of OSGi R4, but part of Eclipse. Eclipse
guys are planning to bring it into OSGI R4.1.
Best regards
Nicole
________________________________
From: Hawkins, Joel [mailto:Joel.Hawkins@compuware.com]
Sent: Wednesday, November 15, 2006 3:41 PM
To: Wengatz, Nicole
Cc: Jim Marino
Subject: RE: Bundles and OSGi
Hi Nicole,
Yikes! Forcing a refresh on the core sounds grim. Good news about the
startup times. It shouldn't be surprising, though, since the core is
just deferring package resolution until first reference. Like
compile-time type checking vs runtime type checking, right? ;-)
I'm not sure the core should use dynamic imports - maybe just the
extensions? In my updated prototype, in the
SystemComponentImplementation corresponding to each extension, I'm
setting the extension classloader to the bundle class loader (the one
that the extension's corresponding BundleContext uses). My hope is that
this classloader will be used to resolve everything that the extension
needs. Then, if an extension had dependencies on another extension, the
dynamic import mechanism could resolve it, and the resulting dependency
would be between the two extension bundles, i.e. not with the core. Does
this sound reasonable, or am I missing something?
Since we know what packages are in the core (and it won't change), we
could just pound those into the import list for each dynamically created
extension bundle, and that would take care of anything like api and spi
dependencies. What we don't know (and what has the word 'hack' around it
everywhere in the code base) are the interdependencies between
extensions. Currently these are handled as imports in the scdl, and
playing a bit looser with the class loading structure than what Jim
ultimately wants to do (I think). For OSGi, I think we have to find
someway to have those scdl imports result in OSGi package imports.
Dynamic imports at the extension level sound like an easy way to achieve
this, particularly at runtime.
Jim, does the provisioning spec you're working on offer any help with
versioning of dependencies? I noticed from the Spring Container and the
Axis2 service that the only conflicting dependency (at least as surfaced
in the maven poms) was with logging. Would this be something that would
show up in the scdl? For dynamic imports, it won't be sufficient (in
some cases) for us to just import all packages, as we'll be opening
ourselves up to version issues (Linkage errors, CNF exceptions, etc.).
Thanks,
Joel
-----Original Message-----
From: Wengatz, Nicole [mailto:nicole.wengatz@siemens.com]
Sent: Wednesday, November 15, 2006 8:58 AM
To: Hawkins, Joel
Cc: Jim Marino; Wengatz, Nicole
Subject: RE: Bundles and OSGi
Hi Joel,
sounds good :-)
I'm just performing some tests with the DynamicImport-Package: *
feature.
I defined one core bundle and several bundles (which could contain the
extensions).
The core bundle has an entry DynamicImport-Package: * to be able to
load all
classes exported by the other bundles.
Every bundle has an import to a package exported by the core to simulate
that the extension require
classes from the core.
My findings are:
1)
The performance drawbacks are not very critical. I started about 120
bundles, 50 of them export classes
used/required by the core. Startup time is still in milliseconds area.
2)
If the core bundle loads a class from one of my other bundles (e.g. A)
using dynamic importing, the core is
dependent to this bundle. If I refresh now this bundle A, the core will
be refreshed as well. And since all
my bundles have an import to a class provided by the core, they will
also be refreshed :-(
What I'm missing is a refresh of only one wire, in this example the wire
between core and A.
I'm not sure if this behaviour is critical for the extensions. If we use
dynamic imports for the extensions
and one of the extensions will be refreshed, all extensions having an
import to the core/runtime would
be refreshed. What do you think?
I'm planning to have a deeper look to the BuddyClassloading now.
Best regards
Nicole
________________________________
From: Hawkins, Joel [mailto:Joel.Hawkins@compuware.com]
Sent: Wednesday, November 15, 2006 2:36 PM
To: Wengatz, Nicole
Cc: Jim Marino
Subject: Bundles and OSGi
Nicole,
I've got the prototype that I sent you working using Bundles instead of
Fragment Bundles. It was actually fairly simple to do. I'm going to try
and get the Axis2 and Spring extensions loading today. If I can do that,
I'll submit a patch, and we can start working on the dynamic bundle
creation bit. My thought was to use Axis2 and Spring to manually create
what we'll want to generate. Call it a voyage of discovery. ;-)
Cheers,
Joel
=00The contents of this e-mail are intended for the named addressee
only. It contains information that may be confidential. Unless you are
the named addressee or an authorized designee, you may not copy or use
it, or disclose it to anyone else. If you received it in error please
notify us immediately and then destroy it.
=00The contents of this e-mail are intended for the named addressee
only. It contains information that may be confidential. Unless you are
the named addressee or an authorized designee, you may not copy or use
it, or disclose it to anyone else. If you received it in error please
notify us immediately and then destroy it.
Re: Bundles and OSGi
Posted by Andy Piper <an...@bea.com>.
In Spring-OSGi we looked at and discarded the BuddyClassloader
approach since I believe it futzes with the CCL in a way that
prevents other CCL applications.
andy
At 11:44 16/11/2006, Jeremy Boynes wrote:
>On 11/15/06, Hawkins, Joel <Jo...@compuware.com> wrote:
>>
>>-----Original Message-----
>>From: Wengatz, Nicole [mailto:nicole.wengatz@siemens.com]
>>Sent: Wednesday, November 15, 2006 10:23 AM
>>To: Hawkins, Joel
>>Cc: Jim Marino; Wengatz, Nicole; Jasny, Robert
>>Subject: RE: Bundles and OSGi
>>
>>I performed now some tests with BuddyClassLoader. The core bundle gets
>>an entry 'Eclipse-BuddyPolicy: registered'
>>and the other bundles register at the core bundle. If the core bundle
>>requires classes it searches in the registered
>>buddies. The performance seems to bad a little bit worser (but still in
>>milliseconds). After the core bundle loaded a class
>>from one of the other bundles (e.g. B) you cannot refresh bundle B. If
>>you would like to update bundle B you have to
>>refresh the core and again all bundles get refreshed.
>>BuddyClassLoading is not part of OSGi R4, but part of Eclipse. Eclipse
>>guys are planning to bring it into OSGI R4.1.
>
>This worries me a little as I would not like to think that the only
>OSGi implementation that was supported was Eclipse's. When is 4.1 due
>and/or does, for example, Felix offer something similar to this?
>
>--
>Jeremy
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>For additional commands, e-mail: tuscany-dev-help@ws.apache.org
_______________________________________________________________________
Notice: This email message, together with any attachments, may contain
information of BEA Systems, Inc., its subsidiaries and affiliated
entities, that may be confidential, proprietary, copyrighted and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by email and then delete it.
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Bundles and OSGi
Posted by Jeremy Boynes <jb...@apache.org>.
On 11/15/06, Hawkins, Joel <Jo...@compuware.com> wrote:
>
> -----Original Message-----
> From: Wengatz, Nicole [mailto:nicole.wengatz@siemens.com]
> Sent: Wednesday, November 15, 2006 10:23 AM
> To: Hawkins, Joel
> Cc: Jim Marino; Wengatz, Nicole; Jasny, Robert
> Subject: RE: Bundles and OSGi
>
> I performed now some tests with BuddyClassLoader. The core bundle gets
> an entry 'Eclipse-BuddyPolicy: registered'
> and the other bundles register at the core bundle. If the core bundle
> requires classes it searches in the registered
> buddies. The performance seems to bad a little bit worser (but still in
> milliseconds). After the core bundle loaded a class
> from one of the other bundles (e.g. B) you cannot refresh bundle B. If
> you would like to update bundle B you have to
> refresh the core and again all bundles get refreshed.
> BuddyClassLoading is not part of OSGi R4, but part of Eclipse. Eclipse
> guys are planning to bring it into OSGI R4.1.
>
This worries me a little as I would not like to think that the only
OSGi implementation that was supported was Eclipse's. When is 4.1 due
and/or does, for example, Felix offer something similar to this?
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org