Re: JFX as an OSGi service?

[Rahman USTA]

Hi Stephen;

Thanks for the documentationing it.
21 Şub 2016 21:23 tarihinde "Stephen Winnall"  yazdı:

> I’ve now got a subclass  of javafx.application.Application that runs as an
> OSGi service and references other OSGi services under Java 8SE. I’ve tried
> to document it on Github (see https://github.com/winnall/OSGiJavaFXUsage)
> for the benefit of posterity.
>
> Let me know if there are any mistakes or improvements required in the -
> sparse - documentation. I’m also not very good at Git :-(
>
> Thanks to Erik de Rijcke, Maurice, Anirvan Sardar and Kevin Rushforth for
> their comments, all of which guided me - bouncing off the walls - to the
> goal.
>
> Steve
>
>
> > On 20 Feb 2016, at 20:37, Erik De Rijcke 
> wrote:
> >
> > This way only the app will be accessible by other components through the
> service registry. The app itself can not have any @reference because it it
> is javafx itself that instantiates the app object and not the osgi
> declarative services framework (which also takes care of injecting your
> dependencies).
> >
> > The way to work around this in java8 is to take the approach I describe,
> as far as I know that is the only workaround to get scr and javafx glued
> together.
> >
> > In javafx 9 this would be fixed by having your service component
> implement runnable and use the api described by kevin, as you can reuse the
> object created by the osgi framework.
> >
> > On Sat, Feb 20, 2016 at 3:27 PM, Maurice > wrote:
> > That is why the bundle activator creates a bundle-singleton of itself,
> that way the app can access the OSGi world. In my case to register itself
> as a service.
> >
> >
> > @Override
> > public void start(Stage primaryStage) throws Exception {
> > 
> > primaryStage.show();
> >
> > Dictionary properties = createDictionary();
> > BundleContext bundleContext =
> UdooActivator.bundleActivator().getBundleContext();
> >
> bundleContext.registerService(com.cuhka.home.application.Application.class,
> this, properties);
> > }
> >
> > Maurice.
> > Op 20-02-16 om 15:08 schreef Stephen Winnall:
> >
> > Hi Maurice
> >
> > I have done something similar, but it has the following drawback in my
> view: the class launched (Udoo15App in your case) does not run under OSGi
> control, so it has no access to OSGi bundles or services, nor is it
> accessible by them. If you don’t need that, you're OK. But I need that
> class to be part of the OSGi world because other bundles/services are going
> to add parts to the UI as they are instantiated.
> >
> > Steve
> >
> > On 20 Feb 2016, at 14:33, Maurice >
> wrote:
> >
> >
> > For my OSGi based JavaFX solution on the Udoo Quad (ARM based Linux) I
> created a service that publishes the application in the context.The
> application does as little as possible. It sets up the primary stage as
> fullscreen and puts a stackpane in it. Initially the stackpane displays a
> 'boot logo', until the actual desktop bundle is started and registered with
> the application. Note that you have to start the application on a separate
> thread, as the thread will be blocked.
> >
> > On Java 8 this means that although the application bundle can't be
> updated in a running OSGi container, but that is why the desktop exists. On
> startup it registers itself, and thus the application content, with the
> application, and when it is stopped it removes the content from the
> application. The application has thus rarely to be updated itself.
> >
> > Regards,
> > Maurice.
> >
> >
> >
> > public class UdooActivator implements BundleActivator {
> > private static UdooActivator activator;
> > private BundleContext context;
> >
> > static UdooActivator bundleActivator() {
> > return requireNonNull(activator, "activator not set");
> > }
> >
> > @Override
> > public void start(BundleContext context) throws Exception {
> > this.context = context;
> > activator = this;
> > new Thread(() -> Application.launch(Udoo15App.class), "JavaFX
> Desktop launcher").start();
> > }
> >
> > @Override
> > public void stop(BundleContext context) throws Exception {
> > Platform.exit();
> > }
> >
> > public BundleContext getBundleContext() {
> > return context;
> > }
> > }
> >
> > Op 20-02-16 om 01:28 schreef Stephen Winnall:
> > Anirvan, Kevin
> >
> > Thanks for this.
> >
> > I’m an expert neither in JavaFX nor in OSGi, but I think the basis of
> the JavaFX/OSGi incompatibility is control. To work with OSGi, JavaFX has
> to relinquish control of its startup sequence to OSGi in such a way that
> javafx.application.Application (or its proxy) is instantiated by OSGi and
> submits to OSGi’s bundle/service lifecycle. AN OSGi expert can probably
> formulate this better…
> >
> > Platform.startup(runnable) /might/ do it. 

Re: JFX as an OSGi service?

[Stephen Winnall]

I’ve now got a subclass  of javafx.application.Application that runs as an OSGi 
service and references other OSGi services under Java 8SE. I’ve tried to 
document it on Github (see https://github.com/winnall/OSGiJavaFXUsage) for the 
benefit of posterity.

Let me know if there are any mistakes or improvements required in the - sparse 
- documentation. I’m also not very good at Git :-(

Thanks to Erik de Rijcke, Maurice, Anirvan Sardar and Kevin Rushforth for their 
comments, all of which guided me - bouncing off the walls - to the goal.

Steve


> On 20 Feb 2016, at 20:37, Erik De Rijcke  wrote:
> 
> This way only the app will be accessible by other components through the 
> service registry. The app itself can not have any @reference because it it is 
> javafx itself that instantiates the app object and not the osgi declarative 
> services framework (which also takes care of injecting your dependencies).
> 
> The way to work around this in java8 is to take the approach I describe, as 
> far as I know that is the only workaround to get scr and javafx glued 
> together.
> 
> In javafx 9 this would be fixed by having your service component implement 
> runnable and use the api described by kevin, as you can reuse the object 
> created by the osgi framework.
> 
> On Sat, Feb 20, 2016 at 3:27 PM, Maurice  > wrote:
> That is why the bundle activator creates a bundle-singleton of itself, that 
> way the app can access the OSGi world. In my case to register itself as a 
> service.
> 
> 
> @Override
> public void start(Stage primaryStage) throws Exception {
> 
> primaryStage.show();
> 
> Dictionary properties = createDictionary();
> BundleContext bundleContext = 
> UdooActivator.bundleActivator().getBundleContext();
> bundleContext.registerService(com.cuhka.home.application.Application.class, 
> this, properties);
> }
> 
> Maurice.
> Op 20-02-16 om 15:08 schreef Stephen Winnall:
> 
> Hi Maurice
> 
> I have done something similar, but it has the following drawback in my view: 
> the class launched (Udoo15App in your case) does not run under OSGi control, 
> so it has no access to OSGi bundles or services, nor is it accessible by 
> them. If you don’t need that, you're OK. But I need that class to be part of 
> the OSGi world because other bundles/services are going to add parts to the 
> UI as they are instantiated.
> 
> Steve
> 
> On 20 Feb 2016, at 14:33, Maurice > 
> wrote:
> 
> 
> For my OSGi based JavaFX solution on the Udoo Quad (ARM based Linux) I 
> created a service that publishes the application in the context.The 
> application does as little as possible. It sets up the primary stage as 
> fullscreen and puts a stackpane in it. Initially the stackpane displays a 
> 'boot logo', until the actual desktop bundle is started and registered with 
> the application. Note that you have to start the application on a separate 
> thread, as the thread will be blocked.
> 
> On Java 8 this means that although the application bundle can't be updated in 
> a running OSGi container, but that is why the desktop exists. On startup it 
> registers itself, and thus the application content, with the application, and 
> when it is stopped it removes the content from the application. The 
> application has thus rarely to be updated itself.
> 
> Regards,
> Maurice.
> 
> 
> 
> public class UdooActivator implements BundleActivator {
> private static UdooActivator activator;
> private BundleContext context;
> 
> static UdooActivator bundleActivator() {
> return requireNonNull(activator, "activator not set");
> }
> 
> @Override
> public void start(BundleContext context) throws Exception {
> this.context = context;
> activator = this;
> new Thread(() -> Application.launch(Udoo15App.class), "JavaFX Desktop 
> launcher").start();
> }
> 
> @Override
> public void stop(BundleContext context) throws Exception {
> Platform.exit();
> }
> 
> public BundleContext getBundleContext() {
> return context;
> }
> }
> 
> Op 20-02-16 om 01:28 schreef Stephen Winnall:
> Anirvan, Kevin
> 
> Thanks for this.
> 
> I’m an expert neither in JavaFX nor in OSGi, but I think the basis of the 
> JavaFX/OSGi incompatibility is control. To work with OSGi, JavaFX has to 
> relinquish control of its startup sequence to OSGi in such a way that 
> javafx.application.Application (or its proxy) is instantiated by OSGi and 
> submits to OSGi’s bundle/service lifecycle. AN OSGi expert can probably 
> formulate this better…
> 
> Platform.startup(runnable) /might/ do it. Platform.launch(class) doesn’t 
> because the object thereby instantiated is always under the control of JavaFX 
> - and thus not of OSGi.
> 
> I’m not comfortable using JFXPanel: if I wanted to use Swing I wouldn’t be 
> trying to use JavaFX. But 

Re: JFX as an OSGi service?

[Erik De Rijcke]

This way only the app will be accessible by other components through the
service registry. The app itself can not have any @reference because it it
is javafx itself that instantiates the app object and not the osgi
declarative services framework (which also takes care of injecting your
dependencies).

The way to work around this in java8 is to take the approach I describe, as
far as I know that is the only workaround to get scr and javafx glued
together.

In javafx 9 this would be fixed by having your service component implement
runnable and use the api described by kevin, as you can reuse the object
created by the osgi framework.

On Sat, Feb 20, 2016 at 3:27 PM, Maurice  wrote:

> That is why the bundle activator creates a bundle-singleton of itself,
> that way the app can access the OSGi world. In my case to register itself
> as a service.
>
>
> @Override
> public void start(Stage primaryStage) throws Exception {
> 
> primaryStage.show();
>
> Dictionary properties = createDictionary();
> BundleContext bundleContext =
> UdooActivator.bundleActivator().getBundleContext();
> bundleContext.registerService(com.cuhka.home.application.Application.class,
> this, properties);
> }
>
> Maurice.
> Op 20-02-16 om 15:08 schreef Stephen Winnall:
>
> Hi Maurice
>>
>> I have done something similar, but it has the following drawback in my
>> view: the class launched (Udoo15App in your case) does not run under OSGi
>> control, so it has no access to OSGi bundles or services, nor is it
>> accessible by them. If you don’t need that, you're OK. But I need that
>> class to be part of the OSGi world because other bundles/services are going
>> to add parts to the UI as they are instantiated.
>>
>> Steve
>>
>> On 20 Feb 2016, at 14:33, Maurice  wrote:
>>>
>>>
>>> For my OSGi based JavaFX solution on the Udoo Quad (ARM based Linux) I
>>> created a service that publishes the application in the context.The
>>> application does as little as possible. It sets up the primary stage as
>>> fullscreen and puts a stackpane in it. Initially the stackpane displays a
>>> 'boot logo', until the actual desktop bundle is started and registered with
>>> the application. Note that you have to start the application on a separate
>>> thread, as the thread will be blocked.
>>>
>>> On Java 8 this means that although the application bundle can't be
>>> updated in a running OSGi container, but that is why the desktop exists. On
>>> startup it registers itself, and thus the application content, with the
>>> application, and when it is stopped it removes the content from the
>>> application. The application has thus rarely to be updated itself.
>>>
>>> Regards,
>>> Maurice.
>>>
>>>
>>>
>>> public class UdooActivator implements BundleActivator {
>>> private static UdooActivator activator;
>>> private BundleContext context;
>>>
>>> static UdooActivator bundleActivator() {
>>> return requireNonNull(activator, "activator not set");
>>> }
>>>
>>> @Override
>>> public void start(BundleContext context) throws Exception {
>>> this.context = context;
>>> activator = this;
>>> new Thread(() -> Application.launch(Udoo15App.class), "JavaFX
>>> Desktop launcher").start();
>>> }
>>>
>>> @Override
>>> public void stop(BundleContext context) throws Exception {
>>> Platform.exit();
>>> }
>>>
>>> public BundleContext getBundleContext() {
>>> return context;
>>> }
>>> }
>>>
>>> Op 20-02-16 om 01:28 schreef Stephen Winnall:
>>>
 Anirvan, Kevin

 Thanks for this.

 I’m an expert neither in JavaFX nor in OSGi, but I think the basis of
 the JavaFX/OSGi incompatibility is control. To work with OSGi, JavaFX has
 to relinquish control of its startup sequence to OSGi in such a way that
 javafx.application.Application (or its proxy) is instantiated by OSGi and
 submits to OSGi’s bundle/service lifecycle. AN OSGi expert can probably
 formulate this better…

 Platform.startup(runnable) /might/ do it. Platform.launch(class)
 doesn’t because the object thereby instantiated is always under the control
 of JavaFX - and thus not of OSGi.

 I’m not comfortable using JFXPanel: if I wanted to use Swing I wouldn’t
 be trying to use JavaFX. But thank you for the hint.

 Steve

 On 19 Feb 2016, at 16:41, Kevin Rushforth
> wrote:
>
> And for JDK 9 there is now:
>
>  Platform.startup(Runnable);
>
> -- Kevin
>
>
> Anirvan Sarkar wrote:
>
>> Hi Stephen,
>>
>> FYI, there is another way of initializing JavaFX runtime. Just use:
>>
>> new JFXPanel();
>>
>> It is documented[1] that FX runtime is initialized when the first
>> JFXPanel
>> instance is constructed.
>>
>> Also JavaFX 9 will provide an official API to start 

Re: JFX as an OSGi service?

[Maurice]

I make sure that the application is basically only the primary stage, 
therefore it only needs to publish itself. All other UI and business 
logic is done by other bundles.


Op 20-02-16 om 15:50 schreef Stephen Winnall:
I have been trying a similar approach. I’m using declarative services 
and I have some @References  to other services in the Application, but 
I haven’t managed to get these instantiated. Do you have an approach 
for that? I suppose I can just write some code and instantiate them 
manually…


Steve

Re: JFX as an OSGi service?

[Stephen Winnall]

I have been trying a similar approach. I’m using declarative services and I 
have some @References  to other services in the Application, but I haven’t 
managed to get these instantiated. Do you have an approach for that? I suppose 
I can just write some code and instantiate them manually…

Steve

> On 20 Feb 2016, at 15:27, Maurice  wrote:
> 
> That is why the bundle activator creates a bundle-singleton of itself, that 
> way the app can access the OSGi world. In my case to register itself as a 
> service.
> 
> 
> @Override
> public void start(Stage primaryStage) throws Exception {
> 
> primaryStage.show();
> 
> Dictionary properties = createDictionary();
> BundleContext bundleContext = 
> UdooActivator.bundleActivator().getBundleContext();
> 
> bundleContext.registerService(com.cuhka.home.application.Application.class, 
> this, properties);
> }
> 
> Maurice.
> Op 20-02-16 om 15:08 schreef Stephen Winnall:
>> Hi Maurice
>> 
>> I have done something similar, but it has the following drawback in my view: 
>> the class launched (Udoo15App in your case) does not run under OSGi control, 
>> so it has no access to OSGi bundles or services, nor is it accessible by 
>> them. If you don’t need that, you're OK. But I need that class to be part of 
>> the OSGi world because other bundles/services are going to add parts to the 
>> UI as they are instantiated.
>> 
>> Steve
>> 
>>> On 20 Feb 2016, at 14:33, Maurice   
>>> wrote:
>>> 
>>> 
>>> For my OSGi based JavaFX solution on the Udoo Quad (ARM based Linux) I 
>>> created a service that publishes the application in the context.The 
>>> application does as little as possible. It sets up the primary stage as 
>>> fullscreen and puts a stackpane in it. Initially the stackpane displays a 
>>> 'boot logo', until the actual desktop bundle is started and registered with 
>>> the application. Note that you have to start the application on a separate 
>>> thread, as the thread will be blocked.
>>> 
>>> On Java 8 this means that although the application bundle can't be updated 
>>> in a running OSGi container, but that is why the desktop exists. On startup 
>>> it registers itself, and thus the application content, with the 
>>> application, and when it is stopped it removes the content from the 
>>> application. The application has thus rarely to be updated itself.
>>> 
>>> Regards,
>>> Maurice.
>>> 
>>> 
>>> 
>>> public class UdooActivator implements BundleActivator {
>>>private static UdooActivator activator;
>>>private BundleContext context;
>>> 
>>>static UdooActivator bundleActivator() {
>>>return requireNonNull(activator, "activator not set");
>>>}
>>> 
>>>@Override
>>>public void start(BundleContext context) throws Exception {
>>>this.context = context;
>>>activator = this;
>>>new Thread(() -> Application.launch(Udoo15App.class), "JavaFX 
>>> Desktop launcher").start();
>>>}
>>> 
>>>@Override
>>>public void stop(BundleContext context) throws Exception {
>>>Platform.exit();
>>>}
>>> 
>>>public BundleContext getBundleContext() {
>>>return context;
>>>}
>>> }
>>> 
>>> Op 20-02-16 om 01:28 schreef Stephen Winnall:
 Anirvan, Kevin
 
 Thanks for this.
 
 I’m an expert neither in JavaFX nor in OSGi, but I think the basis of the 
 JavaFX/OSGi incompatibility is control. To work with OSGi, JavaFX has to 
 relinquish control of its startup sequence to OSGi in such a way that 
 javafx.application.Application (or its proxy) is instantiated by OSGi and 
 submits to OSGi’s bundle/service lifecycle. AN OSGi expert can probably 
 formulate this better…
 
 Platform.startup(runnable) /might/ do it. Platform.launch(class) doesn’t 
 because the object thereby instantiated is always under the control of 
 JavaFX - and thus not of OSGi.
 
 I’m not comfortable using JFXPanel: if I wanted to use Swing I wouldn’t be 
 trying to use JavaFX. But thank you for the hint.
 
 Steve
 
> On 19 Feb 2016, at 16:41, Kevin Rushforth 
>   wrote:
> 
> And for JDK 9 there is now:
> 
> Platform.startup(Runnable);
> 
> -- Kevin
> 
> 
> Anirvan Sarkar wrote:
>> Hi Stephen,
>> 
>> FYI, there is another way of initializing JavaFX runtime. Just use:
>> 
>> new JFXPanel();
>> 
>> It is documented[1] that FX runtime is initialized when the first 
>> JFXPanel
>> instance is constructed.
>> 
>> Also JavaFX 9 will provide an official API to start the FX platform [2] 
>> [3].
>> 
>> 
>> [1]
>> https://docs.oracle.com/javase/8/javafx/api/javafx/application/Platform.html#runLater-java.lang.Runnable
>>  
>> 

Re: JFX as an OSGi service?

[Maurice]

That is why the bundle activator creates a bundle-singleton of itself, 
that way the app can access the OSGi world. In my case to register 
itself as a service.



@Override
public void start(Stage primaryStage) throws Exception {

primaryStage.show();

Dictionary properties = createDictionary();
BundleContext bundleContext = 
UdooActivator.bundleActivator().getBundleContext();
bundleContext.registerService(com.cuhka.home.application.Application.class, 
this, properties);

}

Maurice.
Op 20-02-16 om 15:08 schreef Stephen Winnall:

Hi Maurice

I have done something similar, but it has the following drawback in my view: 
the class launched (Udoo15App in your case) does not run under OSGi control, so 
it has no access to OSGi bundles or services, nor is it accessible by them. If 
you don’t need that, you're OK. But I need that class to be part of the OSGi 
world because other bundles/services are going to add parts to the UI as they 
are instantiated.

Steve


On 20 Feb 2016, at 14:33, Maurice  wrote:


For my OSGi based JavaFX solution on the Udoo Quad (ARM based Linux) I created 
a service that publishes the application in the context.The application does as 
little as possible. It sets up the primary stage as fullscreen and puts a 
stackpane in it. Initially the stackpane displays a 'boot logo', until the 
actual desktop bundle is started and registered with the application. Note that 
you have to start the application on a separate thread, as the thread will be 
blocked.

On Java 8 this means that although the application bundle can't be updated in a 
running OSGi container, but that is why the desktop exists. On startup it 
registers itself, and thus the application content, with the application, and 
when it is stopped it removes the content from the application. The application 
has thus rarely to be updated itself.

Regards,
Maurice.



public class UdooActivator implements BundleActivator {
private static UdooActivator activator;
private BundleContext context;

static UdooActivator bundleActivator() {
return requireNonNull(activator, "activator not set");
}

@Override
public void start(BundleContext context) throws Exception {
this.context = context;
activator = this;
new Thread(() -> Application.launch(Udoo15App.class), "JavaFX Desktop 
launcher").start();
}

@Override
public void stop(BundleContext context) throws Exception {
Platform.exit();
}

public BundleContext getBundleContext() {
return context;
}
}

Op 20-02-16 om 01:28 schreef Stephen Winnall:

Anirvan, Kevin

Thanks for this.

I’m an expert neither in JavaFX nor in OSGi, but I think the basis of the 
JavaFX/OSGi incompatibility is control. To work with OSGi, JavaFX has to 
relinquish control of its startup sequence to OSGi in such a way that 
javafx.application.Application (or its proxy) is instantiated by OSGi and 
submits to OSGi’s bundle/service lifecycle. AN OSGi expert can probably 
formulate this better…

Platform.startup(runnable) /might/ do it. Platform.launch(class) doesn’t 
because the object thereby instantiated is always under the control of JavaFX - 
and thus not of OSGi.

I’m not comfortable using JFXPanel: if I wanted to use Swing I wouldn’t be 
trying to use JavaFX. But thank you for the hint.

Steve


On 19 Feb 2016, at 16:41, Kevin Rushforth  wrote:

And for JDK 9 there is now:

 Platform.startup(Runnable);

-- Kevin


Anirvan Sarkar wrote:

Hi Stephen,

FYI, there is another way of initializing JavaFX runtime. Just use:

new JFXPanel();

It is documented[1] that FX runtime is initialized when the first JFXPanel
instance is constructed.

Also JavaFX 9 will provide an official API to start the FX platform [2] [3].


[1]
https://docs.oracle.com/javase/8/javafx/api/javafx/application/Platform.html#runLater-java.lang.Runnable
  
-
[2]https://bugs.openjdk.java.net/browse/JDK-8090585  

[3]
http://download.java.net/jdk9/jfxdocs/javafx/application/Platform.html#startup-java.lang.Runnable
  
-


On 18 February 2016 at 20:08, Stephen Winnall  
  wrote:

   

As I understand it, there are two ways of activating JavaFX:

1) sub-class javafx.application.Application or
2) call javafx.application.Application.launch()

 
   



Op 20-02-16 om 01:28 schreef Stephen Winnall:

Anirvan, Kevin

Thanks for this.

I’m an expert neither in JavaFX nor in OSGi, but I think the basis of the 
JavaFX/OSGi incompatibility is control. To work with OSGi, JavaFX has to 
relinquish control of its startup sequence to OSGi in such a way that 

Re: JFX as an OSGi service?

[Stephen Winnall]

Hi Maurice

I have done something similar, but it has the following drawback in my view: 
the class launched (Udoo15App in your case) does not run under OSGi control, so 
it has no access to OSGi bundles or services, nor is it accessible by them. If 
you don’t need that, you're OK. But I need that class to be part of the OSGi 
world because other bundles/services are going to add parts to the UI as they 
are instantiated.

Steve

> On 20 Feb 2016, at 14:33, Maurice  wrote:
> 
> 
> For my OSGi based JavaFX solution on the Udoo Quad (ARM based Linux) I 
> created a service that publishes the application in the context.The 
> application does as little as possible. It sets up the primary stage as 
> fullscreen and puts a stackpane in it. Initially the stackpane displays a 
> 'boot logo', until the actual desktop bundle is started and registered with 
> the application. Note that you have to start the application on a separate 
> thread, as the thread will be blocked.
> 
> On Java 8 this means that although the application bundle can't be updated in 
> a running OSGi container, but that is why the desktop exists. On startup it 
> registers itself, and thus the application content, with the application, and 
> when it is stopped it removes the content from the application. The 
> application has thus rarely to be updated itself.
> 
> Regards,
> Maurice.
> 
> 
> 
> public class UdooActivator implements BundleActivator {
>private static UdooActivator activator;
>private BundleContext context;
> 
>static UdooActivator bundleActivator() {
>return requireNonNull(activator, "activator not set");
>}
> 
>@Override
>public void start(BundleContext context) throws Exception {
>this.context = context;
>activator = this;
>new Thread(() -> Application.launch(Udoo15App.class), "JavaFX Desktop 
> launcher").start();
>}
> 
>@Override
>public void stop(BundleContext context) throws Exception {
>Platform.exit();
>}
> 
>public BundleContext getBundleContext() {
>return context;
>}
> }
> 
> Op 20-02-16 om 01:28 schreef Stephen Winnall:
>> Anirvan, Kevin
>> 
>> Thanks for this.
>> 
>> I’m an expert neither in JavaFX nor in OSGi, but I think the basis of the 
>> JavaFX/OSGi incompatibility is control. To work with OSGi, JavaFX has to 
>> relinquish control of its startup sequence to OSGi in such a way that 
>> javafx.application.Application (or its proxy) is instantiated by OSGi and 
>> submits to OSGi’s bundle/service lifecycle. AN OSGi expert can probably 
>> formulate this better…
>> 
>> Platform.startup(runnable) /might/ do it. Platform.launch(class) doesn’t 
>> because the object thereby instantiated is always under the control of 
>> JavaFX - and thus not of OSGi.
>> 
>> I’m not comfortable using JFXPanel: if I wanted to use Swing I wouldn’t be 
>> trying to use JavaFX. But thank you for the hint.
>> 
>> Steve
>> 
>>> On 19 Feb 2016, at 16:41, Kevin Rushforth  
>>> wrote:
>>> 
>>> And for JDK 9 there is now:
>>> 
>>> Platform.startup(Runnable);
>>> 
>>> -- Kevin
>>> 
>>> 
>>> Anirvan Sarkar wrote:
 Hi Stephen,
 
 FYI, there is another way of initializing JavaFX runtime. Just use:
 
 new JFXPanel();
 
 It is documented[1] that FX runtime is initialized when the first JFXPanel
 instance is constructed.
 
 Also JavaFX 9 will provide an official API to start the FX platform [2] 
 [3].
 
 
 [1]
 https://docs.oracle.com/javase/8/javafx/api/javafx/application/Platform.html#runLater-java.lang.Runnable
   
 -
 [2]https://bugs.openjdk.java.net/browse/JDK-8090585  
 
 [3]
 http://download.java.net/jdk9/jfxdocs/javafx/application/Platform.html#startup-java.lang.Runnable
   
 -
 
 
 On 18 February 2016 at 20:08, Stephen Winnall  
   wrote:
 
   
> As I understand it, there are two ways of activating JavaFX:
> 
> 1) sub-class javafx.application.Application or
> 2) call javafx.application.Application.launch()
> 
> 
   
> 
> 
> 
> Op 20-02-16 om 01:28 schreef Stephen Winnall:
>> Anirvan, Kevin
>> 
>> Thanks for this.
>> 
>> I’m an expert neither in JavaFX nor in OSGi, but I think the basis of the 
>> JavaFX/OSGi incompatibility is control. To work with OSGi, JavaFX has to 
>> relinquish control of its startup sequence to OSGi in such a way that 
>> javafx.application.Application (or its proxy) is instantiated by OSGi and 
>> submits to OSGi’s bundle/service lifecycle. AN OSGi expert can probably 
>> formulate this better…
>> 
>> Platform.startup(runnable) /might/ 

Re: JFX as an OSGi service?

[Maurice]

For my OSGi based JavaFX solution on the Udoo Quad (ARM based Linux) I 
created a service that publishes the application in the context.The 
application does as little as possible. It sets up the primary stage as 
fullscreen and puts a stackpane in it. Initially the stackpane displays 
a 'boot logo', until the actual desktop bundle is started and registered 
with the application. Note that you have to start the application on a 
separate thread, as the thread will be blocked.


On Java 8 this means that although the application bundle can't be 
updated in a running OSGi container, but that is why the desktop exists. 
On startup it registers itself, and thus the application content, with 
the application, and when it is stopped it removes the content from the 
application. The application has thus rarely to be updated itself.


Regards,
Maurice.



public class UdooActivator implements BundleActivator {
private static UdooActivator activator;
private BundleContext context;

static UdooActivator bundleActivator() {
return requireNonNull(activator, "activator not set");
}

@Override
public void start(BundleContext context) throws Exception {
this.context = context;
activator = this;
new Thread(() -> Application.launch(Udoo15App.class), "JavaFX 
Desktop launcher").start();

}

@Override
public void stop(BundleContext context) throws Exception {
Platform.exit();
}

public BundleContext getBundleContext() {
return context;
}
}

Op 20-02-16 om 01:28 schreef Stephen Winnall:

Anirvan, Kevin

Thanks for this.

I’m an expert neither in JavaFX nor in OSGi, but I think the basis of the 
JavaFX/OSGi incompatibility is control. To work with OSGi, JavaFX has to 
relinquish control of its startup sequence to OSGi in such a way that 
javafx.application.Application (or its proxy) is instantiated by OSGi and 
submits to OSGi’s bundle/service lifecycle. AN OSGi expert can probably 
formulate this better…

Platform.startup(runnable) /might/ do it. Platform.launch(class) doesn’t 
because the object thereby instantiated is always under the control of JavaFX - 
and thus not of OSGi.

I’m not comfortable using JFXPanel: if I wanted to use Swing I wouldn’t be 
trying to use JavaFX. But thank you for the hint.

Steve


On 19 Feb 2016, at 16:41, Kevin Rushforth  wrote:

And for JDK 9 there is now:

 Platform.startup(Runnable);

-- Kevin


Anirvan Sarkar wrote:

Hi Stephen,

FYI, there is another way of initializing JavaFX runtime. Just use:

new JFXPanel();

It is documented[1] that FX runtime is initialized when the first JFXPanel
instance is constructed.

Also JavaFX 9 will provide an official API to start the FX platform [2] [3].


[1]
https://docs.oracle.com/javase/8/javafx/api/javafx/application/Platform.html#runLater-java.lang.Runnable
  
-
[2]https://bugs.openjdk.java.net/browse/JDK-8090585  

[3]
http://download.java.net/jdk9/jfxdocs/javafx/application/Platform.html#startup-java.lang.Runnable
  
-


On 18 February 2016 at 20:08, Stephen Winnall  
  wrote:

   

As I understand it, there are two ways of activating JavaFX:

1) sub-class javafx.application.Application or
2) call javafx.application.Application.launch()

 
   




Op 20-02-16 om 01:28 schreef Stephen Winnall:

Anirvan, Kevin

Thanks for this.

I’m an expert neither in JavaFX nor in OSGi, but I think the basis of the 
JavaFX/OSGi incompatibility is control. To work with OSGi, JavaFX has to 
relinquish control of its startup sequence to OSGi in such a way that 
javafx.application.Application (or its proxy) is instantiated by OSGi and 
submits to OSGi’s bundle/service lifecycle. AN OSGi expert can probably 
formulate this better…

Platform.startup(runnable) /might/ do it. Platform.launch(class) doesn’t 
because the object thereby instantiated is always under the control of JavaFX - 
and thus not of OSGi.

I’m not comfortable using JFXPanel: if I wanted to use Swing I wouldn’t be 
trying to use JavaFX. But thank you for the hint.

Steve


On 19 Feb 2016, at 16:41, Kevin Rushforth  wrote:

And for JDK 9 there is now:

 Platform.startup(Runnable);

-- Kevin


Anirvan Sarkar wrote:

Hi Stephen,

FYI, there is another way of initializing JavaFX runtime. Just use:

new JFXPanel();

It is documented[1] that FX runtime is initialized when the first JFXPanel
instance is constructed.

Also JavaFX 9 will provide an official API to start the FX platform [2] [3].


[1]
https://docs.oracle.com/javase/8/javafx/api/javafx/application/Platform.html#runLater-java.lang.Runnable
 

Re: JFX as an OSGi service?

[Stephen Winnall]

Anirvan, Kevin

Thanks for this.

I’m an expert neither in JavaFX nor in OSGi, but I think the basis of the 
JavaFX/OSGi incompatibility is control. To work with OSGi, JavaFX has to 
relinquish control of its startup sequence to OSGi in such a way that 
javafx.application.Application (or its proxy) is instantiated by OSGi and 
submits to OSGi’s bundle/service lifecycle. AN OSGi expert can probably 
formulate this better…

Platform.startup(runnable) /might/ do it. Platform.launch(class) doesn’t 
because the object thereby instantiated is always under the control of JavaFX - 
and thus not of OSGi.

I’m not comfortable using JFXPanel: if I wanted to use Swing I wouldn’t be 
trying to use JavaFX. But thank you for the hint.

Steve

> On 19 Feb 2016, at 16:41, Kevin Rushforth  wrote:
> 
> And for JDK 9 there is now:
> 
> Platform.startup(Runnable);
> 
> -- Kevin
> 
> 
> Anirvan Sarkar wrote:
>> 
>> Hi Stephen,
>> 
>> FYI, there is another way of initializing JavaFX runtime. Just use:
>> 
>> new JFXPanel();
>> 
>> It is documented[1] that FX runtime is initialized when the first JFXPanel
>> instance is constructed.
>> 
>> Also JavaFX 9 will provide an official API to start the FX platform [2] [3].
>> 
>> 
>> [1]
>> https://docs.oracle.com/javase/8/javafx/api/javafx/application/Platform.html#runLater-java.lang.Runnable
>>  
>> -
>> [2] https://bugs.openjdk.java.net/browse/JDK-8090585 
>> 
>> [3]
>> http://download.java.net/jdk9/jfxdocs/javafx/application/Platform.html#startup-java.lang.Runnable
>>  
>> -
>> 
>> 
>> On 18 February 2016 at 20:08, Stephen Winnall  
>>  wrote:
>> 
>>   
>>> As I understand it, there are two ways of activating JavaFX:
>>> 
>>> 1) sub-class javafx.application.Application or
>>> 2) call javafx.application.Application.launch()
>>> 
>>> 
>> 
>> 
>> 
>>   

Re: JFX as an OSGi service?

[Kevin Rushforth]

And for JDK 9 there is now:

   Platform.startup(Runnable);

-- Kevin


Anirvan Sarkar wrote:

Hi Stephen,

FYI, there is another way of initializing JavaFX runtime. Just use:

new JFXPanel();

It is documented[1] that FX runtime is initialized when the first JFXPanel
instance is constructed.

Also JavaFX 9 will provide an official API to start the FX platform [2] [3].


[1]
https://docs.oracle.com/javase/8/javafx/api/javafx/application/Platform.html#runLater-java.lang.Runnable-
[2] https://bugs.openjdk.java.net/browse/JDK-8090585
[3]
http://download.java.net/jdk9/jfxdocs/javafx/application/Platform.html#startup-java.lang.Runnable-


On 18 February 2016 at 20:08, Stephen Winnall  wrote:

  

As I understand it, there are two ways of activating JavaFX:

1) sub-class javafx.application.Application or
2) call javafx.application.Application.launch()






  

Re: JFX as an OSGi service?

[Anirvan Sarkar]

Hi Stephen,

FYI, there is another way of initializing JavaFX runtime. Just use:

new JFXPanel();

It is documented[1] that FX runtime is initialized when the first JFXPanel
instance is constructed.

Also JavaFX 9 will provide an official API to start the FX platform [2] [3].


[1]
https://docs.oracle.com/javase/8/javafx/api/javafx/application/Platform.html#runLater-java.lang.Runnable-
[2] https://bugs.openjdk.java.net/browse/JDK-8090585
[3]
http://download.java.net/jdk9/jfxdocs/javafx/application/Platform.html#startup-java.lang.Runnable-


On 18 February 2016 at 20:08, Stephen Winnall  wrote:

> As I understand it, there are two ways of activating JavaFX:
>
> 1) sub-class javafx.application.Application or
> 2) call javafx.application.Application.launch()
>



-- 
Anirvan

Re: JFX as an OSGi service?

[Stephen Winnall]

Hi Erik

Thanks for this - it makes sense.

I was wondering about

1) getting the sub-class of javafx.application.Application to register itself 
at runtime as an OSGi service; or
2) trying to create a ServiceFactory that creates an instance of 
javafx.application.Application (perhaps decorated or proxied); or
3) cloning javafx.application.Application and making a version compatible with 
declarative services.

Your approach is no. 4 and has the advantage that it is known to work!

It seems a pity that JavaFX has such a closed/proprietary approach to starting 
a javafx.application.Application.

Cheers,
Steve
 
> On 18 Feb 2016, at 17:40, Erik De Rijcke  wrote:
> 
> Hi Stephen,
> 
> We use JavaFX in an OSGi container, as a service component, in production, so 
> it's perfectly possible.
> 
> However there are a few gotcha's you need to take into account (I can not c/p 
> the code for obvious reasons...) which makes using it in osgi... quite 
> horrible :)
> 
> When triggering a javafx application in say, your component activate method 
> (as we do), you're actually creating a new javafx application instance, a 
> whole new identical object but without any scr dependency injection.
> 
> This is problematic as your osgi object has all the dependencies injected 
> from the osgi container while the javafx object does not. 
> 
> What we do is this: in our activate we copy all our osgi dependencies, as 
> well as our ourself (this) to static fields, this makes them accessible in 
> the start method of the javafx object. When start is called, we store the 
> javafx object in a static field (which we access by calling 'this' in the 
> start method). We now have access to all dependencies and both objects at any 
> time. Now it's just matter of delegating calls from one instance to another 
> if needed...
> 
> btw, don't forget to call launch in a separate thread in your activate, else 
> you'll block your bundle activator thread indefinitely oh *and* sync (block) 
> your osgi component activate until the start method of your javafx has 
> finished else your component will announce itself activated while javafx is 
> still busy initializing.
> 
> Oh another gotcha, try to avoid using Platform.runLater, as that will only 
> work *after* your application component was activated, instead make a non 
> static runLater method in your osgi javafx application component and use 
> that. That will ensure that javafx was initialized before invoking any 
> platform run later.
> 
> Unfortunately javafx has a lot of static { Platform.RunLater} calls spread 
> out in different classes, so don't try to load those classes before your 
> javafx application was started... OUCH!
> 
> Didn't I say it was hairy and messy? JavaFX and OSGi is quite a bad match 
> unfortunately.
> 
> On Thu, Feb 18, 2016 at 3:38 PM, Stephen Winnall  > wrote:
> I am trying to make JavaFX 8 work with OSGi Declarative Services. My 
> preferred solution would be to instantiate javafx.application.Application as 
> an OSGi service.
> 
> As I understand it, there are two ways of activating JavaFX:
> 
> 1) sub-class javafx.application.Application or
> 2) call javafx.application.Application.launch()
> 
> However, both of these approaches give me a POJO, which makes interaction 
> with OSGi services and bundles very difficult.
> 
> Is there a “proper” way of starting JavaFX as an OSGi service? If not, are 
> there any plans to support this?
> 
> Regards,
> Steve
> 

Re: JFX as an OSGi service?

[Erik De Rijcke]

Hi Stephen,

We use JavaFX in an OSGi container, as a service component, in production,
so it's perfectly possible.

However there are a few gotcha's you need to take into account (I can not
c/p the code for obvious reasons...) which makes using it in osgi... quite
horrible :)

When triggering a javafx application in say, your component activate method
(as we do), you're actually creating a new javafx application instance, a
whole new identical object but without any scr dependency injection.

This is problematic as your osgi object has all the dependencies injected
from the osgi container while the javafx object does not.

What we do is this: in our activate we copy all our osgi dependencies, as
well as our ourself (this) to static fields, this makes them accessible in
the start method of the javafx object. When start is called, we store the
javafx object in a static field (which we access by calling 'this' in the
start method). We now have access to all dependencies and both objects at
any time. Now it's just matter of delegating calls from one instance to
another if needed...

btw, don't forget to call launch in a separate thread in your activate,
else you'll block your bundle activator thread indefinitely oh *and* sync
(block) your osgi component activate until the start method of your javafx
has finished else your component will announce itself activated while
javafx is still busy initializing.

Oh another gotcha, try to avoid using Platform.runLater, as that will only
work *after* your application component was activated, instead make a non
static runLater method in your osgi javafx application component and use
that. That will ensure that javafx was initialized before invoking any
platform run later.

Unfortunately javafx has a lot of static { Platform.RunLater} calls spread
out in different classes, so don't try to load those classes before your
javafx application was started... OUCH!

Didn't I say it was hairy and messy? JavaFX and OSGi is quite a bad match
unfortunately.

On Thu, Feb 18, 2016 at 3:38 PM, Stephen Winnall  wrote:

> I am trying to make JavaFX 8 work with OSGi Declarative Services. My
> preferred solution would be to instantiate javafx.application.Application
> as an OSGi service.
>
> As I understand it, there are two ways of activating JavaFX:
>
> 1) sub-class javafx.application.Application or
> 2) call javafx.application.Application.launch()
>
> However, both of these approaches give me a POJO, which makes interaction
> with OSGi services and bundles very difficult.
>
> Is there a “proper” way of starting JavaFX as an OSGi service? If not, are
> there any plans to support this?
>
> Regards,
> Steve

JFX as an OSGi service?

[Stephen Winnall]

I am trying to make JavaFX 8 work with OSGi Declarative Services. My preferred 
solution would be to instantiate javafx.application.Application as an OSGi 
service.

As I understand it, there are two ways of activating JavaFX:

1) sub-class javafx.application.Application or
2) call javafx.application.Application.launch()

However, both of these approaches give me a POJO, which makes interaction with 
OSGi services and bundles very difficult.

Is there a “proper” way of starting JavaFX as an OSGi service? If not, are 
there any plans to support this?

Regards,
Steve