On Wed, May 11, 2011 at 4:56 PM, Emmanuel Lécharny <elecha...@apache.org>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'.
>
>
Well it's not immediately apparent since we don't have documentation for
this but eventually we will expose that this is what is actually taking
place in order to present this feature of being able to use codec extensions
for user defined controls and extended operations.
I know understand why you mean hidden. However this is not our agenda,
meaning to hide this implementation detail since those extending will have
to create their own OSGi bundles for extension points.
> Btw, the pb I was trying to solve (ie, the Felix EventDispatchQueue thread
> was still running even if we quit the application) has a nice workaround.
> The pb was that the felix thread was a User thread, not a Daemon thread,
> thus needed to be stopped explicitly. What would have been good is to be
> able to make this thread a Daemon thread, but as it's created internally of
> Felix, there was no way to do that.
>
> Hopefully, Karl and Richard mentionned that if you start a thread from a
> daemon thread, then the inner thread will inheritate it's parent status. So
> I started felix inside a Daemon thread, and it did the trick :
>
> Thread felixThread = new Thread(new Runnable() {
> public void run()
> {
> try
> {
> felix.start();
> }
> catch ( BundleException e )
> {
> String message = "Failed to start embedded felix
> instance: " + e.getMessage();
> LOG.error( message, e );
> throw new RuntimeException( message, e );
> }
> }
> }, "FelixThread");
>
> felixThread.setDaemon( true );
> felixThread.start();
>
> instead of :
>
> felix.start();
>
Awesome! That solves the thread kill issue. Did you commit this?
Thanks,
Alex
