Eclipse Community Forums: Virgo » Bundle refresh in virgo 3.0.2

Help

Home

Home » Eclipse Projects » Virgo » Bundle refresh in virgo 3.0.2(failed)

Show: Today's Messages :: Show Polls :: Message Navigator

Bundle refresh in virgo 3.0.2 [message #772255]

Thu, 29 December 2011 11:06

Eclipse Guest

Messages: 93
Registered: February 2013
Location: Vienna

Member

Hi all
When I try to refresh bundle(*.war) through osgi console it fails with next message

[2011-12-29 09:33:03.511] Thread-40322                 <DE0007I> Refreshing bundle 'my-bundle' version '3.2.0'.
[2011-12-29 09:33:27.497] Thread-40322                 <DE0070W> Cannot refresh bundle 'my-bundle' version '3.2.0' as the identity would change. The new identity would have been 'my-bundle-3.2.0' version '0.0.0'.

Difference between to manifests is only in "Bnd-LastModified" field

After googling I found that similar exception was in virgo 2.1.0
https://bugs.eclipse.org/bugs/show_bug.cgi?id=327209
but seems it had been fixed

Does anyone know what i'm doing wrong, cause it takes half a life for restarting a server each time Sad

Best regards, Alexander

Report message to a moderator

Re: Bundle refresh in virgo 3.0.2 [message #772372 is a reply to message #772255]

Thu, 29 December 2011 16:18

Borislav Kapukaranov

Messages: 80
Registered: September 2010

Member

Hi,

How did you deployed your WAR file? Also is it a WAB or a pure WAR?
From the error you're seeing it seems there is an attempt to transform the WAR after the installation, which is not what we do in the standard Virgo deployment pipeline.

If you could recreate the error with a simple WAR file and report a bug that would really help us better diagnose and fix the problem.

Thanks,
Borislav

Report message to a moderator

Re: Bundle refresh in virgo 3.0.2 [message #814550 is a reply to message #772372]

Tue, 06 March 2012 15:36

Hesham Saleh

Messages: 8
Registered: March 2012
Location: Cairo, Egypt

Junior Member

Hi all,

I don't know if bumping this thread is better than creating a new one, but I am currently facing a similar bundle identity problem with WABs on Windows 7 (7 only ?) environments, they are unable to be refreshed, both on Virgo 3.0.1.RELEASE and 3.0.2.RELEASE

On my Linux box I have been able successfully for months to refresh WABs, both from the OSGi console (using the Equinox vsh extension) and using the admin web tool (and on a Mac too), however in all the Windows PCs I have tried it on it always fails.

To reproduce this problem, on a Windows 7 environment start a vanilla Virgo (tried 3.0.1 and 3.0.2), then try to refresh the admin.web bundle.

Here are the logs:
eventlog:

[2012-03-06 16:49:12.053] qtp31925646-97               <DE0007I> Refreshing bundle 'org.eclipse.virgo.apps.admin.web' version '3.0.2.RELEASE'. 
[2012-03-06 16:49:21.631] qtp31925646-97               <DE0070W> Cannot refresh bundle 'org.eclipse.virgo.apps.admin.web' version '3.0.2.RELEASE' as the identity would change. The new identity would have been 'org.eclipse.virgo.apps.admin.web-3.0.2.RELEASE' version '0.0.0'. 
[2012-03-06 16:49:25.663] qtp31925646-97               <ME0002W> Dump contributor 'heap' failed during contribution to dump '1331045362803' org.eclipse.virgo.medic.dump.DumpContributionFailedException: Failed to generate heap dump contribution
	at org.eclipse.virgo.medic.dump.impl.heap.HeapDumpContributor.contribute(HeapDumpContributor.java:64)

...

log:

[2012-03-06 16:49:12.053] INFO  qtp31925646-97               org.eclipse.virgo.medic.eventlog.default                         DE0007I Refreshing bundle 'org.eclipse.virgo.apps.admin.web' version '3.0.2.RELEASE'. 
[2012-03-06 16:49:21.647] WARN  qtp31925646-97               org.eclipse.virgo.medic.eventlog.default                         DE0070W Cannot refresh bundle 'org.eclipse.virgo.apps.admin.web' version '3.0.2.RELEASE' as the identity would change. The new identity would have been 'org.eclipse.virgo.apps.admin.web-3.0.2.RELEASE' version '0.0.0'. 
[2012-03-06 16:49:25.913] WARN  qtp31925646-97               org.eclipse.virgo.medic.eventlog.default                         ME0002W Dump contributor 'heap' failed during contribution to dump '1331045362803' org.eclipse.virgo.medic.dump.DumpContributionFailedException: Failed to generate heap dump contribution
	at org.eclipse.virgo.medic.dump.impl.heap.HeapDumpContributor.contribute(HeapDumpContributor.java:64)
	at org.eclipse.virgo.medic.dump.impl.StandardDumpGenerator.generateDump(StandardDumpGenerator.java:67)
	at org.eclipse.virgo.medic.dump.impl.StandardDumpGenerator.generateDump(StandardDumpGenerator.java:54)
...
[2012-03-06 16:49:27.819] WARN  qtp31925646-97               o.e.virgo.kernel.shell.model.helper.StandardRamAccessorHelper     Unexpected error while trying to read the Runtime Artifact Model MBeans. type: 'bundle' name: 'org.eclipse.virgo.apps.admin.web' version: '3.0.2.RELEASE' 
...

I doubt if the virtual machine type/version would relate to this problem, however for the sake of providing as much information as possible, here are the both machines' info as appearing in the information section at the admin web tool:
Linux (Working): Sun Microsystems Inc.(Java HotSpot(TM) Server VM) - 17.1-b03, Sun Microsystems Inc. - 1.6.0_22, Linux(i386) - 2.6.35-24-generic-pae
Windows (Unworking): Sun Microsystems Inc.(Java HotSpot(TM) Client VM) - 14.3-b01, Sun Microsystems Inc. - 1.6.0_17, Windows 7(x86) - 6.1

Report message to a moderator

Re: Bundle refresh in virgo 3.0.2 [message #815157 is a reply to message #814550]

Wed, 07 March 2012 09:46

Hristo Iliev

Messages: 156
Registered: May 2010
Location: Sofia, Bulgaria

Senior Member

I tried to refresh the admin.web (id 109) but this works ok on my Windows 7.

What's the path in which you unpacked Virgo? It's always a good idea to use the root of the drive to avoid Windows path length limitations.

Report message to a moderator

Re: Bundle refresh in virgo 3.0.2 [message #815232 is a reply to message #815157]

Wed, 07 March 2012 11:55

Hesham Saleh

Messages: 8
Registered: March 2012
Location: Cairo, Egypt

Junior Member

Thanks Hristo for your reply, I placed it on the root of C and even renamed its directory as only "v", still no luck. Tried on both 3.0.1.RELEASE and 3.0.2.RELEASE.

Regarding the bundle ID, it was different in my case in a vanilla installation (id 120).

Edit: I tried also on a Windows XP, still no luck, the exact same problem.

[Updated on: Wed, 07 March 2012 12:02]

Report message to a moderator

Re: Bundle refresh in virgo 3.0.2 [message #815263 is a reply to message #815232]

Wed, 07 March 2012 12:42

Hristo Iliev

Messages: 156
Registered: May 2010
Location: Sofia, Bulgaria

Senior Member

Are you using tomcat or jetty distro?

Do you refresh via the vsh command - "vsh bundle refresh"?

Report message to a moderator

Re: Bundle refresh in virgo 3.0.2 [message #815299 is a reply to message #815263]

Wed, 07 March 2012 13:37

Hesham Saleh

Messages: 8
Registered: March 2012
Location: Cairo, Egypt

Junior Member

I am using the Jetty distro.

Well, after some more testing I realized that I can refresh a WAB successfully from the vsh extension only if started the server in clean mode then depended solely on vsh to refresh them. If however I started to use the web admin to refresh them it messes things up, and as a consequence sometimes vsh won't be able anymore to refresh that specific WAB. (May be this relates to some other file locking problems or something on Windows (both XP and 7), but anyway I think it is another separate issue).

Furthermore, I tried passing the server param to the Java VM (on Windows) so that Virgo used the server version of Java HotSpot, but I didn't notice any difference.

Should confirm though that everything is working fine on OS's other than Windows.

Report message to a moderator

Re: Bundle refresh in virgo 3.0.2 [message #815392 is a reply to message #815299]

Wed, 07 March 2012 15:50

Hristo Iliev

Messages: 156
Registered: May 2010
Location: Sofia, Bulgaria

Senior Member

On virgo-tomcat:

I opened the "org.eclipse.virgo.apps.admin.plan: 3.0.0" node then selected "org.eclipse.virgo.apps.admin.web: 3.0.2.RELEASE" and hit refresh 3 times in a row but the console is ok and logs in the serviceability contain only:

Illegal access: this web application instance has been stopped already. Could not load org.eclipse.gemini.web.tomcat.internal.loading.BundleWebappClassLoader. The eventual following stack trace is caused by an error thrown for debugging purposes as well as to attempt to terminate the thread which caused the illegal access, and has no functional impact. java.lang.IllegalStateException: null
at org.eclipse.gemini.web.tomcat.internal.loading.BundleWebappClassLoader.loadClass(BundleWebappClassLoader.java:269)

On virgo-jetty:

The same scenario produces the dump message you already provided plus this as a cause:

Caused by: java.io.IOException: File exists
        at sun.management.HotSpotDiagnostic.dumpHeap(Native Method)
        ... 65 common frames omitted

Can you please file a bug for the refresh?

[Updated on: Wed, 07 March 2012 15:52]

Report message to a moderator

Re: Bundle refresh in virgo 3.0.2 [message #815412 is a reply to message #815392]

Wed, 07 March 2012 16:22

Hesham Saleh

Messages: 8
Registered: March 2012
Location: Cairo, Egypt

Junior Member

Thank you Hristo for taking the time to reproduce this problem, I will file a bug just now.

Regarding the dump message, I also wondered why it says the file already existed, but I didn't give it much attention as dumping is actually a consequence of the failed refreshing as indicated in the tracing (but it is helpful as it seem to indicate in which class/line the error is):

at org.eclipse.virgo.kernel.install.artifact.internal.StandardArtifactStorage.unstashContent(StandardArtifactStorage.java:122)
	at org.eclipse.virgo.kernel.install.artifact.internal.StandardArtifactStorage.rollBack(StandardArtifactStorage.java:72)
	at org.eclipse.virgo.kernel.install.artifact.internal.AbstractInstallArtifact.[b]failRefresh[/b](AbstractInstallArtifact.java:446)
	at org.eclipse.virgo.kernel.install.artifact.internal.AbstractInstallArtifact.[b]failRefresh[/b](AbstractInstallArtifact.java:442)
	at org.eclipse.virgo.kernel.install.artifact.internal.AbstractInstallArtifact.[b]refresh[/b](AbstractInstallArtifact.java:426)
	at org.eclipse.virgo.kernel.model.internal.deployer.DeployerArtifact.refresh(DeployerArtifact.java:107)
	at org.eclipse.virgo.kernel.model.management.internal.DelegatingManageableArtifact.refresh(DelegatingManageableArtifact.java:101)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

Thanks again,

Report message to a moderator

Re: Bundle refresh in virgo 3.0.2 [message #816071 is a reply to message #815412]

Thu, 08 March 2012 11:44

Hesham Saleh

Messages: 8
Registered: March 2012
Location: Cairo, Egypt

Junior Member

For reference, the bug ID in bugs.eclipse.org is 373554 (unfortunately, can't post links)

Report message to a moderator

Re: Bundle refresh in virgo 3.0.2 [message #857156 is a reply to message #816071]

Thu, 26 April 2012 09:37

Peter Mucha

Messages: 6
Registered: August 2011

Junior Member

I stumbled upon the same bundle refresh problem.

[2012-04-26 10:27:25.414] fs-watcher                   <DE0007I> Refreshing bundle 'Client' version '1.0.0'.
[2012-04-26 10:27:29.158] fs-watcher                   <DE0070W> Cannot refresh bundle 'Client' version '1.0.0' as the identity would change. The new identity would have been 'Client' version '0.0.0'.

[2012-04-26 10:27:30.776] fs-watcher                   <ME0003I> Dump 'serviceability\dump\2012-04-26-10-27-518' generated
[2012-04-26 10:27:31.888] fs-watcher                   <ME0003I> Dump 'serviceability\dump\2012-04-26-10-27-784' generated
[2012-04-26 10:27:31.896] fs-watcher                   <HD0003E> Hot re-deploy failed for file 'Client.war'. org.eclipse.virgo.util.io.FatalIOException: Cannot move path '...\Virgo3\work\org.eclipse.virgo.kernel.deployer_3.0.1.RELEASE\staging\global\bundle\Client\1.0.0\Client.war-past' to '...\Virgo3\work\org.eclipse.virgo.kernel.deploy
er_3.0.1.RELEASE\staging\global\bundle\Client\1.0.0\Client.war'. Destination path already exists.
        at org.eclipse.virgo.util.io.PathReference.moveTo(PathReference.java:304)
        at org.eclipse.virgo.kernel.install.artifact.internal.StandardArtifactStorage.unstashContent(StandardArtifactStorage.java:120)
        at org.eclipse.virgo.kernel.install.artifact.internal.StandardArtifactStorage.rollBack(StandardArtifactStorage.java:72)
        at org.eclipse.virgo.kernel.install.artifact.internal.AbstractInstallArtifact.failRefresh(AbstractInstallArtifact.java:446)
        at org.eclipse.virgo.kernel.install.artifact.internal.AbstractInstallArtifact.refresh(AbstractInstallArtifact.java:434)
        at org.eclipse.virgo.kernel.deployer.core.internal.PipelinedApplicationDeployer.updateAndRefresh(PipelinedApplicationDeployer.java:226)
        at org.eclipse.virgo.kernel.deployer.core.internal.PipelinedApplicationDeployer.updateAndRefreshExistingArtifact(PipelinedApplicationDeployer.java:182)
        at org.eclipse.virgo.kernel.deployer.core.internal.PipelinedApplicationDeployer.doInstall(PipelinedApplicationDeployer.java:147)
        at org.eclipse.virgo.kernel.deployer.core.internal.PipelinedApplicationDeployer.install(PipelinedApplicationDeployer.java:136)
        at org.eclipse.virgo.kernel.deployer.core.internal.PipelinedApplicationDeployer.deploy(PipelinedApplicationDeployer.java:203)
        at org.eclipse.virgo.kernel.deployer.hot.HotDeploymentFileSystemListener.deploy(HotDeploymentFileSystemListener.java:174)
        at org.eclipse.virgo.kernel.deployer.hot.HotDeploymentFileSystemListener.onChange(HotDeploymentFileSystemListener.java:81)
        at org.eclipse.virgo.util.io.FileSystemChecker.notifyListeners(FileSystemChecker.java:245)
        at org.eclipse.virgo.util.io.FileSystemChecker.check(FileSystemChecker.java:166)
        at org.eclipse.virgo.kernel.deployer.hot.WatchTask.run(WatchTask.java:58)
        at java.lang.Thread.run(Thread.java:662)

The curious thing was, that some bundles could be refreshed, others dont. so i studies this problem a bit and found out, that, if for example the "Client" bundle above contains jars in the WEB-INF/lib-folder, a redeploy (= copy it to the pickup folder) would fail and the client needs to be deleted first and then deployed again.
but if there are no jars in the WEB-INF/lib folder, the normal redeploy works...

So as a workaround, it seems to work, if the libraries are in a non-standard directory, e.g. WEB-INF/libs (with all the needed entries in the Bundle-ClassPath). Then a redeploy works and the error disapears... (sadly, this is not easily doable in maven)

is this some kind of accidential locking due to implicit loading of all libs in the WEB-INF/lib directory, or did i do something wrong?

[Updated on: Thu, 26 April 2012 09:40]

Report message to a moderator

Re: Bundle refresh in virgo 3.0.2 [message #858822 is a reply to message #857156]

Fri, 27 April 2012 10:08

Glyn Normington

Messages: 1222
Registered: July 2009

Senior Member

I suspect the WEB-INF/lib clue is more relevant to bug 375043 which has been fixed in the 3.5 stream. A 3.5 milestone should be available in the next few days.

Bug 373554 is still to be fixed, but it's unlikely that WEB-INF/lib contents will affect that one.

Report message to a moderator

Re: Bundle refresh in virgo 3.0.2 [message #869523 is a reply to message #858822]

Thu, 03 May 2012 14:33

Peter Mucha

Messages: 6
Registered: August 2011

Junior Member

sadly, i am using Virgo-Tomcat!
also i thought, i already tried it on the new virgo 3.5 milestone, but i am not sure about that. i will test it again when i have time.
It looks like if the libraries are in another path, they will be loaded on accessing the bundle somehow. after loading, they seem to be locked and the same thing happens as when they are in the WEB-INF/lib path...

Report message to a moderator

Previous Topic:	PAR project compiler error in virgo
Next Topic:	Dependent Applications

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

]

Current Time: Thu Apr 25 22:11:21 GMT 2024

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter