Guillaume Nodet wrote:
For those that are not aware of ServiceMix Kernel (I know David is),
i'd like to point them to it. Feel free to download it and give it a
try. It's based on felix, gshell and a few other bundles. We're using
it to deploy our JBI container in ServiceMix 4 (including the geronimo
transaction manager, activemq, jetty, but those are not included in
the kernel).
See http://servicemix.apache.org/kernel/index.html
To add to this discussion, we are deploying stuff on servicemix using
"features", which is imho the metdata related to (2).
A feature is mostly a list of OSGi bundles with some dependencies on
other features and some optional configuration.
We are almost using Import-Packages exclusively, using spring-dm to
configure most of our services ...
There are other features of the OSGi framework that we might want to mix
into discussion:
1) The config-admin service. This is an OSGi-managed persistent
configuration service. The blueprint service spec includes interactions
with the cm service to allow configuration properties to be injected
into created components. This is a bit like what happens with the
geronimo config substitutions today.
2) Lazy activation. Lazy activation allows a bundle to be started, but
sit in an idle state. On the first classload operation, the bundle will
go through the complete activation process. The Blueprint service add
additional support that allows services exported by the bundle to be
registered as available, but the service does not get created until the
first service request. This could allow some interesting delay
provisioning of subsystems to be implemented.
Rick
2009/3/17 Lin Sun <[email protected] <mailto:[email protected]>>
Rex,
If you follow the discussion closely, I think David was just saying
that he prefers to stay away from Require-Bundle for now, as the OSGi
specification doesn't recommend people to use it, along with the probs
people mentioned about it in the link I posted earlier.
I also found these links interesting -
http://www.osgi.org/blog/2008/06/jsr-277-and-import-package.html
http://ekkes-corner.blogspot.com/2008/06/catch-22-logging-with-osgi-frameworks.html
David,
Some comments regarding #2, its essential to know what
jars/bundles/plugins/modules are actually in your running system.
I think OSGi framework provides the ability to display the currently
running bundles, so there should be APIs to get that. For example,
you type "ss" in equinox console to get the list of installed bundles:
osgi> ss
Framework is launched.
id State Bundle
0 ACTIVE org.eclipse.osgi_3.4.2.R34x_v20080826-1230
14 ACTIVE org.osgi.impl.service.log_1.3.2.200902181055
17 RESOLVED org.osgi.impl.service.http_4.2.0.200902181209
18 INSTALLED org.osgi.test.cases.http_4.2.0.200902181210
OSGi framework also uses resolver to resolve bundles. For example,
if I want to install Bundle A to the framework, and Bundle imports
package AA, then when I install the bundle A, the OSGi framework uses
the resolver to find out if there is any bundle that exports package
AA. If so, bundle A will be marked as RESOLVED. Otherwise, Bundle A
will be marked as INSTALLED. If you search "resolver" in the OSGi
core spec, you'll see a couple of places that mention it.
I recently took a look at the new OSGi bundle repository spec (RFC
112). It talks about the concept of Resolver and the interface
Resolver It talks about scenarios where a user wants to install a
bundle (that uses Import-Package), the server should be able to pull
all its dependencies from the bundle repository (or repositories) on
the fly using the resolver. This seems something we would need for
geronimo.
Lin
On Tue, Mar 17, 2009 at 12:52 AM, Rex Wang <[email protected]
<mailto:[email protected]>> wrote:
> "At the moment I'm inclined to think that require-bundle is not
a workable
> solution for (2) and so we might as well use import-package plus
an osgi
> runtime that uses and requires explicit external dependency
information such
> as provided by maven or geronimo-plugin.xml to choose what
bundle to resolve
> to. "
>
> From my point of view, I am not quite like this "mix" version,
because we
> must maintain the related information in two different places,
that will
> absolutely increase geronimo's complexity and some sorts of
confusing on the
> dependency settings, not only to the developers but also the
users. I think
> one of the purpose that we adopt OSGi is to make our server
infrastructure
> "standardize" to the OSGi specification, but not to create a new
application
> model. Because this may lead to a non osgi compatiable bundle,
IIUC, any
> bundle that wanna be used in geronimo must re-write to provide the
> additional mvn-style information.
>
> Why do you think the require-bundle is not a workable solution
for (2) ?
>
>
> Rex.
>
>
>
> 2009/3/14 David Jencks <[email protected]
<mailto:[email protected]>>
>>
>> On Mar 13, 2009, at 9:43 AM, Rick McGuire wrote:
>>
>>> David Jencks wrote:
>>>>
>>>> I read the blog entry and discussion. The entire discussion is
>>>> predicated on the idea that osgi is close to ideal as-is and
we have no need
>>>> to consider any other point of view. If you step back a bit
I see two
>>>> things clearly acknowledged by everyone:
>>>>
>>>> 1. its useful to be able to know what classes are needed to
make a
>>>> jar/bundle/plugin/module work and which classes are expected
to be used
>>>> elsewhere
>>>> 2. its essential to know what jars/bundles/plugins/modules
are actually
>>>> in your running system
>>>>
>>>> In osgi-land, import-package and export-package supply (1), and
>>>> require-bundle sort of helps with (2) but AFAICT right now
doesn't support
>>>> "artifact aliasing"
>>>> In maven-land, the pom dependency tracking provides a pretty good
>>>> solution for (2), including some support for overriding
"requirements"
>>>> through exclusions, but it's single-classloader model doesn't
translate
>>>> directly into an app server or osgi runtime
>>>> In geronimo trunk we emphasize (2) and can actually assemble
working
>>>> servers using it, and have support for (1) (although its
mostly backwards
>>>> from osgi specifications)
>>>>
>>>> I'd say that in my (limited) experience osgi zealots
typically think
>>>> that (1) is essential and brush (2) under the carpet by
working in
>>>> constrained environments such as their eclipse workspace.
I'd say that our
>>>> experience with geronimo is that (1) is rarely needed if you
have a working
>>>> (2) (look at how many hidden-classes and non-overriable
classes filters are
>>>> in our poms -- none for the use of geronimo, and a few to
make deploying
>>>> applications that include the same jars as us work)
>>>>
>>>> The geronimo/maven approach to (2) is to include the dependency
>>>> information with the artifact. I'm not sure what
approach(es) osgi is
>>>> considering -- OBR appears to not consider bundling
dependency info with the
>>>> artifact but to have a completely external specification. I
don't know
>>>> about p2.... but since jason vanZyl seems to be looking at it
I'd guess it
>>>> is more maven friendly.
>>>>
>>>> If you don't bundle (2) with the artifacts then you need some
kind of
>>>> import-package to artifact map or resolution system. We sort
of have some
>>>> vestiges of this today: when you deploy a web app as a
geronimo plugin (or
>>>> export it from a server where it was deployed) it has picked
up dependencies
>>>> on jetty or tomcat based on which deployer you specified in
the plugin
>>>> project pom or which kind of server you deployed on. Another
example is
>>>> that the car-maven-plugin filters the view of the local maven
repo so only
>>>> the versions specified in the pom are visible to the geronimo
server we run
>>>> off the repo -- this allows you to build plugins for a 2.1.3
server even if
>>>> you have 2.2-SNAPSHOT artifacts locally and some of the
dependencies don't
>>>> specify the version required.
>>>>
>>>> I don't know where the best balance for geronimo lies here.
I certainly
>>>> think claiming all we need is import-package is shortchanging
most of our
>>>> experience in producing geronimo as a working server.
>>>
>>> But on the other hand, I'd hate to have not using just
Import-package as
>>> the starting point. Given how much it is assumed in the OSGi
world, it
>>> would be best to assume its use and only step outside of that
box once we've
>>> found the intractable problem that requires it. Starting
outside of those
>>> limits means we're abandoning the things OSGi does straight
off because
>>> their may be some places where the exception mechanisms are
required.
>>
>> Aren't you exhibiting exactly the same attitude as the blog
posters in
>> saying the (2) is not really a problem we need to consider?
Whereas all our
>> work in getting geronimo to actually work has been focussed on
solving (2).
>> If we ditch our working system for (2) we won't have a
server.... perhaps
>> ever. In terms of assembling a server, without (2) the space
of possible
>> bundles to resolve to is the entire maven central repo. ( I
anticipate that
>> any working server is going to be able to convert plain jars to
bundles on
>> the fly. If not, no one who is not osgi-obsessed will be
willing to use it)
>>
>> At the moment I'm inclined to think that require-bundle is not
a workable
>> solution for (2) and so we might as well use import-package
plus an osgi
>> runtime that uses and requires explicit external dependency
information such
>> as provided by maven or geronimo-plugin.xml to choose what
bundle to resolve
>> to. However until we get something working we won't know much
about whether
>> this or any proposal is a good or workable choice.
>>
>> I'm still waiting for news of a working osgi system that is
comparable in
>> scale to eclipse that primarily uses import-package.
>>
>> thanks
>> david jencks
>>
>>>
>>>
>>> Rick
>>>>
>>>> thanks
>>>> david jencks
>>>>
>>>> On Mar 13, 2009, at 7:10 AM, Lin Sun wrote:
>>>>
>>>>> I think I was not too clear below. I didn't mean to say
that I am in
>>>>> favor of Require-Bundle because it is a lot harder to come
up with the
>>>>> right Import-Package lists. What I meant was that the
reason why a
>>>>> lot of people are using Require-Bundle like David mentioned
in his
>>>>> early notes is probably because it is a lot easier to use.
>>>>>
>>>>> I personally had to spend quite some time to figure out the
prob I
>>>>> mentioned earlier - I was developing a bundle that needs to
import
>>>>> the javax.transaction package from the transaction in OSGi
bundle, but
>>>>> two bundles have it (the basic OSGi J2SE and the transaction
in OSGi
>>>>> bundle). I was able to resolve this using Import-Package
with the
>>>>> specific version of javax.transaction package that I need.
I just
>>>>> tried to switch to use Require-Bundle, that is to have my
bundle to
>>>>> depend on the transaction in OSGi bundle as it contains the
right
>>>>> version of the javax.transaction package I need, but my
bundle is
>>>>> broken completely due to CDNFE. I don't think the
Require-Bundle
>>>>> offers the fine grain control that I needed for my bundle
and I am
>>>>> sure Geronimo would have a lot more complicated bundles than
what I
>>>>> was developing.
>>>>>
>>>>> BTW, there's a good discussion here:
>>>>>
http://thhal.blogspot.com/2008/02/dependencies-and-package-imports.html
>>>>>
>>>>> - in particular in the first comment from Neil Bartlett and the
>>>>> limitations of Require-Bundle documented in the OSGi v 4.1
core spec
>>>>> (section 3.13.3).
>>>>>
>>>>> Lin
>>>>>
>>>>>
>>>>> On Thu, Mar 12, 2009 at 11:40 PM, Lin Sun
<[email protected] <mailto:[email protected]>> wrote:
>>>>>
>>>>>> Not sure about Require-Bundle. I personally has never used
it and I
>>>>>> never see it is being used in the OSGi repo.
Require-Bundle may not
>>>>>> offer the level of control that the Import-Package provides
but it is
>>>>>> probably a lot harder to come up with the right
Import-Package lists.
>>>>>> I think this scenario should work just fine if using
Import-Package.
>>>>>>
>>>>
>>>>
>>>
>>
>
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
