[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [virgo-dev] Building a custom artifact deployer

Thanks Glyn,

I've started experimenting with a custom deployer and I've just bumped
into a stumbling block.
It appears to me that an InstallArtifact is required to inherit from
AbstractInstallArtifact, at least judging by the exception thrown
shortly after my InstallArtifactTreeFactory has produced an
InstallArtifact (see stacktrace below).
I have only had a brief look at the AbstractInstallArtifact class and
seems to contain lots of logic. I'm not sure I would be comfortable
just extending it.
I'm getting a feeling that some code (VisitationStage?) is making too
many assumptions about the InstallArtifacts it operates on.
Should a bug be raised?

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)

best regards, Peter

On Tue, Jul 20, 2010 at 11:24 AM, Glyn Normington
<gnormington@xxxxxxxxxx> wrote:
> Hi Peter
> Ok, thanks. I've raised:
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=320368
> to promote ArtifactStorage to an exported package.
> Glyn
> On 20 Jul 2010, at 09:52, Peter Gardfjäll wrote:
>> Hi Glyn,
>> I guess I could make an attempt to write a sample custom deployer. I
>> don't have a toy example for Virgo yet.
>> What I have written, as part of another project, is code for
>> atomically deploying/starting/undeploying zip files containing bundle
>> jars (a "poor man's PAR" without scoping, pulling in dependencies,
>> etc).
>> I could try to adapt that code to the Virgo deployment interfaces.
>> I am currently on vacation so I can't give you a time frame yet.
>> The first step is to make sure all classes/interfaces that are to be
>> exposed in the public API are promoted to exported packages.
>> I'm not sure if ArtifactStorage is the only missing link here, but a
>> start would be to promote it and notify me when its done. Then I could
>> have a new go at it. When I have some working code I'll put it on
>> github.
>> best regards, Peter
>> On Fri, Jul 9, 2010 at 5:58 PM, Glyn Normington <gnormington@xxxxxxxxxx> wrote:
>>> Hi Peter
>>> Yes, InstallArtifactTreeFactory obeys the whiteboard pattern and the deployer will pick up any that are registered.
>>> Your right that the ArtifactStorage interface needs promoting to an exported package to be usable by 3rd parties.
>>> It would be good to collaborate on a toy example and then make that available as a Virgo sample. Compare [1].
>>> Would you be interested in stripping down what you are doing into a toy and, with my and possibly others' help, getting that going with Virgo with a view to contributing it as a sample? (I guess the best way would be to create a small project on github that I could then directly access rather than sending zips around, but you can call the shots here.)
>>> Regards,
>>> Glyn
>>> [1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=315867
>>> On 9 Jul 2010, at 15:21, Peter Gardfjäll wrote:
>>>> Hi,
>>>> as far as I can tell part of writing a custom artifact deployer for
>>>> Virgo is to register an InstallArtifactTreeFactory in the OSGi service
>>>> registry.
>>>> I assume that all such factories get picked up by the Virgo runtime.
>>>> Am I right so far...?
>>>> If that is indeed the correct approach, one apparent problem that
>>>> strikes me is that the ArtifactStorage interface, which is a parameter
>>>> of the InstallArtifactTreeFactory.constructInstallArtifactTree method,
>>>> is internal to the org.eclipse.virgo.kernel.deployer bundle (that is,
>>>> its package is not exported).
>>>> This makes it impossible for me to write a bundle with a custom tree factory.
>>>> Maybe some restructuring is required to simplify the development of
>>>> additional deployers?
>>>> What are your thoughts?
>>>> best regards, Peter
>>>> _______________________________________________
>>>> virgo-dev mailing list
>>>> virgo-dev@xxxxxxxxxxx
>>>> https://dev.eclipse.org/mailman/listinfo/virgo-dev
>>> _______________________________________________
>>> virgo-dev mailing list
>>> virgo-dev@xxxxxxxxxxx
>>> https://dev.eclipse.org/mailman/listinfo/virgo-dev
>> _______________________________________________
>> virgo-dev mailing list
>> virgo-dev@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/virgo-dev
> _______________________________________________
> virgo-dev mailing list
> virgo-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/virgo-dev