river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bharath Kumar <bharathkuma...@gmail.com>
Subject Re: OSGi
Date Thu, 19 Jan 2017 17:22:02 GMT
Hello all,

I am Bharath kumar and this is my first mail to this group. I am following
River framework for the last 8 years. I have been using OSGi framework for
the past 7 years in various projects.

 I made lot of attempts to use jini with OSGi framework.
Recently I got some success using River 3.0.0 version. I created 3 OSGi
bundles based on River code.

1. River core classes as system fragment bundle.
2. Bootstrap bundle to start code server, Lookup discovery manager, export
remote services.
3. Lookup service.

I made some minor changes to River classes (10 Classes) to resolve class
loading issues. I have excluded other services like transaction services,
Java space services.

I am using eclipse and bndtools for the development. I am ready to share
these 3 bundles to this great community.

Thanks & Regards,

On Jan 19, 2017 8:55 AM, "Peter" <jini@zeus.net.au> wrote:

Thanks Nic & Richard, will follow up your leads.


Sent from my Samsung device.

  Include original message
---- Original message ----
From: Niclas Hedhman <niclas@hedhman.org>
Sent: 18/01/2017 08:34:11 pm
To: dev@river.apache.org
Subject: Re: OSGi

Also, I am still on this list, and can aid with answering question in
details, but not really to put in hours to do the actual work.

The maven-bnd-plugin does most things right, but there is always a question
of hiding internal packages/classes. Instead of aiming for running 'naked'
on a blank OSGi container, I think it is generally better to start out with
something like Apache Karaf. It will provide a lot for relatively little,
incl so called wrapping of JARs into Bundles, provided by Pax URL[1]
project, which also provides URL references of various kinds for many
things. So, even if not going with Karaf, take a look at Pax URL.

And in River, there is likely to be classloading issues, and although
"Dynamic-ImportPackage" is available as a last resort, it should be
avoided. Almost always the context classloader is a "mess", and there is a
tendency of memory leaks when it is involved.

[1] https://ops4j1.jira.com/wiki/display/paxurl/Pax+URL

On Wed, Jan 18, 2017 at 11:18 AM, Peter Firmstone <
peter.firmstone@zeus.net.au> wrote:

> Any OSGi veterans willing to assist with JGDMS support for OSGi during the
> modular restructure?
> I've added OSGi manifests to modules, but I also need to add classpath
> manifest entry's for non osgi application compatibility, I'm using the
> bnd-maven-plugin to generate the OSGi manifests.
> I also want to enable using ServiceLoader  mediator manifest entry's for
> OSGi, as the use of service provider style abstractions within River are
> widespread.
> River also has its own service provider lookup mechanism:
> org.apache.resources.Service
> Then there's the use of context ClassLoader's throughout to consider.
> Regards,
> Peter.
> Sent from my Samsung device.

Niclas Hedhman, Software Developer
http://polygene.apache.org <http://zest.apache.org> - New Energy for Java

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