tuscany-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rajini Sivaram" <rajinisiva...@googlemail.com>
Subject Re: Improving support for running in OSGi
Date Thu, 01 May 2008 08:20:08 GMT
On 4/30/08, Graham Charters <gcharters@googlemail.com> wrote:
>
> 2008/4/30 Raymond Feng <enjoyjava@gmail.com>:
> > "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.).



Eventually, I imagine Tuscany bundles containing OSGi manifest entries will
be built as a distribution step. So the main purpose of itest/osgi-tuscany
should be to ensure that the we can run Tuscany inside an OSGi runtime or a
multi-classloader environment with whatever combination we choose for
distribution. Having a finer grained bundle structure for itest/osgi-tuscany
does not preclude the use of any coarser grain combination in the
distribution.

I do agree that using finer grained OSGi bundles may divert focus away from
exploring higher-level combinations. And we could potentially be fixing
issues that would never arise in coarser grained bundles. But adding
manifest headers to Tuscany modules could provide some valuable benefits.

   1. We can decouple classloading in Tuscany completely from the
   distribution structure. By proving that each module can run in a separate
   classloader, we would be ready for any distribution, including addition of
   individual extension modules as separate bundles. Basically every time
   someone wants a different distribution structure, we wont need to go and
   start testing that there are no classloader issues with using that
   combination. Yes, we may fix some classloading issues that may never arise
   in real life. But if modules in Tuscany correspond to "modules" in any
   sense, we should avoid assuming that different modules are loaded using a
   single classloader. Most of the classloading issues have already been fixed,
   and this shouldn't require much effort now.
   2. It is very easy to add. maven-bundle-plugin can be used to add the
   manifest entries, and it is not  a big task. At least in the short term, I
   would expect import/export statements for manifest entries to be generated
   using maven-bundle-plugin rather than explicitly specified in the pom. So I
   dont think maintenance will be very unmanageable.
   3. It is the easiest way to make OSGi-enablement a first class
   feature. Until now, all OSGi work in Tuscany has been as segregated as
   possible from the rest of Tuscany. Using a test module to build and test
   OSGi-based Tuscany will continue that tradition. Introducing manifest
   entries in all poms will at least make the OSGi work more mainstream. I
   would expect that most people copy an existing pom when creating a new
   module, rather than writing one from scratch, so I would expect that the
   level of breakage that we will experience will be less than with
   itest/osgi-tuscany. And this process will help in raising awareness. The
   extra manifest entries will have no impact on the regular usage (development
   or execution) of Tuscany without OSGi.
   4. The manifest entries generated by maven-bundle-plugin will contain
   explicit import/export packages in all modules, which I believe are better
   than maven module dependency listing because they are based on actual use.
   These could be very useful to Tuscany to improve its modularity story.

We are very close to getting this to work - basic tests work with Tuscany
modules and 3rd party libs built as 200 separate bundles with minimal
changes (at least they did 6 months ago), so it wont be too much wasted
effort, regardless of the final distribution structure.

>  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).

>  3) Support OSGi bundles as SCA contributions (application level, how does
> > the OSGi import/export relate to the sca-contributions.xml?).


OSGi bundles are already supported as SCA contributions. OSGi import/export
is used to resolve references between OSGi contributions (Tuscany does not
get involved in this case).  SCA import/export is used to resolve references
between OSGi contributions and non-OSGi SCA contributions.



> >
> >  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).
>
> 3 might be the best solution longer term, but is the most work.


I am not sure why you think this is the most work. We already have the code
to do this in osgi-tuscany. osgi-tuscany runs most of the samples from the
samples/ directory. It does this by creating virtual bundles for the samples
at runtime and then running them under OSGi-based Tuscany - there is no
build process for generating the sample bundles. For the longer term,
there will be some work to do to generate the manifest entries for all the
third party jars to avoid dynamic imports, but this can be done offline
using something like maven-pax-plugin. Beyond the generation of manifest
entries, it should be merely some copy-and-paste :-).  In fact, we create
virtual bundles all over the place (implementation_osgi, contribution_osgi
and osgi_tuscany). Performance may be an issue, but in terms of getting
something working quickly, this would be the easiest option.


>  Thanks,
> >  Raymond
> >
> >  --------------------------------------------------
> >  From: "Yang Lei" <genially@gmail.com>
> >  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)
> > > <philipp.konradi@siemens.com> 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:gcharters@googlemail.com]
> > > > 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.
> > > >
> > > >
> > >
> >
>



-- 
Thank you...

Regards,

Rajini

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message