In Karaf, we have a simple provisioning mechanism called 'features'.
You can see an example at [1]
In its simpliest form, it's a list of urls pointing to OSGi bundles.
We usually use maven urls (which are real urls with a custom url
handler) so that we can download easily from configured maven
repo
On 11 mai 2011, at 18:46, Alex Karasulu wrote:
> On Wed, May 11, 2011 at 6:56 PM, Emmanuel Lecharny
> wrote:
> On 5/11/11 5:35 PM, Alex Karasulu wrote:
> Hi dev peeps,
>
> So after a long thread I just wanted to summarize the realizations and
> conclusions so we can set a clear direction for m
On Wed, May 11, 2011 at 6:56 PM, Emmanuel Lecharny wrote:
> On 5/11/11 5:35 PM, Alex Karasulu wrote:
>
>> Hi dev peeps,
>>
>> So after a long thread I just wanted to summarize the realizations and
>> conclusions so we can set a clear direction for managing the codec
>> extension
>> mechanism. I cr
On 5/11/11 5:35 PM, Alex Karasulu wrote:
Hi dev peeps,
So after a long thread I just wanted to summarize the realizations and
conclusions so we can set a clear direction for managing the codec extension
mechanism. I created a separate clean thread for this here with Guillaume's
core recommendati
Hi dev peeps,
So after a long thread I just wanted to summarize the realizations and
conclusions so we can set a clear direction for managing the codec extension
mechanism. I created a separate clean thread for this here with Guillaume's
core recommendation following.
For the sake of speed I will
On Wed, May 11, 2011 at 6:03 PM, Emmanuel Lecharny wrote:
> On 5/11/11 4:55 PM, Alex Karasulu wrote:
>
>> The plugin bundles do not contain any services. The activators of the
>> plugin
>> bundles simply register classes in the plugin bundle with the main service
>> exported by the host applicatio
On Wed, May 11, 2011 at 6:03 PM, Guillaume Nodet wrote:
> What we've done for Camel for example is to allow those libraries to
> leverage OSGi if deployed in OSGi and default to a basic mode in other
> cases.
>
> For Camel, components can be create by users (though I guess it's the
> same here,
What we've done for Camel for example is to allow those libraries to
leverage OSGi if deployed in OSGi and default to a basic mode in other
cases.
For Camel, components can be create by users (though I guess it's the
same here, not average users). Camel can discover components using a
pluggable
On 5/11/11 4:55 PM, Alex Karasulu wrote:
The plugin bundles do not contain any services. The activators of the plugin
bundles simply register classes in the plugin bundle with the main service
exported by the host application: the codec factory service.
Looking at this big fat mess a good rule o
On Wed, May 11, 2011 at 5:14 PM, Guillaume Nodet wrote:
> On Wed, May 11, 2011 at 15:42, Alex Karasulu wrote:
> > Thanks Guillaume for your thoughts. Responding in this post to both of
> you
> > in line ...
> >
> > On Wed, May 11, 2011 at 12:19 PM, Emmanuel Lecharny >
> > wrote:
> >>
> >> On 5/
On 5/11/11 4:16 PM, Guillaume Nodet wrote:
Indeed, that's a nice trick.
If I understand the code correctly, you need to make sure the
exception is reported back to the current thread, else you the user
won't even notice any problem (well, in the log of course but no
exception).
Yes. It's just a
On 5/11/11 4:08 PM, Alex Karasulu wrote:
On Wed, May 11, 2011 at 4:56 PM, Emmanuel Lécharnywrote:
On 5/11/11 3:42 PM, Alex Karasulu wrote:
Usually, we are just hiding it if the user does not have its own OSGi
container.
Please clarify.
The user does not know we embed and start Felix. Fo
And btw, disabling the bundle cache by using reference:xxx urls in the
activator should help to speed up the boot time and avoid most of the
disk writes (though not all I guess).
On Wed, May 11, 2011 at 16:14, Guillaume Nodet wrote:
> On Wed, May 11, 2011 at 15:42, Alex Karasulu wrote:
>> Thanks
Indeed, that's a nice trick.
If I understand the code correctly, you need to make sure the
exception is reported back to the current thread, else you the user
won't even notice any problem (well, in the log of course but no
exception).
On Wed, May 11, 2011 at 15:56, Emmanuel Lécharny wrote:
> On
On Wed, May 11, 2011 at 15:42, Alex Karasulu wrote:
> Thanks Guillaume for your thoughts. Responding in this post to both of you
> in line ...
>
> On Wed, May 11, 2011 at 12:19 PM, Emmanuel Lecharny
> wrote:
>>
>> On 5/11/11 10:47 AM, Guillaume Nodet wrote:
>>>
>>> Just my thoughts, as I had a di
On Wed, May 11, 2011 at 4:56 PM, Emmanuel Lécharny wrote:
> On 5/11/11 3:42 PM, Alex Karasulu wrote:
>
>> Usually, we are just hiding it if the user does not have its own OSGi
>>> container.
>>>
>>>
>>> Please clarify.
>>
>
> The user does not know we embed and start Felix. For him, it's 'hidden'
On 5/11/11 3:42 PM, Alex Karasulu wrote:
Usually, we are just hiding it if the user does not have its own OSGi
container.
Please clarify.
The user does not know we embed and start Felix. For him, it's 'hidden'.
Btw, the pb I was trying to solve (ie, the Felix EventDispatchQueue
thread was
Thanks Guillaume for your thoughts. Responding in this post to both of you
in line ...
On Wed, May 11, 2011 at 12:19 PM, Emmanuel Lecharny wrote:
> On 5/11/11 10:47 AM, Guillaume Nodet wrote:
>
>> Just my thoughts, as I had a discussion with Emmanuel yesterday on
>> this subject. I must admit I
On 5/11/11 10:47 AM, Guillaume Nodet wrote:
Just my thoughts, as I had a discussion with Emmanuel yesterday on
this subject. I must admit I don't know directory very much, so maybe
I'm off track.
Unless I misunderstood, the OSGi container is only used for
classloading and want to hide it. Howe
Just my thoughts, as I had a discussion with Emmanuel yesterday on
this subject. I must admit I don't know directory very much, so maybe
I'm off track.
Unless I misunderstood, the OSGi container is only used for
classloading and want to hide it. However, if you try to hide the
OSGi stuff, the fi
On 5/11/11 7:09 AM, Alex Karasulu wrote:
On Tue, May 10, 2011 at 3:57 PM, Kiran Ayyagariwrote:
On Tue, May 10, 2011 at 5:27 PM, Emmanuel Lecharny
wrote:
Hi guys,
following the bug opened by Daniel Fisher
(https://issues.apache.org/jira/browse/DIRSHARED-125), I think we need
to
modify the wa
On Tue, May 10, 2011 at 3:57 PM, Kiran Ayyagari wrote:
> On Tue, May 10, 2011 at 5:27 PM, Emmanuel Lecharny
> wrote:
> > Hi guys,
> >
> > following the bug opened by Daniel Fisher
> > (https://issues.apache.org/jira/browse/DIRSHARED-125), I think we need
> to
> > modify the way we use OSGi and Fe
On Tue, May 10, 2011 at 5:27 PM, Emmanuel Lecharny wrote:
> Hi guys,
>
> following the bug opened by Daniel Fisher
> (https://issues.apache.org/jira/browse/DIRSHARED-125), I think we need to
> modify the way we use OSGi and Felix in shared.
>
> Right now, if the user has already an OSGi container
Hi guys,
following the bug opened by Daniel Fisher
(https://issues.apache.org/jira/browse/DIRSHARED-125), I think we need
to modify the way we use OSGi and Felix in shared.
Right now, if the user has already an OSGi container running, we use it.
Otherwise, we start Felix in StandaloneLdapCod
24 matches
Mail list logo
