A few of us had a discussion about OSGi integration today on IRC for
those interested:
[08:11am] jhawkins: Welcome, Nicole!
[08:11am] jmarino: Hi Nicole
[08:11am] jmarino: should we begin?
[08:11am] Nicole: yes Should we start asking questions?
[08:12am] jhawkins: Lets. Where do you want to start?
[08:13am] Nicole: I would like to talk about the requirement having
the same jars for OSGi and other hosts.
[08:13am] jmarino: k what do you guys think of that?
[08:14am] Nicole: From my point of view it should not be a problem to
generate bundles out of the JARs which we can use in OSGi.
[08:14am] jhawkins: I think we'll probably have a requirmeent for
dual packaging. In other words, there will be some bpeople who will
want an OSGi centric capability, and otheres who'll opt fo conveince.
[08:15am] jmarino: ok my thinking around wanting to have the same was
that we could reuse extensions across runtime hosts. So if someone
wanted to write an extension, it would run on OSGi or in a servlet
container, etc.
[08:16am] jhawkins: I did take a look at the Spring virtual bundle
code (thanks Nicole), and it's true that we could pretty easily do
that. However I think some of the cases where extensions share
dependencies will be problimatic
[08:16am] Nicole: We could have the sources of the binding in OSGi
and provide 2 maven tags. One for the simple JAR, one for a bundle.
[08:17am] jmarino: In the extension model now, we have the
<depenency> tag...could we programatically create the OSGi bundle? I
was thinking we could support both bundles directly (pure OSGi) and jars
[08:18am] Nicole: What is the meaning of the <dependency>? Dependency
to other jars?
[08:19am] jmarino: yes it's basically from Maven. It's more coarse
grained than package dependencies
[08:20am] jhawkins: Sure. The problem comes I see is getting the
import/exports right. Are you planning on doing this at runtime, or
during provisioning?
[08:20am] jmarino: I was thinking this would be done when the
extension is deployed into the runtime. This could be "live" or some
time earlier.
[08:21am] jmarino: I should step back and describe what we are doing
in the spec a little since we are talking about deployment
[08:21am] jhawkins: That would help.
[08:21am] dkulp joined the chat room.
[08:21am] jmarino: ok we are still in the early stages
[08:22am] jmarino: but what we wanted was a way to express
dependencies as well as the equivalent of exports in a language
neutral way...
[08:22am] jmarino: for example, there are not just Java packages,
classes, etc. but also things like WSDL, XSDs, etc.
[08:23am] jmarino: we were thinking about having a syntax for that.
It would share some concepts to OSGi
[08:23am] jmarino: I was thinking we could interpret this "syntax"
and convert it to creating bundles in OSGi
[08:23am] jhawkins: Where would this metadata reside? SCDL? Manifest?
[08:24am] jmarino: yes the metadata would be in SCDL
[08:25am] Nicole: It will not work out of the box, but we could adapt
the Spring<->OSGi stuff. They are reading export/import info out of a
file.
[08:25am] Nicole: We could read the SCDL and create bundle with
manifest.
[08:26am] jhawkins: OK. So imagining we've got that, the question
becomes "what would the translation result look like".
[08:26am] Nicole: A fragment bundle?
[08:27am] jhawkins: Good question. Jim's statement that extensions
should have their own class loaders kills fragment bundes (unless we
want to dig into that deeper).
[08:27am] jmarino: maybe we should dig deeper into that?
[08:28am] jmarino: we don't have this implemented yet but...
[08:28am] jhawkins: Also, the fragment bundle solution has
implications on runtime isolation. Do we want to support multiple
runtimes in a single OSGi?
[08:29am] jmarino: I assumed there would be one but that was just an
assumption without much thought. Is that a bad assumption?
[08:29am] jhawkins: You da' man - how many do you want?
[08:29am] jmarino: not sure about that My OSGi knowledge is pretty
basic
[08:29am] Nicole: Now I'm confused. I Thought one Runtime and X
system/application composites ...
[08:30am] jmarino: that's what I was thinking
[08:30am] Nicole: What would be the advantage of having more than one
Joel?
[08:32am] jhawkins: That would make life easier. To me, this gets
into a "who's on top" discussion. If I see OSGi as some sort of
container container, then I would need to be able to support mutlipe
runtimes (just like a web container supports multiple web apps)...
[08:32am] jhawkins: I don't have a dog in this hunt... just a question
[08:32am] rfeng joined the chat room.
[08:33am] jmarino: I'm wondering if it makes things simpler to assume
one runtime per OSGi container?
[08:33am] jhawkins: If we go with one runtime, then taking a fragment
bundle approach is more defensible, and we can probably leverage more
from OSGi.
[08:33am] Nicole: Only to get the 'big picture'. If we have one
runtime, I could (later also deploy an EJB in it?
[08:34am] jmarino: I think so
[08:34am] jmarino: are you guys o.k. with this assumption then?
[08:35am] jhawkins: Yes. What you probably wouldn't be able to do is
deploy EJBs from different EJB versions.
[08:35am] Nicole: One OSGi, one Tuscany Runtime, hosting several
applications (with different implementations) makes sense for me
[08:35am] jhawkins: +1
[08:35am] jmarino: k should we dig deeper into the classloader
assumptions?
[08:35am] Nicole: yes please
[08:36am] jhawkins: OK.
[08:36am] jmarino: in the current runtime we don't have this
implemented yet but...
[08:36am] jmarino: we were thinking extensions would be isolated from
one another...
[08:36am] jmarino: each composite that contained an extension would
have its own classloader...
[08:37am] jmarino: however, some extensions (e.g. Spring) reference
classes internally that application code can also reference...
[08:37am] jmarino: this means we need to "share" those classes from
the extension to the application (which also has its won classloader)
[08:37am] jmarino: won = own
[08:38am] jhawkins: I think from the application point of view this
is quite do-able...
[08:38am] jhawkins: but lets take an example from the extension world...
[08:38am] jhawkins: (finally figured out the ...s)
[08:39am] jhawkins: The Axis extension has a dep on axiom...
[08:39am] jhawkins: as does the databinding extension ...
[08:40am] jhawkins: Who should have responsibility for exposing
axiom, and how do we determine the proper way to do this? Will we
ahve enough info in the SCDL?
[08:41am] jmarino: yes I believe we will have enough in SCDL. Perhaps
we could also support doing so in the bundle manifest too?
[08:41am] jmarino: In the case of SCDL, we would "tell" the OSGi
container about it
[08:41am] Nicole: Should every extension expose its contained packages?
[08:42am] jmarino: I think only if it needs to
[08:42am] jmarino: some extensions may not need to expose anything
[08:42am] jmarino: that's probably rare though
[08:43am] Nicole: Ok, so this is the responsibility of the extension
developer/provider to decide?
[08:43am] jhawkins: Correct me if I'm wrong, but Nicole, is what yoru
asking is should every extension expose what it's willing to expose?
[08:44am] Nicole: The extension developer has to decide if its
packages are required by others. In this case it exposes, otherwise not.
[08:45am] jhawkins: That sounds a lot like the OSGi export header.
[08:45am] jmarino: yes functionally I think it is very similar,
except more coarse grained and may include things other than Java
(e.g. WSDL QNames)
[08:46am] Nicole: Yes, but how does the 'OSGi Core' know which
extensions are available and how/from where to import? Dynamic import:*?
[08:47am] jmarino: I was thinking in the SCA runtime we would have a
"deployer" that took an archive (jar, bundle, etc) and than told the
OSGi container about it
[08:48am] jmarino: the "deployer" (actually provisioner may be a
better term) could have gotten the archive from some other place,
e.g. in a network of these runtimes
[08:49am] jmarino: or it could just be a file system directory with
some scanner that picks up new archives
[08:49am] jhawkins: There's probably two cases here - one for
'untranslated' bundles, and one for OSGi-packaged bundles.
[08:49am] jhawkins: I want to get back to how we install these into
the runtime...
[08:50am] jmarino: k
[08:50am] jhawkins: basically, I want to get some closure on the
fragment bundle question.
[08:51am] jmarino: k this related to the question of sharing various
classes/packages between an application and an extension or between
two extensions?
[08:51am] jhawkins: Between tow extensions.(two)
[08:52am] jhawkins: I'm assuming we want to package applicationsa as
bundles, right?
[08:52am] jmarino: yes I think so
[08:53am] Nicole: This would mean that a SCA developer has to know
OSGi if he wants to deploy its application in Tuscany running in OSGi?
[08:54am] jhawkins: Yes. And would probably need to know which
imports his choice of bindings/services would require (a nice tooling
opportunity).
[08:55am] Nicole: Ok, with a nice tooling everything is possible.
[08:55am] jmarino: maybe we could start with this assumption and then
later if we need to we could support deploying other types of archives?
[08:55am] jhawkins: OK. Back to extension?
[08:55am] jmarino: I imagine this would work similar to extensions?
[08:55am] jhawkins:
[08:55am] Nicole: Yes, same discussion
[08:56am] jmarino: back to extensions sounds good to me
[08:56am] jmarino: are fragments the best way to go for sharing?
[08:57am] jhawkins: Well, they're dead easy.
[08:57am] jhawkins: There a nice way of extending bundle
functionality without a lot of code.
[08:57am] jmarino: so maybe you could give me a quick tutorial...
[08:58am] Nicole: The host will know classes provided in both
extensions, but how can extension 1 access classes of extension2?
[08:58am] jhawkins: OK. Pardon my elipses. ...
[08:58am] jhawkins: What a fragment bundle does is basically hitch
itself to a single host bundle's classloader...
[09:00am] jhawkins: OSGi appends the bundles non-conflicting imports
to the host bunldes, and exposes non-conflicting exports as if they
were part of the host.
[09:00am] jhawkins: It's a great way to modularize something like
Axis, where you've got lots of optional components.
[09:01am] jmarino: k so I could say "share everything in this
fragment" or "share part of what is in this fragment"?
[09:01am] jhawkins: Yes.
[09:02am] jhawkins: You can also let OSGi deal with the Axiom issue,
such that you could resolve Axiom from a seperate bundle.
[09:03am] jhawkins: What you lose is the absolute classloader
isolation, such that you could run extesnions with conflicting
dependencies.
[09:04am] jmarino: Nicole, what do you think?
[09:05am] Nicole: I think fragment bundles are a good and easy solution.
[09:05am] jhawkins: You also lose the ability to dynamically start/
stop extensions. Not sure if that's a plus or a minus.
[09:05am] jhawkins: So perhaps out manifest translation target is a
fragment bundle?
[09:06am] Nicole: But if extension 1 requires classes from extension
2 it's a simple import/export independend of the fragment stuff.
[09:06am] jhawkins: Yes.
[09:07am] Nicole: Can we update a fragment bundle?
[09:08am] jhawkins: You can uninstall/reinstall. Not sure about
update, but I think that would be just an uninstall/reinstall combo...
[09:08am] jhawkins: I'd imagine that a management interface exposed
by the SCA core would support the extension refresh, among other things.
[09:09am] Nicole: I'm wondering why uninstall/install works but start/
stop does not. But anyway if update works, we should not have problems.
[09:10am] jhawkins: I'll toss a note into the Equinox list to see if
I can get some historical perspective on that.
[09:11am] Nicole: What do you think Jim, should we go with fragments?
[09:12am] jmarino: I'll defer to you guys. If you think that is the
best way then we should use that. My OSGi knowledge is pretty basic.
[09:12am] jmarino: it sounds like they are the way to go based on
what you said
[09:12am] Nicole: You should have a look to Joels prototype and see
how it works
[09:14am] jmarino: Joel, were you using bundles or fragments?
[09:14am] jhawkins: I guess my big question is what is the primary
reason for independent classloaders for extensions. Is it visibility
restriction to the app layer, or isolation between extensions. If
it's isolation, then perhaps we need to think harder.
[09:14am] jmarino: It's both
[09:14am] jhawkins: Bundles for apps, fragments for extensions.
[09:14am] jmarino: we need to isolate between extensions in case they
have a conflicting dependency
[09:15am] jmarino: that is, two "separate" extensions
[09:15am] jmarino: e.g. Axis and Spring
[09:15am] jhawkins: Then I'm afraid fragments won't work for us.
[09:16am] jmarino: ok let's take an example
[09:16am] jmarino: say I have Spring and Axis
[09:17am] jmarino: both depend on Axiom, but Spring requires v1 and
Axis needs v2. They do not need to interoperate.
[09:17am] jmarino: could fragments give us the right isolation?
[09:18am] rfeng: fragments will be logically part of the same bundle,
no isolation between fragments
[09:18am] jhawkins: Right. First fragment will get to pick Axiom, and
the other is hosed.
[09:19am] jmarino: hey Raymond
[09:20am] Nicole: Axiom is an extension bundle and all three are
fragments with one core host?
[09:21am] rfeng: BTW, I notice that Spring adopted a virtual bundle
concept which dynamically creates bundles around regular jars so the
runtime will deal with bundles
[09:21am] Nicole: Why importing from the fragment host and not
directly (with correct version) from Axiom bundle?
[09:21am] rfeng: hi, jim
[09:21am] jmarino: so I was thinking Spring would be one extension
"archive", Axis another...they would declare dependencies on
different versions of Axiom. Axiom would be a jar
[09:23am] jhawkins: Yes. Here's where the fragment bundle part of the
spec's definition of 'conflicting' trips us up. Since the fragment
bundles basically get appended to the host (as Raymond pointed out)...
[09:24am] jhawkins: the first fragment loaded will set up an import
definition for axiom that will conflict with the next fragment, if
you're lucky...
[09:24am] jhawkins: You may wind up with a split package (and a reall
mess) if nobody put version ranges into theire manifests.
[09:25am] Nicole: Ok, understood. Back to dynamic import:*?
[09:25am] jmarino: so are the Spring and Axis extensions fragments of
the runtime bundle?
[09:26am] jhawkins: Nicole - looking like it. Jim, yes.
[09:26am] jmarino: k so you are instead saying they should be bundles?
[09:27am] jhawkins: Yes. I think so (sighs wistfully)
[09:27am] jmarino: Nicole, do you think that is ok?
[09:28am] Nicole: Yes, we should have a look to it. I'm not sure how
performant this dynamic import stuff is. Whenever an import is
required, the runtime has to search for it.
[09:28am] Nicole: So I believe it depends on the number of bundles.
[09:29am] jmarino: k so dynamic import will be performed by the
runtime as it encounters dependencies in extension SCDL?
[09:29am] jhawkins: Yeah. With fragments, all you needed was a bundle
dependency. Ah well.
[09:30am] Nicole: If the runtime has not already imported the
required classes, it starts searching for it in all (because of *)
other bundles.
[09:31am] Nicole: There is another concept, Buddy ClassLoading (not
OSGi R4, but maybe R4.1), is an Eclipse feature.
[09:32am] Nicole: You can define your bundle (e.g. your extension
bundle) as buddy for the runtime.
[09:32am] Nicole: The runtime will search ONLY in the buddies for
required classes.
[09:34am] jhawkins: Sounds like we need to go do a bit of research.
[09:34am] jmarino: yes
[09:35am] Nicole: Yes, at work I got already an action item to find
out the performance drawback of Dynamic Import.
[09:35am] jmarino: k Nicole do you want to take a look at that?
[09:35am] Nicole: Yes
[09:36am] jmarino: is that maybe a good place to break? Nicole would
you have enough info to go off and investigate? We could reconvene
when you have something to share?
[09:36am] jmarino: (a few days or however long it takes)
[09:37am] Nicole: Yes, I'm planning to do an evaluation with dynamic
imports and will come back to you with the results.
[09:37am] jmarino: in the meantime we could discuss on the list and
then set up more IRC sessions if needed?
[09:37am] Nicole: Fine
[09:37am] jhawkins: Works for me.
[09:38am] Nicole: Ok, have a nice day!
[09:38am] jmarino: k let's do that. I'll post this transcript to the
list and we can follow-up there
[09:38am] jmarino: k you too
[09:38am] jhawkins: Great. Cheers.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
