Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Virgo » Using plans with Virgo tooling(How can I use a Virgo plan within my development environment (Eclipse IDE)?)
Using plans with Virgo tooling [message #1000319] Mon, 14 January 2013 14:18 Go to next message
Simon Watson is currently offline Simon WatsonFriend
Messages: 30
Registered: September 2011
Member
I'm developing a project with Virgo 3.6 and I'd like to understand if it's possible to use a plan to install bundles within my Eclipse IDE.

I'd like to use a plan to control the order bundles are loaded in (this seems crucial for success with Gemini JPA & DBAccess). A plan works just fine in a production deployment (plan in pickup folder, bundles in /usr repo) but is it possible to make this work within the Eclipse IDE with Virgo tooling? In this environment, the plan would reference bundle projects in the Eclipse workspace.

Looking at bug report 379765 (https://bugs.eclipse.org/bugs/show_bug.cgi?id=379765), it seems like this isn't yet supported. However, the final bug comment talks about a workaround, where the stage folder is added as a watched repo when the Virgo server is started within Eclipse.

I've tried to replicate this by doing the following:

1. Create a copy my Virgo server's configuration folder called configuration-eclipse.
2. Edit org.eclipse.virgo.repository.properties in my new config folder to add the stage folder as a watched repo. The chain is set as stage,ext,usr
3. Modify the launch configuration of the server in Eclipse IDE to point at the new configuration by adding the argument: -Dorg.eclipse.virgo.kernel.config=configuration-eclipse
4. Create a simple test bundle (named foo.test) and test plan (test.plan) projects in my Eclipse workspace
5. Drag the plan onto the server in Eclipse. I can then expand the plan and see the bundle referenced (pretty neat, although I'm not sure what mechanism it uses to find the bundle at this point). Both the plan and the bundle JAR are present in Virgo's stage folder.
6. The server gives an error "Cannot find bundle 'foo.test' version range '[0.0.0, oo)' in repository 'ext-usr'". Where does 'ext-usr' come from?

What am I doing wrong? Should this approach work? Is there any way to check that Eclipse is using its new config?

I also notice a org.eclipse.virgo.repository.properties file in the stage folder - what creates this and why?

Beyond this simple test case, I would like the plan to reference both bundles in my workspace, and those in the /usr repo e.g. Gemini JPA bundles, DB driver.

Test bundle's manifest:

Manifest-Version: 1.0
Bundle-Vendor: Test
Bundle-Version: 1.0.0
Bundle-Name: TestBundle
Bundle-ManifestVersion: 2
Bundle-Description: Test
Bundle-SymbolicName: foo.test


Test plan manifest:

Manifest-Version: 1.0
Bundle-Version: 1.0.0
Bundle-Name: TestPlan
Bundle-ManifestVersion: 2
Bundle-SymbolicName: foo.test.plan


Test plan:

<?xml version="1.0" encoding="UTF-8"?>
<plan name="test.plan" version="1.0.0" scoped="true" atomic="true"
        xmlns="http://www.eclipse.org/virgo/schema/plan"
		xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
		xsi:schemaLocation="
		        http://www.eclipse.org/virgo/schema/plan
		        http://www.eclipse.org/virgo/schema/plan/eclipse-virgo-plan.xsd">

    <artifact type="bundle" name="foo.test" />
</plan>


Server output:

[2013-01-14 14:11:22.687]  TCP Connection(5)-127.0.0.1 <DE0000I> Installing plan 'test.plan' version '1.0.0'. 
[2013-01-14 14:11:22.688]  TCP Connection(5)-127.0.0.1 <DE0700E> Cannot find bundle 'foo.test' version range '[0.0.0, oo)' in repository 'ext-usr'. 
[2013-01-14 14:11:22.691]  TCP Connection(5)-127.0.0.1 <DE0002E> Installation of plan 'test.plan' version '1.0.0' failed. org.eclipse.virgo.nano.deployer.api.core.DeploymentException: Deployment of plan 'test.plan' version '1.0.0' in scope 'null' failed: bundle 'foo.test' in version range '[0.0.0, oo)' not found
	at org.eclipse.virgo.kernel.deployer.core.internal.PlanResolver.operate(PlanResolver.java:116)
	at org.eclipse.virgo.kernel.deployer.core.internal.PlanResolver.access$0(PlanResolver.java:92)
	at org.eclipse.virgo.kernel.deployer.core.internal.PlanResolver$1.visit(PlanResolver.java:86)
	at org.eclipse.virgo.util.common.ThreadSafeGraphNode.visitInternal(ThreadSafeGraphNode.java:193)
	at org.eclipse.virgo.util.common.ThreadSafeGraphNode.visit(ThreadSafeGraphNode.java:184)
	at org.eclipse.virgo.kernel.deployer.core.internal.PlanResolver.transform(PlanResolver.java:82)
	at org.eclipse.virgo.kernel.install.pipeline.stage.transform.internal.TransformationStage.doProcessGraph(TransformationStage.java:54)
	at org.eclipse.virgo.kernel.install.pipeline.stage.AbstractPipelineStage.process(AbstractPipelineStage.java:41)
	at org.eclipse.virgo.kernel.install.pipeline.internal.StandardPipeline.doProcessGraph(StandardPipeline.java:62)
	at org.eclipse.virgo.kernel.install.pipeline.internal.CompensatingPipeline.doProcessGraph(CompensatingPipeline.java:73)
	at org.eclipse.virgo.kernel.install.pipeline.stage.AbstractPipelineStage.process(AbstractPipelineStage.java:41)
	at org.eclipse.virgo.kernel.install.pipeline.internal.StandardPipeline.doProcessGraph(StandardPipeline.java:62)
	at org.eclipse.virgo.kernel.install.pipeline.stage.AbstractPipelineStage.process(AbstractPipelineStage.java:41)
	at org.eclipse.virgo.kernel.deployer.core.internal.PipelinedApplicationDeployer.driveInstallPipeline(PipelinedApplicationDeployer.java:359)
	at org.eclipse.virgo.kernel.deployer.core.internal.PipelinedApplicationDeployer.doInstall(PipelinedApplicationDeployer.java:185)
	at org.eclipse.virgo.kernel.deployer.core.internal.PipelinedApplicationDeployer.install(PipelinedApplicationDeployer.java:140)
	at org.eclipse.virgo.kernel.deployer.core.internal.PipelinedApplicationDeployer.deploy(PipelinedApplicationDeployer.java:253)
	at org.eclipse.virgo.kernel.deployer.management.StandardDeployer.deploy(StandardDeployer.java:52)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:597)
	at com.sun.jmx.mbeanserver.ConvertingMethod.invokeWithOpenReturn(ConvertingMethod.java:167)
	at com.sun.jmx.mbeanserver.MXBeanIntrospector.invokeM2(MXBeanIntrospector.java:96)
	at com.sun.jmx.mbeanserver.MXBeanIntrospector.invokeM2(MXBeanIntrospector.java:33)
	at com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:208)
	at com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:120)
	at com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:262)
	at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:836)
	at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:761)
	at javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1454)
	at javax.management.remote.rmi.RMIConnectionImpl.access$300(RMIConnectionImpl.java:74)
	at javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1295)
	at javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1387)
	at javax.management.remote.rmi.RMIConnectionImpl.invoke(RMIConnectionImpl.java:818)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:597)
	at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:303)
	at sun.rmi.transport.Transport$1.run(Transport.java:159)
	at java.security.AccessController.doPrivileged(Native Method)
	at sun.rmi.transport.Transport.serviceCall(Transport.java:155)
	at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:535)
	at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:790)
	at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:649)
	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
	at java.lang.Thread.run(Thread.java:680)
Caused by: org.eclipse.virgo.nano.deployer.api.core.DeploymentException: bundle 'foo.test' in version range '[0.0.0, oo)' not found
	at org.eclipse.virgo.kernel.deployer.core.internal.PlanResolver.obtainInstallArtifactGraph(PlanResolver.java:165)
	at org.eclipse.virgo.kernel.deployer.core.internal.PlanResolver.operate(PlanResolver.java:101)
	... 48 common frames omitted

[2013-01-14 14:11:22.694]  TCP Connection(5)-127.0.0.1 <DE0003E> Install failed for plan 'test.plan' version '1.0.0'. 
[2013-01-14 14:11:23.544]  TCP Connection(5)-127.0.0.1 <ME0003I> Dump 'serviceability/dump/2013-01-14-14-11-696' generated

Report message to a moderator

Re: Using plans with Virgo tooling [message #1001432 is a reply to message #1000319] Wed, 16 January 2013 17:28 Go to previous messageGo to next message
Simon Watson is currently offline Simon WatsonFriend
Messages: 30
Registered: September 2011
Member
I figured this out, at least enough for what I need to do right now Razz

I couldn't force Virgo to use an alternative configuration folder (neither -Dorg.eclipse.virgo.kernel.config=configuration-eclipse or -configDir=configuration-eclipse made a difference), so I just edited the default configuration/org.eclipse.virgo.repository.properties:

ext.type=external
ext.searchPattern=repository/ext/{artifact}
usr.type=watched
usr.watchDirectory=repository/usr
stage.type=watched
stage.watchDirectory=stage
chain=stage,ext,usr


My Virgo plan project in Eclipse IDE now works well, referencing both workspace bundles, and those in Virgo's /usr repository.

Given that I only use this local Virgo installation for my Eclipse IDE development, this works well for me.

Report message to a moderator

Re: Using plans with Virgo tooling [message #1008082 is a reply to message #1001432] Fri, 08 February 2013 20:02 Go to previous message
Leo Dos Santos is currently offline Leo Dos SantosFriend
Messages: 27
Registered: July 2009
Junior Member
Simon Watson wrote on Wed, 16 January 2013 12:28
I figured this out, at least enough for what I need to do right now Razz

I couldn't force Virgo to use an alternative configuration folder (neither -Dorg.eclipse.virgo.kernel.config=configuration-eclipse or -configDir=configuration-eclipse made a difference)


The tools actually write out their own VM arguments when they start up the server, so there's a good chance we were overwriting your changes. The irony is that the tools are supposed to point the runtime to the location of its own modified properties file for staging plans, but this was overlooked for Virgo 3.5+. I've prepared a fix for Virgo IDE 1.0.1

Report message to a moderator

Previous Topic:Inconvenient wiring diagrams in the admin console.
Next Topic:Installation of plan 'org.eclipse.virgo.web.tomcat' failed: FatalIOException: Cannot move path
Goto Forum:
  

[ Syndicate this forum (XML) ] [ RSS ]

Current Time: Tue Apr 23 06:40:38 GMT 2024

Powered by FUDForum. Page generated in 0.03981 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top

Sign up to our Newsletter

A fresh new issue delivered monthly