Showing posts with label Virgo Tools. Show all posts
Showing posts with label Virgo Tools. Show all posts

Mar 10, 2017

Virgo 3.7.0 Released

 Today Florian announced the availability of Virgo 3.7.0. 

Virgo 3.7.0 brings several improvements (most notably Tomcat 8.5 and Spring Framework 4.2) and is paired by release 1.5.0 of the Virgo Tools, the Eclipse IDE integration.

This is the first official Virgo release since I joined the project as a committer, and it's also my first open source release in general. I am very happy and very proud of what we achieved.

Download Virgo and get Virgo Tools from the update site!

Jan 5, 2017

Virgo Tools 1.5

Since September 2015 I am a committer of the open source Eclipse Virgo project.

I have written several posts in the past about the Eclipse Virgo OSGi application server, and after having helped the project team with patches and bug fixes I have been invited by Florian, the project lead, to join the team as a committer.

I am an individual committer, contributing to the project in my spare time. I spent almost all of my effort on the Virgo Tools, the Eclipse plug-ins that integrate Virgo as a test environment in Eclipse. The most notable improvements of the upcoming version 1.5 of the Virgo tools will be:
  1. Support for PDE Plug-in projects. This is the possibility to develop for the Virgo runtime using the Eclipse PDE Tools, Plug-in Development Environment. This was one of the most requested and long standing missing features. See here and here.
  2. Improved support for plan projects. Virgo supports deployment of a number of artifacts, including Plans. Plans are XML files listing Bundles and other Plans to be activated. The Virgo Tools now provide fair support for having Plan files in Eclipse and deploying them to the test environment.
  3. Bug fixes and documentation
  4. Compatibility fixes for Eclipse Neon
We are currently planning to release the Virgo Tools 1.5 in January 2017 to be shortly followed by Eclipse Virgo 3.7.

Stay tuned!


Oct 2, 2012

Developing for Virgo server with Eclipse PDE

Last week I pushed to github an Eclipse plug-in released under the EPL license that allows using PDE plug-in projects with Virgo Tools. Source code, binaries and documentation are available here:   http://github.com/giamma/pde2virgo
 
The plug-in is pretty simple: it contributes a new builder to a PDE plug-in project and the builder takes care of copying the content of the META-INF folder, as well as any library referred by the Bundle-ClassPath header, to the project binary folder, where Virgo Tools expect those resources to be located.
 
To develop for Virgo using PDE you also have to properly configure the PDE target platform so that your plug-ins compile against the Virgo bundle repository. Plus, you must add the OSGi Bundle Nature to your PDE Plug-in projects, otherwise Virgo Tools won't let you deploy them to the server instance. More details are available in the github project wiki https://github.com/giamma/pde2virgo/wiki
 
I originally developed the plug-in in my spare time when looking for a solution that would allow me to develop OSGi bundles for Virgo Server using PDE plug-in projects rather than Virgo Tools' OSGi bundle projects. The plug-in is still affected by a couple of minor issues, but it works well and has been used by about ten colleagues of mine in the last three months. I decided to release it to the public because of this discussion https://bugs.eclipse.org/bugs/show_bug.cgi?id=329198 and because Eclipse gave me a lot in the last 8 years, so it was my turn to give back a little.

After some months developing with Eclipse Virgo Server for Apache Tomcat I can state that I am really glad I chose it as the target application server: it is a high-quality, lightweight OSGi enterprise app server capable of blending traditional Web Applications with OSGi applications, that provides great diagnostic features, meaningful error messages and that can significantly reduce your development time thanks to a fast start-up time and the ability to hot-swap OSGi bundles. Its Eclipse   integration, Virgo Tools, still needs some work, though.
 

Oct 1, 2012

First contact with Virgo Server, Virgo Tools, Eclipse Link

[Updated version of a post originally shared on G+ on the 22nd of June 2012]

My team and I have been working on an OSGi enterprise prototype since April 2012. We decided to use Eclipse Virgo Tomcat Server as our application server. Here is the experience collected so far, using Virgo 3.5M4 and version 1.0.0.201205110321-MILESTONE of the Virgo tools, both pre-release versions.

Documentation and other sources of information

Virgo comes with a lot of official documentation, and the documentation quality is generally high. On the other hand, if you look over the Web for articles, blog posts, forum posts etc you won't find that much besides the official documentation and the Eclipse community forums.
And while the quality of Virgo is generally very high, keep in mind that if you experience an uncommon issue, chances are that you will have to solve it on your own.
A good knowledge of the OSGi specification is really required to work with Virgo. Even long time Eclipse plug-in developers may have troubles developing proper OSGi bundles, because Eclipse plug-in developers are typically used to requiring bundles rather than importing packages, and because of the different boot delegation of Equinox when used in Eclipse, see http://blog.springsource.org/2009/01/19/exposing-the-boot-classpath-in-osgi/

Error reporting

Virgo is very good in giving you precise error and diagnostic information if your OSGi bundles fail to be resolved. The Virgo error messages are much much better than Equinox's and this is very very valuable.

Attention points

Even if Virgo is an OSGi application server, and even if it is based on Equinox, Virgo does not support split packages and does not favor required bundles.
I totally agree that split packages are evil, a very dangerous pitfall of the OSGi specification. So I was originally pretty happy with this decision, till I wanted to use the Equinox Registry in my application. In fact, I found out that the org.eclipse.core.runtime package is split across multiple bundles, and could not find a way to have the Equinox Registry bundles work "as is" in Virgo. A user in the Virgo Eclipse forums advised me to create a Plan (a virgo deployment artefact) that would include the bundles with the split package, but that did not solve my issue. I eventually worked around the problem by repackaging the Equinox registry bundles in a single bundle. Maybe other solutions are possible, but this was the fastest solution. The second important attention point is that Virgo authors dislike the use of Require-Bundle manifest header. I again understand the decision and I agree that one should prefer Import-Package, but what I dislike is that Virgo offers an alternative header attribute Import-Bundle that is Virgo specific, and does not belong to the OSGi specification. It is a sort of macro which will make Virgo enhance your bundle headers at deploy time to make them import all packages of the imported bundle. While this may appear as a convenient macro, it is Virgo specific and it will prevent your application from running in other OSGi containers or OSGi application servers (unless of course you modify the MANIFEST). So I have decided not to use it.

IDE Tools

If you are a long time Eclipse plug-in developer like me you are probably used to the PDE and love it, and you may expect to be able to develop bundles for Virgo using PDE.
Unluckily this is not possible, and you have to use the Virgo Tools, a totally different toolset. You could develop bundles with PDE, export them as binaries and deploy to Virgo, and it will of course work, but if you want to be able to build and run from the workspace your projects cannot be PDE plug-in projects but must be Virgo Tools' OSGi Bundle projects. The bad thing here is that developing with Virgo Tools is not as smooth as developing with PDE tools.
Here are a few examples:
  1. Much like PDE, Virgo Tools add a container to your project build path. The container should automatically populate the classpath according to bundle dependencies. In practice, the container is often out of sync resulting in spurious build errors, and you have to open the MANIFEST, add a blank, save and build to fix them. Plus, if you don't use autobuild, you'll need to build twice: once for the container to be updated after you change the MANIFEST and a second time for the code to be compiled after the container has updated. 
  2. If you want to import a package from another bundle in the workspace, you must enlist the other bundle in your Project References property page for the container to see it, but the MANIFEST editor will not help you, you'll need to switch to the source view and manually add the imported package. 
  3. If one of your workspace bundles exports packages that are included in some embedded JARs and you need another bundle to use classes from those packages, you'll have again to manually import the package, but you'll also need to add those JARs to your Java Project Buildpath, otherwise the dependant bundle will not compile, because the container will never see the JARs. 
There are a number of other smaller issues but the above are the most annoying.

Runtime Bugs

We spotted 3 defects, two related to the EclipseLink - Gemini JPA integration:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=381369
https://bugs.eclipse.org/bugs/show_bug.cgi?id=379397

And one in the EcilpseGemini Web component, part of Virgo Server:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=380362

As usual the Eclipse community has been great in providing support and advice to workaround the issues.

Great Virgo features

  1. Very good diagnostic tools. Logs, dumps, detailed wiring information, all those features simplify problem determination of malfunctioning OSGi applications. 
  2. User regions. You can deploy bundles in isolated user regions (exported packages and offered OSGi services will be visible and usable only by bundles in the same region). You can have the same bundles deployed more than once in different user regions, because virgo will qualify the bundle symbolic name with the region name. 
  3. Deployment artifacts galore. You can deploy to Virgo Tomcat Server bundles, plain WAR files, Plans, PARs, Web Application Bundles (WAB) and all that flexibility allows you to deploy OSGi enterprise applications and plain old Web Applications within the same Virgo instance. Plain WARs can even load classes from the deployed OSGi bundles. 
  4. Hot swapping. You can easily remove/add a deployment artefact (e.g. a bundle) from/to the server, without stopping the server and the application. Of course you need to make proper use of OSGi ServiceTrackers, the OSGi Extender pattern and write your application code to deal with such use cases. 
  5. No more issues with 3rd party libraries When working with traditional J2EE application servers a frequent issue consists in classloading problems that may originate when your application and the app server use different versions of the same third party library. In such cases, depending on the app server of use, you have different ways of bypassing the problem, but none of them is really perfect, and in general, I wish I'd never have to deal with such issues. I am glad OSGi and Virgo free me from those problems.

Conclusion

All in all Eclipse Virgo is an exciting piece of technology. It's a full featured OSGi and Web container packaged with lots of useful diagnostic features that enables blending traditional Web Applications with OSGi (enterprise) applications. True modularity is visible in Virgo itself, which comes in 3 different flavors (Nano, Kernel, Tomcat Server). I believe it's a solid product and probably the best option for OSGi enterprise applications.