I have an application that I am converting to OSGi, and there are a couple of
bundles that are required (for now). These are jars that are included in the
program distribution. What is the best way to install these? I was looking
at using a classpath:xxx.jar, but is there a better way to do this?
thanks,
Lance
I'm guessing that you want an easy way to start up your application, without having to install all bundles from the console at every startup. If that is your current problem, you can take a look at
http://paxrunner.ops4j.org/space/Pax+Runner , which eases the launching of the framework and deploying the bundles into it, or
http://njbartlett.name/bndtools.html , an excellent Eclipse plugin that helps you during development.
Another approach that could be satisfying is to create a feature containing all your bundles. See for a hint here. A feature is a package of bundles and it allows you to install a bunch of bundles with one command.
Related
I am starting develop modular apps with OSGi framework. My first concern is if I can develop using felix dependencies in my source code then later run my code in Concierge.
I looked for Concierge examples over the Internet, but there is no a good tutorial with examples at least I did not find out something good, please if you know something let me know.
So, my question is simply if I can develop using specifications and run everywhere in terms of platforms (Concierge, Felix, and others).
Thanks in advance for your support on it,
Regards,
-Rod
The OSGi specifications are split into three parts:
Core: These specifications are normally implemented by the OSGi framework. I am not sure if every framework supports all specs but until now I did not spot any that were not supported. So typically these are always available.
Compendium, Enterprise: These specifications are normally supported by specific bundles. So you have to make sure to install a bundle that implements the spec you want to use. For example you can install felix config admin if you want to use the configuration admin spec. Normally you can mix these like use equinox framework but still install felix config admin.
How would you implement a Plugin-system for your Java application?
Is it possible to have an easy to use (for the developer) system which achieves the following:
Users put their plugins into a subdirectory of the app
The Plugin can provide a configuration screen
If you use a framework, is the license compatible with commercial developement?
First you need an interface that all plugins need to implement, e.g.
public interface Plugin {
public void load(PluginConfiguration pluginConfiguration);
public void run();
public void unload();
public JComponent getConfigurationPage();
}
Plugin authors should then bundle their plugins into JAR files. Your applications opens the JAR file and could then use an attribute from JAR manifest or the list of all files in the JAR file to find the class that implements your Plugin interface. Instantiate that class, the plugin is ready to go.
Of course you may also want to implement some kind of sandboxing so that the plugin is restricted in what it can and can not do. I have created a small test application (and blogged about it) that consists of two plugins, one of which is denied access to local resources.
Use OSGi.
It is the foundation of the Eclipse plug-in system. Equinox is Eclipse's implementation (licensed EPL) and Felix is the Apache Project's implementation (licensed Apache Public License).
Eclipse provides a concrete example that OSGi can cover the points you mentioned (or you could just build your application on top of Eclipse RCP if you want a full Eclipse/SWT/JFace stack).
Since 1.6, there's been java.util.ServiceLoader which can be used if you want to code your own simple system.
But if you want anything more than basic features, use one of the existing frameworks.
Use PF4J.
It has support for Web, Spring and Wicket.
Easy to use and build the applications
There is also JPF (Java Plugin Framework).
I worked on OSGi for a week--an intense, nothing but OSGi week. At the end it was like a bad dream but I learned a lot.
I was able to get OSGi working (not easy, all examples are out of date, everything on the net is at least three years old if not five), but I had serious trouble getting it integrated into an existing project because of issues with the jar manifests.
In short, there are only a few obscure tools used for building manifests and they are not well documented (BND Tools is hardly obscure, but it is designed for a certain process in Eclipse). Also, most of the OSGi information available is not targeted towards application developers who have an existing desktop application.
This makes a lot of the context for the information foggy or inappropriate. Neil Bartlett's blog posts were the biggest help, but even those failed to get a working system (I grabbed some code from the Felix tutorial and pieced it together to get the embedded framework rolling). I found his book draft that he posted for free years ago, which is excellent, but the examples in Eclipse do not work because of changes in Eclipse OSGi support.
I think that recommending OSGi for solving the above stated problem is extremely poor advice. OSGi is "the right choice" but for a scenario as the one above, I think either JPF or some homegrown minimalistic framework is sufficient.
Years ago I started a project like that and I hope soon will be ready.I got inspired by projects like NetBeans and Eclipse but meanwhile it changed to something a little bit different. OSGi looks like a good choice now, but I didn't had a chance to compare it with my project.It is similar with JPF mentioned above, but in the same time different in many ways.
The basic idea which motivated me is to be as easy as possible to build Java application, with no separation between web applications, desktop applications or applet/JWS applications(of course this doesn't cover the UI - yet) as a core functionality.
I built the project with a few goals in my mind :
it doesn't matter if you build a web application or a desktop application you should start the application in the same way, a plain main method, No fancy web.xml declaration(not that I'm against having a standard web descriptor, but it doesn't go well with a plug-in system, where you add "servlets" - I call them RequestHandler(s) - dynamic at your will).
easy to plug in "extensions" around an "extension point" - something from Eclipse but a different approach.
self-deployable, since all the plugins are registered(XML files) the application must be self-deployable independent of the build system - of course there is an Ant task and a Maven MOJO which are the links with the ourside world, but in the end it calls the application and instruct it to self-deploy itself at a specific location.
borrowed from Maven, it can download code from repositories(including Maven 1 & 2 repositories) so your application can be deployed as a single small jar as long as you have access to the repositories(useful sometime, and basically this provides support for auto-updates - don't you love the idea to be notified by your web application that there is a newer version, it was downloaded and it just needs your permission to install it? I know I love that).
basic application monitoring about system health, email notifications in case of failures
How would you implement a Plugin-system for your Java application?
Is it possible to have an easy to use (for the developer) system which achieves the following:
Users put their plugins into a subdirectory of the app
The Plugin can provide a configuration screen
If you use a framework, is the license compatible with commercial developement?
First you need an interface that all plugins need to implement, e.g.
public interface Plugin {
public void load(PluginConfiguration pluginConfiguration);
public void run();
public void unload();
public JComponent getConfigurationPage();
}
Plugin authors should then bundle their plugins into JAR files. Your applications opens the JAR file and could then use an attribute from JAR manifest or the list of all files in the JAR file to find the class that implements your Plugin interface. Instantiate that class, the plugin is ready to go.
Of course you may also want to implement some kind of sandboxing so that the plugin is restricted in what it can and can not do. I have created a small test application (and blogged about it) that consists of two plugins, one of which is denied access to local resources.
Use OSGi.
It is the foundation of the Eclipse plug-in system. Equinox is Eclipse's implementation (licensed EPL) and Felix is the Apache Project's implementation (licensed Apache Public License).
Eclipse provides a concrete example that OSGi can cover the points you mentioned (or you could just build your application on top of Eclipse RCP if you want a full Eclipse/SWT/JFace stack).
Since 1.6, there's been java.util.ServiceLoader which can be used if you want to code your own simple system.
But if you want anything more than basic features, use one of the existing frameworks.
Use PF4J.
It has support for Web, Spring and Wicket.
Easy to use and build the applications
There is also JPF (Java Plugin Framework).
I worked on OSGi for a week--an intense, nothing but OSGi week. At the end it was like a bad dream but I learned a lot.
I was able to get OSGi working (not easy, all examples are out of date, everything on the net is at least three years old if not five), but I had serious trouble getting it integrated into an existing project because of issues with the jar manifests.
In short, there are only a few obscure tools used for building manifests and they are not well documented (BND Tools is hardly obscure, but it is designed for a certain process in Eclipse). Also, most of the OSGi information available is not targeted towards application developers who have an existing desktop application.
This makes a lot of the context for the information foggy or inappropriate. Neil Bartlett's blog posts were the biggest help, but even those failed to get a working system (I grabbed some code from the Felix tutorial and pieced it together to get the embedded framework rolling). I found his book draft that he posted for free years ago, which is excellent, but the examples in Eclipse do not work because of changes in Eclipse OSGi support.
I think that recommending OSGi for solving the above stated problem is extremely poor advice. OSGi is "the right choice" but for a scenario as the one above, I think either JPF or some homegrown minimalistic framework is sufficient.
Years ago I started a project like that and I hope soon will be ready.I got inspired by projects like NetBeans and Eclipse but meanwhile it changed to something a little bit different. OSGi looks like a good choice now, but I didn't had a chance to compare it with my project.It is similar with JPF mentioned above, but in the same time different in many ways.
The basic idea which motivated me is to be as easy as possible to build Java application, with no separation between web applications, desktop applications or applet/JWS applications(of course this doesn't cover the UI - yet) as a core functionality.
I built the project with a few goals in my mind :
it doesn't matter if you build a web application or a desktop application you should start the application in the same way, a plain main method, No fancy web.xml declaration(not that I'm against having a standard web descriptor, but it doesn't go well with a plug-in system, where you add "servlets" - I call them RequestHandler(s) - dynamic at your will).
easy to plug in "extensions" around an "extension point" - something from Eclipse but a different approach.
self-deployable, since all the plugins are registered(XML files) the application must be self-deployable independent of the build system - of course there is an Ant task and a Maven MOJO which are the links with the ourside world, but in the end it calls the application and instruct it to self-deploy itself at a specific location.
borrowed from Maven, it can download code from repositories(including Maven 1 & 2 repositories) so your application can be deployed as a single small jar as long as you have access to the repositories(useful sometime, and basically this provides support for auto-updates - don't you love the idea to be notified by your web application that there is a newer version, it was downloaded and it just needs your permission to install it? I know I love that).
basic application monitoring about system health, email notifications in case of failures
I'm using Eclipse Luna (64Bit) and I have to develop a System, which can manage several Plug-In's. The Plug-In's must be included at Runtime dynamically and I've read, that it is possible to do this with the OSGi-Framework. In Eclipse I started to implement some Example Plugin-Projects and now I want to include them into an another Eclipse Java-Project but thats over my head till now.
Is there a solution for this problem anyway or do I have to use another Framework?
Thanks for all answers!
Are you trying to write a plug-in for Eclipse or create your own plugin management system? If the latter, I'd suggest that you use OSGi as the basis instead of re-inventing the wheel. There's lots of good documentation on the 'net about how to do that.
I am just familiar with OSGi technology - never used but heard of it so many times. I've read several articles "for dummies" but I think I still fail to understand its use case completely. Maybe some of you could confirm if I understood it correctly.
Here is an example of what I might want to do.
Let us assume that I want to build a Java web application. Simple war. But, organized in such way that it contains different modules. Each module would contain different functionalities. Maybe each module would be packed as a separate jar, I am not sure.
Now, what I would like to have is UI part of the app capable of checking which of the modules are deployed too in order to show (or not) related menus, items, parts of pages, etc...
So, is the OSGi technology solution for this kind of problems or not? Is this what it is intended to be used for or am I off the track?
Thank you in advance for your answers.
Yes, OSGi technology is a solution for the kind of problem you mentioned in your question.
Eclipse is one solution that uses OSGi technology. In Eclipse, the UI would be an Eclipse Rich Client Platform (RCP), while the other modules would be Eclipse plug-ins. Each module would be a separate package that includes more components than a JAR.
You can use other solution platforms, or write all of the OSGi code yourself. The idea behind OSGi is to make your application more modular, so that you can update pieces of your application without having to update the entire application.
So, is the OSGi technology solution for this kind of problems or not? Is this what it is intended to be used for or am I of the track?
I would say this is exactly the kind of scenario OSGi caters for.
Look into the Eclipse RAP project, which runs on top of the Equinox OSGI container, and does the kind of thing you describe.
Some excellent tutorials are available on vogella.de.
Vaadin is an osgi based web framework in which you can accomplish this.
Alternatively you could have a look at the OSGI and Equinox book, it should contain enough info to help you roll your own solution.