Extending Virgo with a HttpService
Several people have asked about us providing a packaging of Virgo that includes the OSGi HttpService. We don’t have any plans to do so because it’s so easy to extend Virgo with extra function yourself. I’m using the Equinox HttpService as the desired extra function here but the same approach applies no matter what you want to extend Virgo with.
All you need is the latest Virgo Kernel download, the Equinox HttpServer jar and it’s dependency the Servlet API jar. Unzip the Kernel and copy the two jars in to one of the repos. You have a choice of ‘repository/ext’ or ‘repository/usr’.
In this case ‘ext’ is the better choice as these bundles are being used to extend the core functionality of Virgo. If they were dependencies of an application then ‘usr’ would be the better choice.
There are two configuration files to edit.
- The ‘config/org.eclipse.virgo.kernel.userregion.properties’ file. At the very bottom, specify an additional initial artifact. The artifacts listed here will be started before any applications are installed. We need to list the Equinox HttpService bundle. The value is comma separated so after adding the new bundle you should have something like.
initialArtifacts =
repository:plan/org.eclipse.virgo.kernel.userregion.springdm,
repository:bundle/org.eclipse.equinox.http
- The HttpService requires some configuration itself, it needs to know which port to run on. This is given with the ‘org.osgi.service.http.port’ property and can be specified in the ‘lib/org.eclipse.virgo.kernel.launch.properties’ file.
org.osgi.service.http.port=8080
That’s all there is to it, start the kernel up and before any applications are installed the HttpService will be available. This is the same approach that should be used to extend Virgo in any other way and is exactly how the Tomcat and Jetty packages of Virgo are constructed. If you have extended Virgo in some way, let us know.
7 Comments
-
How to extend the Virgo Jetty Server to support the RAP Widget Toolkit « EclipseSource Blog
[…] our extension of Virgo as suggested here[4] into […]
-
Chris Frost
Hi,
Anything referenced in the initialArtifacts property will be actively ‘started’ by the server before any user applications are installed. Anything just in the repository directory will be pulled in and ‘resolved’ if something that is being started depends on it. So, Nothing depends on Vaadin so it must be referenced in the initialArtifacts property while Hibernate is required by something that is being ‘started’ and so get’s pulled in automatically by Virgo.
Hope that clears things up and sorry for the slow reply.
Chris. -
Miguel Salinas
One question in relation to initialArtifacts property in the Virgo config file org.eclipse.virgo.kernel.userregion.properties.
Why if a include any springsourcer bundle from his EBR remote repository like for example com.springsource.org.hibernate-3.3.2.GA.jar I don’t need to add any configuration to the initialArtifacts properties to be installed and however when I need to add, for example the Vaadin bundle, vaadin-6.4.10.jar exactly, I need to add the configuration to be installed?, I must to add any configuration to the initialArtifacts property when i must to installed any bundle from usr local repository from Virgo?, Why the com.springsource.org.hibernate-3.3.2.GA.ja is installed correctly despite not include any config?
-
Ryan
Thanks for the reply, Chris. I did finally manage to get Equinox HTTP up and running after much fumbling about.
First, it does depend on the log service package. The Import-Package directive in its manifest includes org.osgi.service.log;v
ersion=”1.0″. I finally figured out that org.eclipse.osgi.services-3.1.200.v20071203.jar seems to have all (or most) of the osgi interfaces in it, but that jar is only included in Virgo Web Server, not in Kernel. That seems kind of fishy to me. Shouldn’t the “service” jar be in the kernel so that all the OSGi service interface packages are available, even if implementations aren’t? That’s the reason, incidentally, that Equinox HTTP works fine in Web Server.After that, I had trouble figuring out how to set the HTTP port. Following your instructions didn’t seem to work, though I may have done something wrong. I found that I had to specify the org.osgi.service.http.port property in the userregion properties at config/org.eclipse.virgo.kernel.userregion.properties. I tried about a dozen other locations, including setting it as a system property, and none of them worked. I think I was deploying the http service through the pickup directory at that point, so maybe that’s related. I’m still a little fuzzy on the kernel/userregion division and how the repository ties into it.
I understand your “packaging” point of view with respect to the kernel and the different varieties of web server. Personally, I would prefer just two packages at this point: Virgo Kernel and Virgo Web Server, where the web packaging includes the tomcat bundles–active by default, the jetty bundles–inactive by default, and one or another of the stable HttpService implementations–active by default. (I think the ideal situation would be for the default HttpService to use the default web server.) Any other “packages” would also be welcome, and the end users can just turn them on and off using “initialArtifacts” or some other property. That seems to me a much more useful and flexible server, not to mention simpler than having to worry over multiple varieties of web server, when they’re really all the same thing, just with different plans active.
All that said, I’ve nearly got a proof of concept running in Virgo Web Server 2.1.1, and I think the remaining problem is with some of the bundles I’m trying to deploy related to Jersey.
-
Chris Frost
Hi,
Ha, you got me there. The Kernel in 2.1.1 does indeed not include the services jar for users to consume. I was looking for it trying to consume the Log service but it doesn’t need it, it needs the package to be exported. I assure you it is available in all the packagings of 3.0.0 and there is a good chance the service will be available as well. As for the configuration files, a change has been made to the way the Kernel and User regions are split out, as a result the correct location to specify the config has changed. We’ve made the change to keep ourselves in line with the specifications as the are agreed upon at the OSGi alliance. From 3.0.0 onwards all OSGi specific properties should go in ‘lib/org.eclipse.virgo.kernel.launch.properties‘.
The Virgo runtime has a number of bundles and to keep them from interfering with user applications (and visa versa) we keep them in the Kernel Region while all the users applications can go in the User Region. This also means that users applications aren’t tied to the same version of some libraries that we use, such as the Spring framework.
I hope you fair better with the rest of your work on Virgo, we really do want it to be easy. 3.0.0 will be out soon and just come back to us if you have any questions. Always happy to help.
Chris
-
-
Ryan
I’m curious what the rationale is behind not adding an HttpService. The “it’s easy to add one yourself” argument isn’t a very good one because it’s not very easy. I’ve been wrestling with it for several hours now. Aside from being not easy, it certainly defies the principle of least astonishment. I was quite astonished, to say the least, when my ServiceTracker didn’t find any HttpServices to track in the Virgo _Web_ Server.
Also, your instructions to just add the equinox http bundle + servlet-api bundle don’t work. Specifically, when trying to install the equinox http bundle in Virgo Kernel 2.1.1, it complains about a missing package: Import-Package: org.osgi.service.log; version=”1.0.0″. Naturally, I checked the equinox log bundle, but it doesn’t include that package. The only bundle I’ve found so far that does is a Felix one. Granted I’m new to Virgo, but it seems that, being a web server, an HttpService is the bare minimum that should be available.
-
Chris Frost
Hi,
Sorry to hear your having problems, I did this example on 3.0.0.M03 but went back and tried it on 2.1.1 to see whats what. I couldn’t find any problems, as 2.1.1 is based on Equinox 3.6.x I used the httpService from this download page, http://download.eclipse.org/equinox/drops/R-3.6.2-201102101200/index.php, It’s under the add-on section. I put the bundle in the ‘use’ repo and then did the config changes as in the blog post. The only difference is that I did this with the 2.1.1 web-server not the Kernel only build. This meant I didn’t have to go and get the servlet api jar and when changing the ‘initialArtifacts‘ property I removed the reference to the web plan and added one for the httpService bundle. I also enable the telnet console, when I started it up I could see the httpService being published. Will happily help further, just give some extra details over on the forum. I have just seen your post over there, apologies for the slow response but some extra details as to the step your doing would be helpful to diagnose further. The Equinox httpService bundle shouldn’t need the OSGi logService?
We’ve found it gets a little harder with the Jetty 6 one and is almost impossible with the PaxWeb one (which is just a repackaging of Jetty in to a single bundle). There are several additional bundles that can be deployed to enhance the functionality of the Equinox implementation if needed, such as ‘org.eclipse.equinox.jsp.jasper’ for JSP compilation. I really recommend sticking with the Equinox implementation.
Our view is that Virgo is the Virgo Kernel and the other packagings we provide are extensions to the Kernel. With the Web packages we went with the more Enterprise focused support for WABs (Web Application Bundles) which is another spec from the OSGi Alliance. You aren’t alone though as people have asked about the HttpService which was the reason for this blog post. We haven’t put both in a single packaging as it feels like duplication, no one has every requested both. It’s a trade off between how many different builds we can maintain compared to the benefit to the community. As for the OSGi Log service, this is very high on the list of new features and if it doesn’t make it in to the Kernel for 3.0 it’ll be close behind it.
So, sorry to hear you are having problems again, hope I’ve been able to help and explained our reasoning a little.
Chris.
-
Leave a Reply
This site uses Akismet to reduce spam. Learn how your comment data is processed.