Community
Participate
Working Groups
Build Identifier: virgo-kernel-2.1.0.BUILD-20100721141128 While writing a custom artifact deployer, I've run into a problem with the deployment pipeline, which apparently assumes that all InstallArtifact's extend the AbstractInstallArtifact class. Shortly after my InstallArtifactTreeFactory has produced an InstallArtifact the deployment pipeline (not sure of the terminology here, please correct me if I'm wrong) throws the following exception: java.lang.ClassCastException: org.eclipse.virgo.zipdeployer.internal.ZipInstallArtifact cannot be cast to org.eclipse.virgo.kernel.install.artifact.internal.AbstractInstallArtifact at org.eclipse.virgo.kernel.deployer.core.internal.Plumber$1.operate(Plumber.java:99) at org.eclipse.virgo.kernel.install.pipeline.stage.visit.internal.VisitationStage.doProcessNode(VisitationStage.java:51) at org.eclipse.virgo.kernel.install.pipeline.stage.AbstractPipelineStage.doProcessTree(AbstractPipelineStage.java:68) at org.eclipse.virgo.kernel.install.pipeline.stage.visit.internal.VisitationStage.doProcessTree(VisitationStage.java:58) at org.eclipse.virgo.kernel.install.pipeline.stage.AbstractPipelineStage.process(AbstractPipelineStage.java:41) at org.eclipse.virgo.kernel.install.pipeline.internal.StandardPipeline.doProcessTree(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:268) at org.eclipse.virgo.kernel.deployer.core.internal.PipelinedApplicationDeployer.doInstall(PipelinedApplicationDeployer.java:151) at org.eclipse.virgo.kernel.deployer.core.internal.PipelinedApplicationDeployer.install(PipelinedApplicationDeployer.java:123) at org.eclipse.virgo.kernel.deployer.core.internal.PipelinedApplicationDeployer.deploy(PipelinedApplicationDeployer.java:187) at org.eclipse.virgo.kernel.deployer.hot.HotDeploymentFileSystemListener.deploy(HotDeploymentFileSystemListener.java:174) at org.eclipse.virgo.kernel.deployer.hot.HotDeploymentFileSystemListener.onChange(HotDeploymentFileSystemListener.java:78) 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:619) Apparently the deployment code is making too many assumptions about the InstallArtifacts it operates on. The solution is probably one of the following: (1) Make sure the deployment pipeline only deals with InstallArtifacts (2) Document AbstractInstallArtifact to simplify its use. Without any detailed insight into the deployment machinery alternative (1) sounds like a cleaner approach (design-wise). Reproducible: Always
Thanks Peter, adding Dmitry to the copy list, could you add any extra details from the issue you found with Transformers just casting to abstract artifacts in some cases.
Chris, all I have at the moment is a minimalistic Eclipse plugin-development project. I guess I could compress that project and upload it together with instructions on how to build and add the deployer bundle to the Virgo runtime. Then you would be able to reproduce the exception yourself. Does that sound reasonable?
Hi Peter, Thanks for the offer of a minimal project. (Just attach a zip file to this Bugzilla.) Bugzilla https://bugs.eclipse.org/bugs/show_bug.cgi?id=320368 has been completed by Glyn and since been rippled up to all the repos. We do not anticipate being able to spend much more time on this issue ourselves until the 2.1.0 release is out. Of course that doesn't stop contributions from others. Would you be willing to look at the Kernel deployer to see how it could be improved? A suggested patch would be fantastic. http://wiki.eclipse.org/Virgo/Community Although the Kernel repo is one of the larger ones it is easy enough to build and import in to STS. If you need any help just ask, we will always have time to answer questions. Chris.
Created attachment 175817 [details] A minimalistic custom deployer (that recognizes .zip files) and can be used to reproduce the bug Contains an Eclipse Plug-in development project that contains a custom deployer recognizing .zip file artifacts. Instructions for building and running the bundle (within the Virgo runtime) and reproducing the error are provided in the README.txt file within the project.
A first step forward is to make sure that AbstractInstallArtifact gets promoted to an exported package. Currently, it is located in org.eclipse.virgo.kernel.install.artifact.internal, which makes it invisible to external deployers.
(In reply to comment #5) > A first step forward is to make sure that AbstractInstallArtifact gets promoted > to an exported package. Currently, it is located in > org.eclipse.virgo.kernel.install.artifact.internal, which makes it invisible to > external deployers. When I wrote it, I didn't pay much attention to making AbstractInstallArtifact externally consumable so either we should make Virgo not depend on InstallArtifact instances extending AbstractInstallArtifact or we should carefully review and document AbstractInstallArtifact to make it safe for external consumers to extend. I'd prefer the first approach for starters if this isn't too onerous and then we could follow up with the second approach in due course.
