Note that there are some explanatory texts on larger screens.

plurals
  1. POWhat is the alternative to OSGI for inter-module service injection in Wildfly?
    primarykey
    data
    text
    <p>We are in the process of disentangling a classic legacy monolithic EAR-packaged Java EE application. Our (most complex) component wiring pattern is as follows: component A 'requires' interface X, whilst components B and C (... N) each 'provide' interface X. Our requirement is to package and deploy A, B, C and X separately and independently in order to minimize downtime and minimize business impact. </p> <p>We therefore require the necessary robustness to allow providers (B,C) of interfaces to be removed and added (redeployed), at runtime, without requiring a redeployment of the consumers (A) of the interface, nor a restart of the server. The solution will run on Wildfly 8, but can make use or other technologies as long as they work on Wildfly 8.</p> <p>We've implemented a POC using JBoss-OSGI and Weld-OSGI which fulfilled all of our requirements, and offered us an excellent migration path as well. However, in Wildfly 8 Alpha 3, JBoss-OSGI was removed from the default distribution. This made us think we should explore alternatives that are more in line with the thinking of the people behind Wildfly. </p> <p>The question therefore is, on Wildfly 8, what is the alternative to OSGI for inter-module service injection that would meet our requirements?</p> <p>For the sake of budgets, simplicity, performance overheads and company policies, we've had to eliminate the following: <br/>1. Remote EJB's <br/>2. Web Services <br/>3. JSon/Rest <br/>4. SCA</p> <p>Please note that this is not a request for a debate on the viability of OSGI nor for an evaluation or comparison of different solutions. I am simply looking for any solution(s) that would meet our criteria and is NOT based on OSGI.</p>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. COI appreciate you don't want a debate, and you're right that StackOverflow is not the place for debates. But... you said that JBoss-OSGi fulfilled all your requirements, and offered an excellent migration path. And to be clear, JBoss-OSGi is still available and supported by Red Hat, albeit now as an optional add-on rather than out-of-the-box. So I don't really understand the motivation for this question.
      singulars
    2. COValid point. Yes JBoss-OSGI is still available as an add-on. However, support from Red Hat is a more tricky issue, excluded from EAP etc., which is my first concern. In addition, it is risky using JBoss-OSGI on Wildfly when important people behind Wildfly don't really buy into it. Once again I do not wish to debate the validity of their point of view, but the fact that it exists is a risk in using JBoss-OSGI. Lastly, I feel I am missing the more obvious solution they actually had in mind for a scenario such as this, and that my tendency to think in OSGI concepts may have closed my eyes to it.
      singulars
    3. COHey @ArjanTijms, do you really patrol the whole of StackOverflow to make sure people say "Java EE" instead of the widely understood terms JEE and J2EE? Your devotion to nomenclature and trademarks is admirable but a little narrowly focused... I mean why not correct OSGI to OSGi?
      singulars
 

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