You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@felix.apache.org by Eelco Meuter <Ee...@wur.nl> on 2009/05/13 17:07:54 UTC
Felix and javaFX/third party jars
Hello felix users,
This is maybe a typical question from a a OSGi newbee.
Presently, I am building an embedded OSGi application with a javaFX
front-end and stumbled on a couple of issues. I hope anyone could help
me with this.
As a starting point of my design, I took the service-based example. I
designed a FelixLauncher class that configures and launches felix. I
implemented the BundleActivator into a javaFX class and I am able to
start the FX bundle - hello world example- after I successfully launch
felix. The javaFX SDK is added to the config map using the
FelixConstants.FRAMEWORK_SYSTEMPACKAGES_EXTRA property.
issue 1: There must be a more intelligent way to add third party
packages, rather than explicitly list them in a comma delimited
manner. It is not bad to do some manual labour, but it set-up is prone
to errors.
issue 2: My hello world fx class does give some proof of concept, but
I need some classloader magic if my more elaborate fx application
start to work. This application has several CustomNodes in different
packages within the same jar that are suddenly unreachable. It throws
a classnotfound exception.
I hope someone can help me to deal with these issues.
Regards,
Eelco Meuter
Wageningen University
Plant Production Systems
P.O. Box 430
6700 AK WAGENINGEN
The Netherlands
http://www.pps.wur.nl
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Felix and javaFX/third party jars
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Packages listed in "uses" directives for export packages are exposed in
some way by those exported packages (e.g., a method return value or
method parameter types). If you see a package listed in "uses" then it
will either be imported by your bundle or exported by it. The framework
uses this information to make sure that clients of your exported
packages are wired to the same packages your exported package uses, if
necessary.
-> richard
On 5/14/09 3:03 PM, Patrick Forhan wrote:
>> These are automatically created by bnd, as are the SDK headers. The export
>> headers of the sdk look a bit different. BND does not explicitly mention
>> these packages, but wraps them in a 'uses:=' statement. Could this be the
>> problem?
>>
>
> If I understand it correctly the uses:= clauses are there to give
> hints to the container. It basically indicates that you will have to
> find those packages somewhere. I would try to instruct BND to export
> *at least* all of the javafx.* packages. The configuration I use has
> the following packages exported:
>
> com.sun.gluegen.*,
> !com.sun.javafx.runtime.adapter,
> !com.sun.javafx.runtime.liveconnect,
> !com.sun.javafx.runtime.provider,
> !com.sun.javafx.api.*,
> com.sun.javafx.*,
> com.sun.embeddedswing,
> com.sun.media.*,
> com.sun.medialib.*,
> com.sun.opengl.*,
> com.sun.scenario.*,
> com.sun.stylesheet.*,
> javax.media.opengl.*,
> org.jdesktop.layout,
> !javafx.fxunit,
> javafx.*,
>
> I don't remember quite why the com.sun.* stuff is exported and not
> private-packaged, but that is working for us at the moment.
>
> Pat.
>
Re: Felix and javaFX/third party jars
Posted by Eelco Meuter <ee...@wur.nl>.
Thanks for the explanation of the uses:= clause. It still does not
work. I get the same errors as reported last week and I don't know
what I do wrong. I also tried to bundle each jar in the SDK
separately, but that didn't work either. I am open to all creative
solutions.
If used the following ant script to create the javafx bundle:
<target name="build" description="wraps javaFX jars">
<jar destfile="test.jar">
<zipgroupfileset dir="${javafx.path}/lib">
<include name="**/*.jar"/>
</zipgroupfileset>
</jar>
<bndwrap jars="test.jar" definitions="${basedir}/bnd"
output="javafx.runtime.jar"/>
<delete file="test.jar"/>
<move file="javafx.runtime.jar" todir="${common.basedir}/bundles" />
</target>
This is the test.bnd definition file:
Export-Package:com.sun.gluegen.*,\
!com.sun.javafx.runtime.adapter,\
!com.sun.javafx.runtime.liveconnect,\
!com.sun.javafx.runtime.provider,\
!com.sun.javafx.api.*,\
com.sun.javafx.*,\
com.sun.embeddedswing,\
com.sun.media.*,\
com.sun.medialib.*,\
com.sun.opengl.*,\
com.sun.scenario.*,\
com.sun.stylesheet.*,\
javax.media.opengl.*,\
org.jdesktop.layout,\
!javafx.fxunit,\
javafx.*
On May 14, 2009, at 9:03 PM, Patrick Forhan wrote:
>> These are automatically created by bnd, as are the SDK headers. The
>> export
>> headers of the sdk look a bit different. BND does not explicitly
>> mention
>> these packages, but wraps them in a 'uses:=' statement. Could this
>> be the
>> problem?
>
> If I understand it correctly the uses:= clauses are there to give
> hints to the container. It basically indicates that you will have to
> find those packages somewhere. I would try to instruct BND to export
> *at least* all of the javafx.* packages. The configuration I use has
> the following packages exported:
>
> com.sun.gluegen.*,
> !com.sun.javafx.runtime.adapter,
> !com.sun.javafx.runtime.liveconnect,
> !com.sun.javafx.runtime.provider,
> !com.sun.javafx.api.*,
> com.sun.javafx.*,
> com.sun.embeddedswing,
> com.sun.media.*,
> com.sun.medialib.*,
> com.sun.opengl.*,
> com.sun.scenario.*,
> com.sun.stylesheet.*,
> javax.media.opengl.*,
> org.jdesktop.layout,
> !javafx.fxunit,
> javafx.*,
>
> I don't remember quite why the com.sun.* stuff is exported and not
> private-packaged, but that is working for us at the moment.
>
> Pat.
> --
> Defy mediocrity.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
Wageningen University
Plant Production Systems
P.O. Box 430
6700 AK WAGENINGEN
The Netherlands
http://www.pps.wur.nl
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Felix and javaFX/third party jars
Posted by Patrick Forhan <fe...@muddyhorse.com>.
> These are automatically created by bnd, as are the SDK headers. The export
> headers of the sdk look a bit different. BND does not explicitly mention
> these packages, but wraps them in a 'uses:=' statement. Could this be the
> problem?
If I understand it correctly the uses:= clauses are there to give
hints to the container. It basically indicates that you will have to
find those packages somewhere. I would try to instruct BND to export
*at least* all of the javafx.* packages. The configuration I use has
the following packages exported:
com.sun.gluegen.*,
!com.sun.javafx.runtime.adapter,
!com.sun.javafx.runtime.liveconnect,
!com.sun.javafx.runtime.provider,
!com.sun.javafx.api.*,
com.sun.javafx.*,
com.sun.embeddedswing,
com.sun.media.*,
com.sun.medialib.*,
com.sun.opengl.*,
com.sun.scenario.*,
com.sun.stylesheet.*,
javax.media.opengl.*,
org.jdesktop.layout,
!javafx.fxunit,
javafx.*,
I don't remember quite why the com.sun.* stuff is exported and not
private-packaged, but that is working for us at the moment.
Pat.
--
Defy mediocrity.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Felix and javaFX/third party jars
Posted by Eelco Meuter <ee...@wur.nl>.
Here are the import headers:
Import-Package
com.sun.javafx.functions
com.sun.javafx.runtime
com.sun.javafx.runtime.annotation
com.sun.javafx.runtime.location
com.sun.javafx.runtime.sequence
framework.datamodel
javafx.geometry
javafx.scene
javafx.scene.effect
javafx.scene.input
javafx.scene.layout
javafx.scene.paint
javafx.scene.shape
javafx.scene.text
javafx.stage
javafx.util
org.osgi.framework {version=1.4}
These are automatically created by bnd, as are the SDK headers. The
export headers of the sdk look a bit different. BND does not
explicitly mention these packages, but wraps them in a 'uses:='
statement. Could this be the problem?
Eelco
On May 14, 2009, at 4:23 PM, Patrick Forhan wrote:
> What are the import-package headers for your javafx application,
> bundle 3? It will have to include all the packages you use. BND can
> successfully analyze the compile JFX classes to help create this
> automatically, but if you are naming the import-packages manually it
> won't.
>
> Pat.
>
> --
> Defy mediocrity.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
Wageningen University
Plant Production Systems
P.O. Box 430
6700 AK WAGENINGEN
The Netherlands
http://www.pps.wur.nl
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Felix and javaFX/third party jars
Posted by Patrick Forhan <fe...@muddyhorse.com>.
What are the import-package headers for your javafx application,
bundle 3? It will have to include all the packages you use. BND can
successfully analyze the compile JFX classes to help create this
automatically, but if you are naming the import-packages manually it
won't.
Pat.
--
Defy mediocrity.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Felix and javaFX/third party jars
Posted by Eelco Meuter <ee...@wur.nl>.
Thanks for the advise.
I also took the conservative approach in wrapping the SDK. Only the
jars javafxc, javafxrt, Scenario and javafxgui are wrapped in one jar.
Do you bundle them as well as one or as separate? That was not clear
from the maven code, given my limited knowledge of maven. The
framework_systempackages_extra are not set when adding the SDK as a
bundle. The exception is thrown by the jfx code and does not come more
informative that this I am affraid. Bundle 1 is a helloworld bundle to
see if the framework behaves as expected, bundle 2 is the jfx sdk and
bundle 3 is the application.
Eelco
On May 14, 2009, at 3:36 PM, Patrick Forhan wrote:
> Well, don't try to tackle too many things at once... you'll need a
> firm understanding of OSGi and JavaFX separately from one another in
> order to be really effective. Maven-vs-ant shouldn't matter too much
> at this point, though it does seem like the maven-bundle-plugin (which
> uses BND) has been getting a lot of attention and features.
>
> I found I had to be careful in bundling up the JavaFX stuff... if I
> took too much, the bundle would start having dependencies on more and
> more things, which would in turn require more bundles. You should be
> able to adapt the bundle-instructions I used in maven to make a
> similar bundle via ant or BND. I think we got it to the point where
> it only had JRE dependencies. We also cheated and made a bunch of
> things optional imports when they probably weren't entirely, like
> applet, javascript, and media support.
>
> It's hard to debug from here as to your problem with bundle 3 (is that
> your JFX code, or the runtime?). Also, if you bundle up javafx, you
> shouldn't need framework_systempackages_extra or the jfx stuff in your
> startup classpath.
>
> Pat.
>
> --
> Defy mediocrity.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
Wageningen University
Plant Production Systems
P.O. Box 430
6700 AK WAGENINGEN
The Netherlands
http://www.pps.wur.nl
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Felix and javaFX/third party jars
Posted by Patrick Forhan <fe...@muddyhorse.com>.
Well, don't try to tackle too many things at once... you'll need a
firm understanding of OSGi and JavaFX separately from one another in
order to be really effective. Maven-vs-ant shouldn't matter too much
at this point, though it does seem like the maven-bundle-plugin (which
uses BND) has been getting a lot of attention and features.
I found I had to be careful in bundling up the JavaFX stuff... if I
took too much, the bundle would start having dependencies on more and
more things, which would in turn require more bundles. You should be
able to adapt the bundle-instructions I used in maven to make a
similar bundle via ant or BND. I think we got it to the point where
it only had JRE dependencies. We also cheated and made a bunch of
things optional imports when they probably weren't entirely, like
applet, javascript, and media support.
It's hard to debug from here as to your problem with bundle 3 (is that
your JFX code, or the runtime?). Also, if you bundle up javafx, you
shouldn't need framework_systempackages_extra or the jfx stuff in your
startup classpath.
Pat.
--
Defy mediocrity.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Felix and javaFX/third party jars
Posted by Eelco Meuter <ee...@wur.nl>.
Thanks for the prompt answer! Sorry I missed your earlier comment...
I've looked at your example and repeated it using Ant and bnd. Maybe I
should learn maven instead.
Anyway, the bndwrap task nicely wraps the javaFX classpath that is
used for the build as a single bundle although it throws this warning:
[bndwrap] Warnings
[bndwrap] Superfluous export-package instructions:
I have no idea what this means yet.
As I don't have a swing application using FX elements, but a complete
FX application, I am not quite sure how to deal with loading magic. If
I ignore it, I receive a org.osgi.framework.BundleException:
Unresolved constraint in bundle 3: package; (package=javafx.geometry).
Ignoring clearly doesn't work. The odd thing is that the package is
exported according to the manifest of my SDK wrap.
I tried to use the following trick, which feels like a hack:
override public function start(context:BundleContext):Void{
var bundleClassLoader:ClassLoader =
this.getClass().getClassLoader();
var originalClassLoader:ClassLoader =
Thread.currentThread().getContextClassLoader();
Thread.currentThread().setContextClassLoader(bundleClassLoader);
//Set the stage...
Thread.currentThread().setContextClassLoader(originalClassLoader);
}
This seems to work together with setting all the packages which bnd
finds as import packages into the FRAMEWORK_SYSTEMPACKAGES_EXTRA
property of my custom felix launcher class. Unfortunately it stumbles
on an import package which is not captured by bnd. This puzzles me as
well.
I clearly misunderstand something or a lot, but I really would like to
get this working.
On May 13, 2009, at 11:55 PM, Patrick Forhan wrote:
> I've mentioned this before, so forgive the repeat:
> http://blog.muddyhorse.com/2009/02/maven-osgi-spring-javafx-ant/
>
> Basically, we put most of the javafx stuff into a bundle, and used it
> that way. Then we had to do some magic to be able to load CustomNodes
> because of stylesheet issues.
>
> Pat.
>
> --
> Defy mediocrity.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
Wageningen University
Plant Production Systems
P.O. Box 430
6700 AK WAGENINGEN
The Netherlands
http://www.pps.wur.nl
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Felix and javaFX/third party jars
Posted by Patrick Forhan <fe...@muddyhorse.com>.
I've mentioned this before, so forgive the repeat:
http://blog.muddyhorse.com/2009/02/maven-osgi-spring-javafx-ant/
Basically, we put most of the javafx stuff into a bundle, and used it
that way. Then we had to do some magic to be able to load CustomNodes
because of stylesheet issues.
Pat.
--
Defy mediocrity.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org