I think changing the extension to not include ".jar" in the zipped jar for an expanded directory should be easy to do. And I agree the ArtifactInstaller + exploded directory seems somewhat broken. Feel free to raise a JIRA (and eventually attach a patch).
On Tue, Mar 1, 2011 at 21:31, Alasdair Nottingham <[email protected]> wrote: > That doesn't work for me because I have to use the extension. Also I'm not > dealing with bundles here. > > If I'm honest this seems broken, my canHandle could pass, but install fail > because I can't deal with a directory, when offering to handle I don't know > if it is a file or a directory. > > Alasdair Nottingham > > On 1 Mar 2011, at 19:56, Guillaume Nodet <[email protected]> wrote: > >> The code doesn't work if you do a check based on the extension because >> if you've seen the extension is lost when using exploded bundles. >> What I've seen usually is to have the canHandle() method opening the >> jar and look for a specific file in the zip or manifest information do >> better determine if the artifact is supported or not. For example the >> pax-web deployer looks for a WEB-INF/web.xml file. >> >> On Tue, Mar 1, 2011 at 20:33, Alasdair Nottingham <[email protected]> wrote: >>> Hi, >>> >>> In aries we have an ArtifactInstaller for FileInstall that is will >>> install an OSGi Application. The code, in theory, can cope with it >>> being either an archive with a .eba extension, or an expanded >>> directory (also with a .eba extension). This does not work though. The >>> reason is that when canHandle is called I am provided a jared up >>> version of the directory, which ends with .jar. As a result canHandle >>> returns false. >>> >>> If it returned true then the install method is called, but is passed >>> the directory in watched directory. I was wondering why different >>> things are being passed in these two cases. What is the right way to >>> cope in this situation and correctly identify myself as being >>> responsible. >>> >>> Thanks >>> Alasdair >>> >>> -- >>> Alasdair Nottingham >>> [email protected] >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] >>> For additional commands, e-mail: [email protected] >>> >>> >> >> >> >> -- >> Cheers, >> Guillaume Nodet >> ------------------------ >> Blog: http://gnodet.blogspot.com/ >> ------------------------ >> Open Source SOA >> http://fusesource.com >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > -- Cheers, Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ Open Source SOA http://fusesource.com --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
