So it really seems like we need a way to incrementally modify at least 
jre.properties and possibly the boot delegation property.

It isn't possible to use a fragment bundle with the framework as host to change 
the (effective) jre.properties, is it?

If that won't work maybe we can merge property files something like

jre-<BSN>.properties merges with jre.properties.

An entry like

jdk6=javax.foo,\
!javax.bar,\
!javax.baz

has the result of adding the javax.foo to the jdk6 exports and removing 
javax.bar and javax.baz.

I think I saw someone claim recently that for the bootdelegation property the 
framework already understands entries like !com.sun.xml.bind so maybe for that 
property we can just merge everything together into one string.

thanks
david jencks

On Jul 12, 2011, at 9:09 AM, Guillaume Nodet wrote:

> I disagree with that.  Jaxb, stax and other libraries provided by the JRE
> work in OSGi afaik with the JRE implementation.  People have complained in
> the past that the default karaf behavior did not allow them to leverage
> those technologies provided by the JRE, that's why we changed the exported
> packages to reflect what the JRE provides.   For all the OSGi users that
> don't use CXF and don't require a specific stax implementation or something
> like that, I'd like to keep the current behavior.
> 
> Note that when you get to the borders of the OSGi specs, everything is not
> clearly defined.   Another problem is caused by the fact that the packages
> provided by the JRE are not versioned.   I think the current behavior is the
> best one for a generic container, but I agree we have to tweak it for CXF or
> ServiceMix, so be it, I think that's the responsibility of those projects to
> do it, though Karaf could provided a good way to allow those modifications.
> 
> On Tue, Jul 12, 2011 at 13:42, Daniel Kulp <dk...@apache.org> wrote:
> 
>> On Tuesday, July 12, 2011 7:28:57 AM Andreas Pieber wrote:
>>> Hey David,
>>> 
>>> The problem isn't during assambling but to install e.g. CXF
>>> afterwards. Please start an empty Karaf 3.x and try to install the CXF
>>> features file. To make it run you have to modify the jre.properties
>>> and the bootdelegation to get it up running. And there is no way to do
>>> this automatically from your .kar/features.xml right now :(
>> 
>> That should be changing in CXF 2.4.2.    The last holdup was a bug in
>> Neethi's
>> OSGi manifest, but a new version of Neethi is under vote now.  With that,
>> you
>> should be able to take a clean Karaf and deploy CXF.
>> 
>> THAT said,  IMO, the karaf jre.properties file should exclude the packages
>> that are known not to work in karaf.  jaxb-api, stax-api, saaj-api, etc....
>> Karaf should then contain a set of "API" features to install the proper
>> OSGi
>> versions of said API's.
>> 
>> 
>> Dan
>> 
>> 
>> 
>>> 
>>> Kind regards,
>>> Andreas
>>> 
>>> On Tue, Jul 12, 2011 at 12:05 AM, David Jencks <david_jen...@yahoo.com>
>> wrote:
>>>> On Jul 11, 2011, at 5:26 AM, Andreas Pieber wrote:
>>>> <big snip>
>>>> 
>>>>> * Karaf profiles & Kar files (IMHO this is one of the most important
>>>>> features for 3.x and not present in the issues by now; there had been
>>>>> considerable work on this by David, but still, we're missing a
>>>>> possibility to start e.g. CXF without modifying some files in etc)
>>>> 
>>>> I'm really hoping that 3.0.0 will have the minimal and standard
>>>> assemblies created using kars/features rather than the old style
>>>> maven-assembly-plugin.  I haven't been able to work on this for a while
>>>> but i thought I left it in a state as least as functional as the
>>>> old-style servers.  The only bit I recall as missing is the legal
>>>> files.
>>>> 
>>>> What are you looking for to start e.g. cxf?  IIRC you can assemble a
>>>> server including a cxf feature as a boot feature, or add it in later as
>>>> a regular feature....
>>>> 
>>>> thanks
>>>> david jencks
>> --
>> Daniel Kulp
>> dk...@apache.org
>> http://dankulp.com/blog
>> Talend - http://www.talend.com
>> 
> 
> 
> 
> -- 
> ------------------------
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com

Reply via email to