Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>Since you're asking about the thinking of the people behind WildFly, I will refer you to the following mail-list message. It was posted to the Jigsaw development list by David Lloyd, who is (I believe) the designer of JBoss Modules on which WildFly is based. The context was a discussion about the introduction of a service model into Jigsaw: <a href="http://mail.openjdk.java.net/pipermail/jigsaw-dev/2012-February/002161.html">http://mail.openjdk.java.net/pipermail/jigsaw-dev/2012-February/002161.html</a></p> <p>What David seems to be saying is either that the <em>idea</em> of services itself flawed – i.e. you don't need them! – or that the requirement is already sufficiently solved by the ServiceLoader API which was introduced in Java 6.</p> <p>However, ServiceLoader is known not to work on module systems that use classloader isolation, which includes both OSGi and JBoss Modules. This is because ServiceLoader uses classpath scanning, and in a module system there is no "classpath". In OSGi we have specced a way of adapting ServiceLoader (though it's yucky and requires bytecode munging). Perhaps JBoss Modules also has a way of handling this, but I couldn't find anything from a quick scan of their docs.</p> <p>Anyway as I said in my comment above, I'm puzzled about your motivation. You clearly get benefits from the service model provided by OSGi, and JBoss-OSGi is still available and supported by Red Hat... so why not continue to use it? Especially if there is nothing clearly provided by WildFly out-of-the-box that does what you want.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload