OSGi R5 Enterprise release contains the Subsystem specification.
Does OSGi subsystems contain all capabilities of Eclipse feature?
Does tooling exist for it?
Purpose of this mapping would be a re-use of existing eclipse features in e.g. felix or bnd/bndtools based infrastructures.
Yes... kind of. A subsystem is powerful but also more complex than an Eclipse Feature.
A feature is just a set of bundles. You can install multiple features into a single OSGi Framework, and the bundles from each feature can interact with each other, e.g. by importing packages or binding services. This makes them hard to test and to reason about, because a feature that works on its own might not work when installed alongside some other feature.
A subsystem is also a set of bundles, but it additionally includes a degree of isolation. You can control whether the packages, services and other capabilities from one subsystem are visible to the members of any other subsystem. Thus they are more predictable.
Unfortunately constructing a subsystem is a much more complex task, and there is no specific tooling for this that I know of. We haven't done anything in bnd/Bndtools to help with this. But hey it's open source... contributions welcome ;-)
Subsystems and features are really two orthogonal things. An Eclipse feature is a set of bundles that can be installed into an OSGi runtime. Actually, there's little difference between a bundle that has a lot of Require-Bundle elements and a feature, as far as requiring that they be installed.
An OSGi subsystem on the other hand was a proposed way of allowing OSGi runtimes to be nested. However, they were replaced with a more general wiring construct in the final version of the OSGi spec; but in any case, they do a completely different thing.
Related
My ultimate goal is Invoking Eclipse plugin from Java. I see that an Eclipse plugin registers a class as Bundle-Activator in MANIFEST.MF. The start(BundleContext context) method will be called on this class. Where does this call come from?
Eclipse is made up of many repos that are mostly mirrored on GitHub. Some are deprecated and point to other repos. And it's a programming IDE and an OSGi framework at the same time? I find it hard to find the code for this core part of the framework that handles plugin loading. Where is it?
The project to interact with OSGi bundles is Eclipse Equinox. It is an implementation of the OSGi framework. You start equinox and load the bundle jar from there instead of putting them into the regular classpath.
Here you find some information how to do this in general:
http://njbartlett.github.io/2011/07/03/embedding-osgi.html
You can then interact with the bundles from you plain java application. This is not an easy thing though.
What makes things even more complex is that Eclipse is not plain OSGi. Eclipse predates OSGi and many of the concepts are still not fully adapted to plain OSGi.
So using eclipse plugins from a plain java application may be very hard.
I recommend to ask on the mailing list of the plugin you want to use if there is experience with using it outside eclipse.
Is there any ready-made installer, component, api or any combination, that would let a JavaFX application, or any JVM based client for that matter, automatically and securely check for a new version of itself, and get, install and re-launch the new version?
Although not ideal, is it doable at least with sbt?
in the Moment there is only a feature request for Java 9
Take a Look at this aproach which seems straight forward
AutoUpdate by Reportmill
Install4J is a a tool for creating installers for JVM applications, it provides for creation of auto-updates
https://www.ej-technologies.com/products/install4j/features.html
You can also build Install4J projects from SBT using the sbt-install4j plugin (disclaimer: I am the author of the plugin).
I have come to believe that the most practical (partial) solution is Java Web Start. Mature, documented, and comes along with the JRE and JDK. I wonder if anyone had experience with it for ScalaFX or JavaFX applications.
i have some requirements on my project that modularity appears to be needed, so i'm researching some approaches on the best way to do it.
Based on this, i found OSGI and sounds like a great deal, after some search and some tutorials i have some doubts.
In a high level i'm thinking in separate my modules by business segments, for instance, financial, invoices, registers, and so on.
1) I believe i can create bundles to separate these modules, i also saw that i can use osgi container to deploy those bundles. Is is possible to distribute this application on jboss, websphere and weblogic?
2) Is there any known disadvantage to make my application full dependent to OSGI? I mean, i only wanted to use OSGI to separate my modules and make deploy and version distribution easier?
Thanks
As relates to WebSphere Application Server, the answer to your question #1 is positive. WAS has extended support for applications based on OSGi and has the notion of Web Application Bundle (WAB) and EJB bundle. You should take a look at the official documentation - OSGi applications.
You might also want to take a closer look at Apache Aries, the project that enables the use of OSGi for building applications in Java EE environment.
i' ve some web applications developed using Seam Framework 2.3 + jBoss AS 7 + Hybernate.
Since i' ve been studying OSGI for a while, i was wondering if is possible to move my applications to the osgi world for modularizing everything; i' ve read a lot of blogs and these interesting discussions as well (how-to-modularize-an-enterprise-application-with-osgi-and-ee6 and how-to-modularize-a-jsf-facelets-spring-application-with-osgi) but honestly i still don't really know where i should start from, since i' ve never used OSGI before.
According to you
Is it possible (and useful) do such things?
According to your experience, what would be a good starting point?
Thanks for help
Approach
Possibly start with a toy application as a spike, a WAB (OSGi WAR) and single service bundle.
Definitely take an iterative approach. As far as I know JBoss supports the mixing of OSGi services and Java EE stuff, via JBoss modules/msc, this will allow you to try OSGi and migrate gradually.
I think you'll find some things are incredibly easy and others very hard, so pick easy battles while you're getting familiar. In the end you may stick with a hybrid approach.
Build
What's your build tool? Mostly like Maven or Ant, in which case have a look at maven-bundle-plugin
or bnd respectively. You'll need to ensure the OSGi metadata is present in each of your bundles (Bundle-SymbolicName, Import-Package, Export-Package, etc). If you're using Maven see this answer.
It can be tricky to divide a monolithic app into modules, but as a general rule when you migrate a reasonable sized module you should have separate bundles for API and implementation (which is good design anyway but has implications for the runtime too).
Interop
You can acquire OSGi services, access bundles etc using the low level framework APIs from an injected BundleContext, which will give you a low-level programmatic hook into OSGi. It should be as simple as:
#Resource
BundleContext context;
Unless your Java EE code is packaged as JBoss modules I don't think it will be easy for you to call the other way (e.g. OSGi service looking up Java EE service) without resorting to something like JNDI.
You should be able to install the webconsole and see what Java EE bits are registered in OSGi, and similarly check JNDI to see what's available OSGi for Java EE.
Migrating Services
While OSGi is a lot of fun, using the raw framework API results in quite a bit of boilerplate code and it's unlikely you'll need the power or want the coupling. You can use a number of dependency injection frameworks on top of OSGi; blueprint (Spring-like), Peaberry (Guice) and Declarative Services for example.
I'm biased but Declarative Services has a strong affinity to the OSGi µservice model and the implementations are lightweight.
CDI
I don't know much about Seam/CDI, but Pax CDI might help (though JBoss might already have covered this).
Web
Are you planning to have a highly modular UI with hot deploy of the various components? If not then probably best just to package the UI as a WAB. A WAB is a skinny WAR (i.e. it imports rather than embeds most dependencies). Even if you're after a highly modular, dynamic frontend, I would definitely do this for the first pass.
JPA
A word of warning - JPA implementations typically don't play well in OSGi environments, you may want to look at Apache Aries or Eclipse Gemini. Another option might be to leave the JPA stuff in Java EE space and access Java EE DAOs/Repositories as OSGi services. Again though you may experience some classloading issues.
Possibly useful examples https://docs.jboss.org/author/display/JBOSGI/Provided+Examples
The base of our enterprise application is OSGI and we have several Java projects that are logically OSGI bundles. We use Maven to compile the application using the Maven Bundle plugin. But this process is time consuming and makes it impossible to debug the application. We also use the Runner and Pax(:provison) plugins to run the application. If we could rely on the Auto build function of Eclipse and also debug the application it would make our lives so much easier. Is there a way to configure Eclipse to be able to compile (and may be run) an OSGI-based application?
I'm not entirely sure if I understand you, but here goes.
Well, running/debugging OSGi applications in Eclipse is really easy, as long as your bundles reside in PDE aware projects or at least are on your target platform.
Do you have the source of all your bundles? Debugging without source isn't all that useful. If you do, can you just import all the source of your bundles into your Eclipse workspace?
Otherwise you can create a target platform, add all your bundles to that. (as a first attempt, I'd say dump all your bundles in a directory and point the target platform there)
Either way, then you should be able to Run (or debug)-> OSGi framework -> New -> Pick your bundles -> Start
You can both pick bundles from or target platform and from your workspace.
For building, you can use Eclipse Plugin Development Environment (PDE). Despite its name, it isn't specific to building Eclipse plugins and can be used for working on pure OSGi bundles. Eclipse plugins are OSGi bundles with some extras.
Cannot help you with the running or debugging part, although I do know that some enterprise-oriented OSGi platforms provide extensions to PDE.
If you're already using the maven bundle plugin, you may find that PDE's manifest-first approach isn't a good fit with your existing code-first build (I assume at the end you want both an IDE build for development and debugging, and a command-line build for continuous integration and automated testing).
You have two choices. As others have suggested, you can use Eclipse's integrated PDE, and use Tycho for your maven build. Tycho uses the same data used by PDE, so you don't have to write things down more than once. Alternatively, you can stick with the maven bundle plugin and use bndtools within Eclipse. Like the bundle plugin, bndtools is code-first, so you won't need to worry about maintaining manifests. However, you may find there isn't quite as big a set of features in bndtools as in PDE, and I'd suggest still checking your manifests by hand to make sure you understand what's being generated. Whether you prefer manifest-first or code-first is a bit of a heated philosophical debate.
Look at bndtools. bndtools is using the same bnd that is underlying the maven bundle plugin. You can even use bndtools together with m2e. bndtools is available from the Eclipse market place.