Patch: issue RT-14177

Tom Schindl tom.schindl at
Tue Apr 10 06:46:38 PDT 2012


I think we need to take a highlevel look at this. So the real problem in
an OSGi Environment is the fully qualified classname in OSGi has to have
more information than in standard java.

In standard java:

In OSGi:

So the problem we need to solve is to make the css and fxml framework
classes pass on this information or make use it it directly (e.g. fxml
loads classes itself, while css only passes a string to the control
which does the classloading).

So the first an most important API that is needed is the possibility to
install a global Classloading-Delegate which understands the little bit
more sophisticated FQN of a class in OSGi.

interface ClassloadingDelegate {
  Class<?> loadClass(String classnameUrl);
  String createClassNameUrl(String resourceURL, String classname);

there must be some place in javafx where such a classloading delegate
could be installed (e.g. the Platform-Class?).

Platform#setClassloadingDelegate(ClassloadingDelegate): void

(I don't know if Platform is the best class for this because it is
public API but this API is better suited in an internal one)

*1. Usecase: All information coming from an OSGi-Bundle*

The createClassnameUrl is used by the FXML and CSSEngine to create an
URL from the simple class definitions e.g.:

-fx-skin: my.package.MyClass

passes in the following informations to

resourceURL: bundle://1234/css/my.css
classname: my.package.MyClass

which results in:


which is then set in the Control's skinClassName. The control then uses
ClassloadingDelegate#loadClass(String classnameUrl) to load the class.

*2. Usecase: Information coming from css/fxml file on the filesystem*

CSS nor FXML requires informations loaded from a bundle/jar file but
they can resided fairly everywhere (e.g. file://, http://) and in this
case the retrieval of the bundle to use when loading classes can not be
derived from css filename but must be encoded into the css itself like this:

-fx-skin: my.bundle/my.package.MyClass

so the CSS-Engine will call ClassloadingDelegate#createClassNameUrl with
these values:

resourceURL: file://C/my.css
classname: my.bundle/my.package.MyClass

and now the delegate has to do some more work because it first has to
find the bundle with the symbolic name "my.bundle" (Probably by using
the PackageAdmin-Service) and make up the bundle-url of it but the
result would be the same:


What do you think about this proposal?


Am 06.04.12 19:10, schrieb Florian Brunner:
> Here the patch created with "hg diff --git" and zipped.
> Regards,
> Florian
> Am Freitag 06 April 2012, 18:31:23 schrieb Kevin Rushforth:
>> Right. Since you didn't file the issue and are not the assignee, you 
>> can't add an attachment.
>> Copying Brian Beck in case this is something we can (and want to) fix.
>> In the mean time, you can e-mail me the patch and I'll attach it to the 
>> bug report.
>> -- Kevin
>> Florian Brunner wrote:
>>> Hi Kevin,
>>> Thanks for your response.
>>> Unfortunatly, I don't see a way to attach something to the JIRA issue.
>>> Either I'm missing something or maybe I need additional rights?
>>> Regards,
>>> Florian
>>> Am Donnerstag 05 April 2012, 18:54:38 schrieben Sie:
>>>> Great. Please attach the patch as a zip file to the JIRA issue 
>>>> (preferably generated with either webrev or "hg diff --git") so that it 
>>>> can be evaluated.
>>>> -- Kevin
>>>> Florian Brunner wrote:
>>>>> Hi,
>>>>> Let me introduce myself: my name is Florian Brunner and I'm a Senior Software Engineer from Switzerland.
>>>>> I started to use JavaFX in an OSGi environment. Now I stumbled over the following issue, which blocks me:
>>>>> I have written a patch now. It probably doesn't solve the whole issue, but at least it unblocks me for now.
>>>>> It would be great if you could integrate it.
>>>>> Note that I contributed to OpenJDK before (Swing) and have signed the Sun Contributor Agreement:
>>>>> Florian Brunner - - puce
>>>>> Regards,
>>>>> Florian

B e s t S o l u t i o n . a t                        EDV Systemhaus GmbH
tom schindl                 geschäftsführer/CEO
eduard-bodem-gasse 5-7/1   A-6020 innsbruck     fax      ++43 512 935833                      phone    ++43 512 935834

More information about the openjfx-dev mailing list