Jump to: navigation, search

Difference between revisions of "Virgo/FAQ"

Line 67: Line 67:
 
Note that it is not necessary to change the version of Spring framework used by the Virgo kernel as that version is independent of the version of Spring framework used by the user region.
 
Note that it is not necessary to change the version of Spring framework used by the Virgo kernel as that version is independent of the version of Spring framework used by the user region.
  
If you want to use Spring framework version less than 3.0 (for instance 2.5.6.SEC2) you will have to use Virgo 2.1.x. The reason for this is that Virgo 3.0.x ships with Tomcat 7 and Servlet 3.0, while Spring framework 2.5.6 import range allows maximum Servlet 2.5 and this makes the two incompatible.
+
If you want to use Spring framework version less than 3.0 (for instance 2.5.6.SEC2) you will have to use Virgo 2.1.x or Virgo Jetty Server 3.0. The reason for this is that Virgo Tomcat Server 3.0.x ships with Tomcat 7 and Servlet 3.0, while Spring framework 2.5.6 import range allows maximum Servlet 2.5 and this makes the two incompatible.
  
 
= How can I programmatically deploy applications to Virgo?  =
 
= How can I programmatically deploy applications to Virgo?  =

Revision as of 05:35, 29 August 2011

How can I diagnose class loading problems?

See this blog.

What's a uses constraint and what can I do if one is violated?

Uses constraints are explained in this blog.

Virgo typically produces helpful diagnostics for uses constraint violations. To solve uses constraint violations, see Rob Harrop's blog and Neil Bartlett's blog.

How can I import a package into someone else's bundle without hacking the manifest?

See this blog.

What support does Virgo have for thread context class loaders?

See this blog.

How can I get a graphical application to work in Virgo?

To get GUI apps to work in Virgo, you have to edit lib/java6-server.profile in order to add some packages to the org.osgi.framework.bootdelegation property.

On Mac, you need to add some Apple packages:

org.osgi.framework.bootdelegation = \
 org.eclipse.virgo.osgi.extensions.*,\
 org.eclipse.virgo.osgi.launcher.*,\
 org.eclipse.virgo.kernel.authentication,\
 com.sun.*,\
 javax.xml.*,\
 org.apache.xerces.jaxp.*,\
 org.w3c.*,\
 org.xml.*,\
 sun.*,\
 apple.*,\
 com.apple.*

On Windows, you just need to add com.sun.* as sun.* is already in the list.

org.osgi.framework.bootdelegation = \
 org.eclipse.virgo.osgi.extensions.*,\
 org.eclipse.virgo.osgi.launcher.*,\
 org.eclipse.virgo.kernel.authentication,\
 com.sun.*,\
 javax.xml.*,\
 org.apache.xerces.jaxp.*,\
 org.w3c.*,\
 org.xml.*,\
 sun.*,\
 com.sun.*

How can I change the version of Spring framework in the user region?

You can upgrade or downgrade the version of Spring framework in the user region provided the new version satisfies the version range required by Virgo. Virgo 3.0.x can use Spring framework 3.0 or greater.

To upgrade or downgrade, delete the Spring framework bundles and .libd file in repository/ext and then add the corresponding bundles and .libd file for the replacement version of Spring framework. The Spring framework bundles are listed in the .libd file if you are uncertain about which they are. Then re-start Virgo with the -clean switch and the user region should now run with the replacement version of Spring framework.

Here's an example of upgrading Spring framework on a UNIX system:

cd repository/ext/
rm org.springframework.*-3.0.5.RELEASE.*
cp /.../spring-framework-3.0.6/dist/org.springframework.* .

Note that it is not necessary to change the version of Spring framework used by the Virgo kernel as that version is independent of the version of Spring framework used by the user region.

If you want to use Spring framework version less than 3.0 (for instance 2.5.6.SEC2) you will have to use Virgo 2.1.x or Virgo Jetty Server 3.0. The reason for this is that Virgo Tomcat Server 3.0.x ships with Tomcat 7 and Servlet 3.0, while Spring framework 2.5.6 import range allows maximum Servlet 2.5 and this makes the two incompatible.

How can I programmatically deploy applications to Virgo?

This can be achieved using the MBeans registered by Virgo. It's best to explore them first using something like JConsole. The deployer MBean can be used to specify an artifact with a URI that should be deployed (installed and started). Prefixes "file:" and "repository:" can be used. In the case of repository a URL of the form "repository://type/name[/version]" will refer to an artifact in a provisioning repository. The square brackets indicate that the trailing "/version" is optional, in which case Virgo uses the highest version available, and are not part of the URL. In the case of a bundle, "type" is "bundle" and "name" is the bundle symbolic name (and if "version" is specified, it is the bundle version).

Note that you can also install bundles using BundleContext.installBundle and they will be installed in the same region as the bundle whose BundleContext used to perform the install. However, bundles installed in this way will not pass through the Virgo deployment pipeline and will not be subject to the transformations normally applied to bundles as they are deployed in Virgo.