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

This is the same issue that I found a while back. Transformers just cast to abstract artifacts in some cases. 

I think there were a few more interfaces that are fairly central for processing and used by public interfaces but are not exported

I will find those references today

Sent from my iPhone

On Jul 23, 2010, at 4:45, Peter GardfjÃll <peter.gardfjell@xxxxxxxxx> 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