|
|
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
|
|
|
Re: Bundle refresh in virgo 3.0.2 [message #815157 is a reply to message #814550] |
Wed, 07 March 2012 09:46 |
|
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.
|
|
|
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 #815392 is a reply to message #815299] |
Wed, 07 March 2012 15:50 |
|
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 #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
|
|
|
|
|
Powered by
FUDForum. Page generated in 0.05229 seconds