Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > Repacking jar files...

Reply
Thread Tools

Repacking jar files...

 
 
Simon Brooke
Guest
Posts: n/a
 
      05-14-2004
To configure webapps for delivery, I'm working on a configurer which

1: makes a copy of the distribution war file and unpacks it
2: makes substitutions in key configuration files, usually WEB-INF/web.xml
3: repacks the war file.

Unfortunately I'm having problems with repacking the war file. Quick reminder
- a war file is essentially a jar file containing a webapp, so if you've
exerience of repacking jar files you can probably help.

The symproms of the problem are

I do create a file, but

* When unpacked with ark (the KDE archiver) v2.1.9 all the contents can
be read and the archive appears perfect.

* When unpacked with jar as distributed in Sun j2sdk1.4.0, nothing is
unpacked and I get

java.util.zip.ZipException: missing entry name
at java.util.zip.ZipInputStream.readLOC(ZipInputStrea m.java:223)
at java.util.zip.ZipInputStream.getNextEntry(ZipInput Stream.java:72)
at sun.tools.jar.Main.extract(Main.java:676)
at sun.tools.jar.Main.run(Main.java:190)
at sun.tools.jar.Main.main(Main.java:904)

* When unpacked with Info-ZIP's zip v2.3, it seems to unpack alright but
things which should be directories come out as empty files.

* When unpacked with Win-ZIP

* When installed into tomcat 4, things in the root directory of the
webapp can be accessed, but nothing else can be, so I'm assuming that
it's doing very much the same thing as Info-ZIP is doing.

Anyone got any helpful insights? I can't see anything in the API which
allows me to mark a JarEntry as a directory, and I can't account for the
'missing entry name' problem.

The code I am using to repack the war file is as follows:

/**
* repack the contents of the specified directory into a WAR archive file
*
* @param dir the directory to pack
*
* @throws IOException if anything goes wrong
*/
protected void repack( Context context, File dir )
throws IOException
{
File oldMeta =
new File( dir, "META-INF" /* is this JarFile.MANIFEST_NAME? */ );

if ( oldMeta.exists( ) )
{
// TODO: should we do aything to carry forward the contents of oldMeta? If so what?
deleteDir( oldMeta );
}

File pack =
new File( dir.getParent( ), context.get( APPNAMETOKEN ) + ".war" );

JarOutputStream jout =
new JarOutputStream( new FileOutputStream( pack ) );

Stack toWrite = new Stack( );

toWrite.push( dir );

while ( !toWrite.empty( ) )
{
File current = (File) toWrite.pop( );

jout.putNextEntry( new JarEntry( getRelativePath( current, dir ) ) );

if ( current.isDirectory( ) )
{
/** push all my files and subdirs onto the stack */
String[] children = current.list( );

for ( int child = 0; child < children.length; child++ )
{
toWrite.push( new File( current, children[child] ) );
}
}
else
{
/** write contents of file to stream */
InputStream in =
new BufferedInputStream( new FileInputStream( current ) );

for ( int i = in.read( ); i > -1; i = in.read( ) )
jout.write( i );
}
}

jout.flush( );
jout.close( );

/* compute the URL of the newly created delivery package and cache
* it in the context. There must be a better way of doing this. */
HttpServletRequest req =
(HttpServletRequest) context.get( REQUESTMAGICTOKEN );
ServletContext sc = getServletContext( );

URL requrl = new URL( req.getRequestURL( ).toString( ) );
File root = new File( sc.getRealPath( "" ) );

context.put( DELIVERYPACKAGEURLTOKEN,
new URL( requrl.getProtocol( ), requrl.getHost( ),
requrl.getPort( ),
sc.getServletContextName( ) + File.separator +
getRelativePath( pack, root ) ) );
}

/**
* get the relative path of file, presumed to be contained within dir or
* some subdirectory of dir, from dir
*
* @param file a file
* @param dir a directory which encloses it
*
* @return the relative path, or (for the time being) the canonical path
* if file is not within dir.
*/
private String getRelativePath( File file, File dir )
throws IOException
{
String result = file.getCanonicalPath( );

/*
* OK, we need the relative pathname of current with respect to dir
* this is a hack. TODO: find a guaranteed safe way to do this
*/
String dirCanonical = dir.getCanonicalPath( );
String currentCanonical = file.getCanonicalPath( );

if ( currentCanonical.indexOf( dirCanonical ) == 0 )
{
/* i.e. if the canonical name of the current file starts with
* the canonical name of the directory we're packing - which
* it should */
result = currentCanonical.substring( dirCanonical.length( ) );
}

if ( result.startsWith( File.separator ) )
{
result = result.substring( 1 );
}

return result;
}


--
(Simon Brooke) http://www.jasmine.org.uk/~simon/

For office use only. Please do not write or type below this line.

 
Reply With Quote
 
 
 
 
Andrew Thompson
Guest
Posts: n/a
 
      05-14-2004
On Fri, 14 May 2004 14:35:01 GMT, Simon Brooke wrote:

(problems with .WAR)
> * When unpacked with ark (the KDE archiver) v2.1.9 all the contents can
> be read and the archive appears perfect.


*

> * When unpacked with jar as distributed in Sun j2sdk1.4.0, nothing is
> unpacked and I get
>
> java.util.zip.ZipException: missing entry name
> at java.util.zip.ZipInputStream.readLOC(ZipInputStrea m.java:223)

....
> * When unpacked with Info-ZIP's zip v2.3, it seems to unpack alright but
> things which should be directories come out as empty files.


Those last two result make it sound like the Jar's
TOC is corrupt. For further info. on Zip
ToC's, see in this recent thread..
<http://google.com/groups?threadm=srSdndHRtf9jzRPdRVn-sQ%40nildram.net&rnum=25>
(Check especially Chris Uppal's detailed explanation).

* From that it seems KDE Archiver is utterly
ignoring the ToC and reading each file out
in order. I would say use it to extract the
bad file.

Just a thought.

--
Andrew Thompson
http://www.PhySci.org/ Open-source software suite
http://www.PhySci.org/codes/ Web & IT Help
http://www.1point1C.org/ Science & Technology
 
Reply With Quote
 
 
 
 
Chris Uppal
Guest
Posts: n/a
 
      05-17-2004
Simon Brooke wrote:

> if you've
> exerience of repacking jar files you can probably help.


I'm not sure that will is address the problem you are seeing. But I've seen no
other replies, so...

It might be that you are generating a malformed "Zip" file by attempting to
create directory entries.

The most common convention (there doesn't seem to be a standard) is not to
include entries for any directories at all. So it's up to the decoding
application to infer their existence from the names of any files that are "in"
them.

A second convention is to create entries with a trailing '/' in their names,
and no contents. This is more likely to work (not confuse other zip
applications) if you also set the so-called "internal attributes" to the MSDOS
directory marker, however the Java API's provide no access to that. Note that
writing 0 bytes to the contents is NOT the same thing as having no contents if
the entry is compressed, since compressing a 0-length string produces a couple
of bytes.

So I suggest you don't generate directory entries at all, or -- if that doesn't
work for some reason -- then you fall back to creating them *uncompressed* and
with a trailing '/' to the name.

-- chris


 
Reply With Quote
 
Andrew Thompson
Guest
Posts: n/a
 
      05-17-2004
On Mon, 17 May 2004 10:00:45 +0100, Chris Uppal wrote:
...
> ...But I've seen no
> other replies, so...


Something wrong with news server I suspect..
<http://google.com/groups?th=fc9bffd97194785a>

And the follow-up (on a different thread)
<http://google.com/groups?th=415f433921f6c827>

--
Andrew Thompson
http://www.PhySci.org/ Open-source software suite
http://www.PhySci.org/codes/ Web & IT Help
http://www.1point1C.org/ Science & Technology
 
Reply With Quote
 
Roedy Green
Guest
Posts: n/a
 
      05-17-2004
On Mon, 17 May 2004 10:00:45 +0100, "Chris Uppal"
<> wrote or quoted :

>It might be that you are generating a malformed "Zip" file by attempting to
>create directory entries.


The decoder thinks they are files and creates them. That prevents it
from creating directories later of that same name.

Check the zip spec to see if there is a directory attribute bit.

Anyway,just leave out the directories. Every decoder automatically
creates them as needed.

--
Canadian Mind Products, Roedy Green.
Coaching, problem solving, economical contract programming.
See http://mindprod.com/jgloss/jgloss.html for The Java Glossary.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Repacking an array of arrays Kaps Lok Ruby 11 07-10-2007 10:39 PM
security exceptions after jar repacking Magnus Warker Java 15 04-19-2007 05:19 AM
Differences of xercesImpl.jar, xercesImpl-J.jar, dom3-xercesImpl.jar ? Arnold Peters Java 0 01-05-2005 10:59 PM
Repacking jar files: solution Simon Brooke Java 0 05-17-2004 06:35 AM
Battery Repacking David NZ Computing 2 08-29-2003 11:45 AM



Advertisments
 



1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57