can't extract an archive from a URI?

[argherna]

Hello,

I'm working on a portlet that extracts archives uploaded to a server.
So far, it runs great on Mac OS X, but not on Windows XP Pro. I've
tried multiple ways of passing in the path to the archive, but Windows
is still giving my problems.

Basically, my portlet uploads a war file and saves it with the warfile
name in the java.io.tmpdir directory under Tomcat. When the process
tries to extract the archive, it errs out and gives the linked
stacktrace (link is good till 10/14/2009). Any thoughts on the matter
or advice is appreciated.

stacktrace on pastebin: http://pastebin.com/m358669ef

Andy

[Andrew Wills]

Andy,

If you can, please post the <extract-archive> element you've defined,
together with the underlying value of 'to-dir' if it's dynamic.

I've confirmed that something like the following (for to-dir) works on
Windows, and it should work on *nix as well as Mac:

<extract-archive location="something.zip"
to-dir="/C:/Users/awills/danann/cernunnos/otpt/"/>

The TO_DIR reagent on ExtractArchiveTask expects a file system
location, not a URL. It does a java.io-based write (not java.net).

drew

[Andy Gherna]

See attached files. The first is the action, the second (very
familiar) is the one where the stack trace occurs.

--
Andy Gherna
argh...@gmail.com
Twitter - http://twitter.com/argherna

[Andy Gherna]

Oops, use the attached deploy-portlet-app.crn file instead. This one
is what caused the stack trace.

[Andrew Wills]

Andy,

Looks like ${3} (a.k.a. ${targetDir}) is coming as
"file:/C:/dev/uPortal-myws-2.6.1/jakarta-tomcat-5.5.9/webapps/WeatherPortlet"
or something very close to that.

I think the 'to-dir' attribute on <extract-archive> will interpret
that as a relative path, and will look for a folder named 'file:' in
the current execution directory. But file (folder) names can't have
colons in them, and there you get the "filename, directory name, or
volume label syntax is incorrect" message.

The 'to-dir' attribute wants a file system path (not a URL).

drew

[Andy Gherna]

Comments in-line.

On Mon, Sep 14, 2009 at 6:39 PM, Andrew Wills <wills...@gmail.com> wrote:
>
> Andy,
>

> Looks like ${3} (a.k.a. ${targetDir}) is coming as
> "file:/C:/dev/uPortal-myws-2.6.1/jakarta-tomcat-5.5.9/webapps/WeatherPortlet"
> or something very close to that.
>

Right.

> I think the 'to-dir' attribute on <extract-archive> will interpret
> that as a relative path, and will look for a folder named 'file:' in
> the current execution directory.  But file (folder) names can't have
> colons in them, and there you get the "filename, directory name, or
> volume label syntax is incorrect" message.
>

OK. I changed the way the 'targetDir' ($3) is passed in. It is no
longer a URI from a File, but rather just a straight Windows path and
I've gotten past the extract problem.

But now, this same parameter is causing some problems with accessing
the files in the extracted archive. Take a look at
http://pastebin.com/m435e326e (link is good for 30 days). Based on
the scripts I posted yesterday, should the ${doc()} phrase use
something other than targetDir for it's path?

[argherna]

Also, changing the ${doc()} phrase to ${parseXml()} gives the same
stack trace.

On Sep 15, 11:31 am, Andy Gherna <arghe...@gmail.com> wrote:
> Comments in-line.
>

> On Mon, Sep 14, 2009 at 6:39 PM, Andrew Wills <wills.d...@gmail.com> wrote:
>
> > Andy,
>
> > Looks like ${3} (a.k.a. ${targetDir}) is coming as
> > "file:/C:/dev/uPortal-myws-2.6.1/jakarta-tomcat-5.5.9/webapps/WeatherPortlet"
> > or something very close to that.
>
> Right.
>
> > I think the 'to-dir' attribute on <extract-archive> will interpret
> > that as a relative path, and will look for a folder named 'file:' in
> > the current execution directory.  But file (folder) names can't have
> > colons in them, and there you get the "filename, directory name, or
> > volume label syntax is incorrect" message.
>
> OK.  I changed the way the 'targetDir' ($3) is passed in.  It is no
> longer a URI from a File, but rather just a straight Windows path and
> I've gotten past the extract problem.
>
> But now, this same parameter is causing some problems with accessing

> the files in the extracted archive.  Take a look athttp://pastebin.com/m435e326e(link is good for 30 days).  Based on

> the scripts I posted yesterday, should the ${doc()} phrase use
> something other than targetDir for it's path?
>
> --
> Andy Gherna

> arghe...@gmail.com
> Twitter -http://twitter.com/argherna

[argherna]

> > But now, this same parameter is causing some problems with accessing

> > the files in the extracted archive.  Take a look athttp://pastebin.com/m435e326e(linkis good for 30 days).  Based on

> > the scripts I posted yesterday, should the ${doc()} phrase use
> > something other than targetDir for it's path?
>

As it turns out, the answer to my question is yes. The parseXml
phrase expects a URI, not a file path. It uses Attributes.CONTEXT to
build full paths if the current path is relative (that is, it builds a
resolved URI). So, I set a value for Attributes.CONTEXT to be a file
URI and everything just worked.

[Andy Gherna]

Attaching the stack traces before pastebin erases them. Hoping they
will help others diagnose their problems in the future.