Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [virgo-dev] Building a custom artifact deployer 
Hi Peter

Yes, please raise a bug. We should either make AbstractInstallArtifact usable, possibly by documenting it better, or enable its use to be optional.

Please note that I am on vacation for 4 out of the next 5 weeks, so it may take a while for me to get around to the bug. OTOH someone else may like to have a go and produce a patch. ;-)

Regards,
Glyn
On 23 Jul 2010, at 09:45, Peter Gardfjäll wrote:

> 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?
> 
> 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)
> 
> 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
>> 
> _______________________________________________
> virgo-dev mailing list
> virgo-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/virgo-dev

Back to the top