Graham Charters wrote:
Hi Raymond, thanks for your comments. I've added some more below.
Regards, Graham.
2008/4/30 Raymond Feng <[EMAIL PROTECTED]>:
More comments inline.
Thanks,
Raymond
--------------------------------------------------
From: "Graham Charters" <[EMAIL PROTECTED]>
Sent: Wednesday, April 30, 2008 9:43 AM
To: <tuscany-dev@ws.apache.org>
Subject: Re: Improving support for running in OSGi
2008/4/30 Raymond Feng <[EMAIL PROTECTED]>:
"Enforcing" the modularity via OSGi is a good way to validate our
modularity/extensibility story in Tuscany. I think we already have a
fairly
well organized module structure in Tuscany (from the maven dependency
perspective). To be consistent, should we consider directly mapping our
module structure into OSGi bundles (one bundle per existing Tuscany
module)?
I wonder if that might be too fine-grained and unmanageable.
Personally, I'd prefer an approach which took into consideration how
we see folks extending or sub-setting the runtime (e.g. the things
Yang referred to - implementation types, etc.).
IMHO, big bundles lead to defeat modularity and increase coupling. It also
become difficult to embed subset of the Tuscany runtime. But anyway, we can
adjust the scheme over time as the picture becomes clearer.
To a certain extent I agree with you, but there's also a school of
thought that says when adopting OSGi it's best to start with big
modules and then decompose as understanding grows. I think the
thought processes we go through will ensure we end up with the right
modules that match the requirements, such as runtime subsetting.
There may be different levels for the OSGi enablement.
1) Add OSGi entries to the META-INF/MANIFEST.MF so that Tuscany jars
can be
consumed as OSGi bundles
2) Run Tuscany bundles with an OSGi runtime (using OSGi as the
modularization mechanism for the Tuscany runtime, system level)
I think we need this step to occur regularly and frequently to stop
the support decaying. I've fixed these kinds of issues twice in the
last week, which occur because new modules are added to Tuscany, but
not the OSGi support (not surprising since the OSGi support is outside
the main build).
Is there a checklist we can use to make sure new modules or changes won't
break the OSGi support? If not, can we produce one and post it to the
Tuscany wiki?
I think we could produce a checklist to help folks. It would also be
nice to make it easier for people to get things right without it. The
idea of updating the module structure to reflect the bundles we create
is interesting. I guess if the number of bundles is changing rapidly
then this might be a bit painful. We could also have the bundles
build on continuum so we find problems earlier. Having everyone build
the bundles might not be acceptable.
3) Support OSGi bundles as SCA contributions (application level, how
does
the OSGi import/export relate to the sca-contributions.xml?).
The other interesting issue is how we deal with the 3rd party jars,
most of
which are not OSGi bundles. To support the case that different Tuscany
extensions may require different versions of the same 3rd party jar, we
need
to figure out a good way to "turn" 3rd party jars into OSGi bundles.
This is a knotty problem. It's not a new problem and is discussed
here: https://mail.osgi.org/pipermail/jsr-291-eg/2006-March/000023.html
Licensing and signing can prevent us from adding information to the
jars, which leaves us with three options, I think:
1. Create wrapper bundles which contain the jars, which raises
concerns about disk space.
2. Use a non-OSGi mechanism to refer to jars outside a bundle
(Equinox allows this).
3. Devise a new mechanism to create 'virtual bundles' on the fly (see
https://www.osgi.org/members/bugzilla/show_bug.cgi?id=277).
Unfortunately, the URL requires a log-in. Is it possible to post the
content here?
My apologies, I hadn't realized this was a member bug and therefore
required access (I must have already been logged in when I tested it).
I can't paste in the details, but I can summarize. This bug
discusses the requirement raised in the first link. It discusses the
approach to allow the bundle classpath to reference jars outside the
bundle (the equinox approach), and also considers a 'virtual bundle'
concept (which seems preferred). There aren't many details about the
latter.
3 might be the best solution longer term, but is the most work.
Thanks,
Raymond
--------------------------------------------------
From: "Yang Lei" <[EMAIL PROTECTED]>
Sent: Tuesday, April 29, 2008 9:09 PM
To: <tuscany-dev@ws.apache.org>
Subject: Re: Improving support for running in OSGi
I think enabling OSGI can help modularity with a clear definition of
package visibility, so we can have a much cleaner "module"
dependencies through osgi bundle import/export on package. I think
it will help Tuscany adopters a lot in the scenarios such as: when
implementing new implementation type, binding type, or data binding
types, there is clear indication which set of packages can be used
(exported API/SPI ). So upgrading to new Tuscany level can be as
simple as plug and play if there is no API/SPI changes, and version
control (multiple version co-existence) can also be made available
through OSGI capabilities.
Regards,
Yang
On Tue, Apr 29, 2008 at 1:49 PM, Konradi, Philipp (CT)
<[EMAIL PROTECTED]> wrote:
Hi,
I'd like to get people's thoughts on whether the idea of > > >
'promoting'
OSGi is a good one,
IMHO support of OSGi is very important and I glad to see increasing
interest of the community here.
and get ideas on how best to proceed.
I personally have currently not a very deep insight into > >
implementation
details yet, but we are currently prototyping and have there also OSGi
services.
What I could offer today is only to feed our findings about > >
limitations
and rooms for improvement back.
Another important thing which I see on the horizon, is the ongoing
standardization of Distributed OSGi (RFC119) and the benefit to support
that
standard in Tuscany's OSGi bits. So from mid-term perspective I suggest
to
keep an eye on that as well.
Regards,
Philipp
-----Ursprüngliche Nachricht-----
Von: Graham Charters [mailto:[EMAIL PROTECTED]
Gesendet: Montag, 28. April 2008 09:48
An: tuscany-dev@ws.apache.org
Betreff: Improving support for running in OSGi
Hi All,
I'd like to get more involved in the OSGi support in Tuscany (both >
the
modularity work (itest/osgi-tuscany) and the implementation.osgi).
I
recently started looking at the work to run Tuscany in OSGi,
embodied
in itest/osgi-tuscany and described in the thread entitled
"Classloading in Tuscany". I've noticed a couple of others on the
list also interested in Tuscany running in OSGi and wondered if it
might be worth considering making this a "first-class" option. At >
the
moment the five bundles are only built by folks who want the OSGi
support and go into the itest/osgi-tuscany directory to create it.
This can result in any problems being discovered late, but also
could
create the impression that OSGi is considered a second-class
environment (which I don't believe is the case).
Aside from the obvious benefits to OSGi users in doing this, I think
there's a potential for Tuscany to use the OSGi build as a test-bed
for highlighting and working through modularity issues, which would
also benefit Tuscany in general, not just in an OSGi runtime.
I'd like to get people's thoughts on whether the idea of 'promoting'
OSGi is a good one, and get ideas on how best to proceed. We could
then start discussing what some of the issues might be (e.g. size of
builds, time to build, etc...).
Regards,
Graham.
My 2c:
+1 to promote OSGi to a first class Tuscany runtime environment
+1 for an OSGi continuum build (thinking about a build profile that'll
run the Tuscany itest suite in an OSGi environment, similar to the
profiles we have for Web containers for example)
Here's what I imagined we'd do:
1. add OSGi entries to each of our JAR manifests
2. have developers maintain them and pay attention to imports/exports
3. use the OSGi build to detect API and SPI import/export violations
4. find the best way to OSGi-enable 3rd party dependency JARs
I realize that my suggestion [1] is not very popular and most people on
this list would prefer to come up with bigger bundles grouping several
of our JARs/modules. I don't think that the 'bigger aggregate bundle'
approach will work, but I'll be happy to watch people try it :) if they
want to.
With respect to [4] I find rather funny to see many projects out there
claim OSGi enablement without having OSGified their 3rd party
dependencies. I wonder how that works, can an OSGi-enabled project
really leverage the OSGi classloader isolation and versioning
capabilities when 99% of the JARs it requires are not OSGi bundles? I
must be missing something... and I hope we can do better in Tuscany with
a real end-to-end OSGi enablement story :)
--
Jean-Sebastien
