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.

> On 18 Feb 2016, at 17:40, Erik De Rijcke <derijcke.e...@gmail.com> 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 <st...@winnall.ch 
> <mailto:st...@winnall.ch>> 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

Reply via email to