Return-Path: Delivered-To: apmail-felix-users-archive@minotaur.apache.org Received: (qmail 82150 invoked from network); 1 Mar 2011 23:34:05 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 1 Mar 2011 23:34:05 -0000 Received: (qmail 60336 invoked by uid 500); 1 Mar 2011 23:34:05 -0000 Delivered-To: apmail-felix-users-archive@felix.apache.org Received: (qmail 60149 invoked by uid 500); 1 Mar 2011 23:34:04 -0000 Mailing-List: contact users-help@felix.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: users@felix.apache.org Delivered-To: mailing list users@felix.apache.org Received: (qmail 60129 invoked by uid 99); 1 Mar 2011 23:34:04 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 01 Mar 2011 23:34:04 +0000 X-ASF-Spam-Status: No, hits=-0.7 required=5.0 tests=FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of gnodet@gmail.com designates 74.125.82.53 as permitted sender) Received: from [74.125.82.53] (HELO mail-ww0-f53.google.com) (74.125.82.53) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 01 Mar 2011 23:33:59 +0000 Received: by wwb29 with SMTP id 29so4248244wwb.10 for ; Tue, 01 Mar 2011 15:33:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type:content-transfer-encoding; bh=lh8cVmHRcTahA6zVhhtGO6ql3Q7QzjNiEcL8EW0o/38=; b=mzbTyAEbh0GPs6rxiYH61qFq7NAMIfUBT7v9gThoFTALZ6uq4lrhqOQ9PXavSXB2zj KjBdPkq0P/EYgCtchw7pdnCQ9izEcTRvdVcmDHLrkJ/sZxC2IkytV+dKFhWduk6baoXn Hu6bfmes6Mb4Iavab1+c9fsndLbU4VHWQo2LE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=H5fWV5A7KE3UyLhatXj288IKyL/IljAh9bShnXmSnjaKzjnAMYJA7VzSfPedqDdfBE jSBjv8Hv1cKnfggpAYE9sZCcNfIllf8CgsRqRvZ+R1NfzQIUc1dlVHSd/svZwUIm+Gzb kGJPeggmP4771vYpukQ+zEPryzNSoitDQ0zMk= MIME-Version: 1.0 Received: by 10.227.30.141 with SMTP id u13mr1911431wbc.225.1299022417501; Tue, 01 Mar 2011 15:33:37 -0800 (PST) Received: by 10.227.156.139 with HTTP; Tue, 1 Mar 2011 15:33:37 -0800 (PST) In-Reply-To: <19319862-16D1-48A0-A83B-432FEABC39AE@apache.org> References: <19319862-16D1-48A0-A83B-432FEABC39AE@apache.org> Date: Wed, 2 Mar 2011 00:33:37 +0100 Message-ID: Subject: Re: ArtifactInstaller.canHandle being passed a jar From: Guillaume Nodet To: users@felix.apache.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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 broke= n. Feel free to raise a JIRA (and eventually attach a patch). On Tue, Mar 1, 2011 at 21:31, Alasdair Nottingham wrote: > That doesn't work for me because I have to use the extension. Also I'm no= t dealing with bundles here. > > If I'm honest this seems broken, my canHandle could pass, but install fai= l because I can't deal with a directory, when offering to handle I don't kn= ow if it is a file or a directory. > > Alasdair Nottingham > > On 1 Mar 2011, at 19:56, Guillaume Nodet 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. =A0For example the >> pax-web deployer looks for a WEB-INF/web.xml file. >> >> On Tue, Mar 1, 2011 at 20:33, Alasdair Nottingham 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 >>> not@apache.org >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org >>> For additional commands, e-mail: users-help@felix.apache.org >>> >>> >> >> >> >> -- >> Cheers, >> Guillaume Nodet >> ------------------------ >> Blog: http://gnodet.blogspot.com/ >> ------------------------ >> Open Source SOA >> http://fusesource.com >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org >> For additional commands, e-mail: users-help@felix.apache.org >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscribe@felix.apache.org > For additional commands, e-mail: users-help@felix.apache.org > > --=20 Cheers, Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ Open Source SOA http://fusesource.com --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@felix.apache.org For additional commands, e-mail: users-help@felix.apache.org