On Jul 12, 2011, at 2:28 PM, Daniel Kulp wrote:

> On Tuesday, July 12, 2011 12:41:18 PM David Jencks wrote:
>> I probably didn't explain my idea very well....
>> 
>> I was thinking that the base jre.properties might have
>> 
>> javax.xml.bind
>> 
>> in the jdk6 entry in it to indicate that it's using the jaxb 2.1 api and
>> implementation shipped with java 6.  If you needed say osgi-friendly jaxb
>> 2.2 api and the separate snoracle implementation you could have a kar
>> indicating the geronimo jaxb 2.2 spec and (smx?) bundlized snoracle 2.2
>> jaxb impl together with a "patch" properties with
>> 
>> !javax.xml.bind
>> 
>> which would have the effect of removing the entry from the jdk6 entry.
>> 
>> So the purpose here is to provide a way to modify the effective
>> jre.properties by installing a .kar file rather than editing it by hand.
> 
> The question I have is how possible is it to do that without restarting 
> Karaf, 
> or would restarting Karaf after installing the "jaxb kar" be required?  Would 
> there be an impact on existing things running using jaxb?   

I don't see how its plausible to make changes in what the framework exports 
without restarting karaf.  Can you refresh the framework?  Is this different 
from restarting?

I actually hope or expect we'll make it so easy to assembly your own custom 
server with maven that the normal use case will be that rather than installing 
stuff into a running instance of someone else's idea of what karaf should be.

david jencks

> 
> Dan
> 
> 
> 
> 
>> 
>> thanks
>> david jencks
>> 
>> On Jul 12, 2011, at 12:33 PM, mikevan wrote:
>>> David,
>>> 
>>> From my experience, the only time I need to use a negation operator in
>>> jre.properties is if I want to explictly show users (folks reading the
>>> jre.properties file) that my implementation of Karaf does not use that
>>> package.  If I don't want a package from the jre to be used in my
>>> instance of Karaf, I simply exclude that package from the list of
>>> packages exported into karaf.
>>> 
>>> Feel free to correct me if I'm wrong. :-)
>>> 
>>> David Jencks wrote:
>>>> 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 &lt;dk...@apache.org&gt;
>>>>> 
>>>>> 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
>>>>>>> &lt;david_jen...@yahoo.com&gt;
>>>>>> 
>>>>>> 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
>>> 
>>> -----
>>> Mike Van
>>> --
>>> View this message in context:
>>> http://karaf.922171.n3.nabble.com/PROPOSAL-Towards-Karaf-3-0-0-tp315876
>>> 3p3163632.html Sent from the Karaf - Dev mailing list archive at
>>> Nabble.com.
> -- 
> Daniel Kulp
> dk...@apache.org
> http://dankulp.com/blog
> Talend - http://www.talend.com

Reply via email to