Cargo

Improvements to JarArchive / WarArchive

Details

  • Type: Improvement Improvement
  • Status: Closed Closed
  • Priority: Minor Minor
  • Resolution: Fixed
  • Affects Version/s: None
  • Fix Version/s: 0.8
  • Component/s: Module API
  • Labels:
    None
  • Number of attachments :
    2

Description

Currently the JarArchive / DefaultJarArchive only provides a read-only access.

It would be nice to have functionality to be able to modify (add/remove/change) the files within a Jar archive, explode the JAR into a directory, etc.

I don't know whether this should be in the interface (JarArchive), or only in the implementation (DefaultJarArchive).

Also, the current implementation stores the Jar (or war, etc) content as a member variable (private byte[] content). This means that if the archive is large it eats a lot of memory - it could (in findResource) create a JarInputStream from the File that it was passed originally.

  1. Text File
    jarPatch.patch
    23/Nov/05 8:34 AM
    7 kB
    Nigel Magnay
  2. Text File
    patch2.patch
    04/Jan/06 8:05 AM
    7 kB
    Nigel Magnay

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Vincent Massol added a comment -

I'm all for it! Sounds very good. I agree about your last comment about the jar storage implementation which doesn't scale with big files.

Show
Vincent Massol added a comment - I'm all for it! Sounds very good. I agree about your last comment about the jar storage implementation which doesn't scale with big files.
Hide
Permalink
Nigel Magnay added a comment -

Had a bit of a think around this - problem is that the JAR API is basically read-only. You could basically have a JARArchive that is a .jar file, a directory (exploded jar), or came from a stream (existing API). In the latter case, the JAR is definitely not updateable; the first two could potentially be updated...

As an initial patch I have added an 'expand to directory' method - this allows a jararchive to be expanded so it can be modified and re-jarred up. I'm using this in the merging stuff to build the merged WAR files and is a generally useful feature.

I have also refactored slightly to not load all of the file into memory in the event of the source being a File, because this can consume a lot of memory..

Show
Nigel Magnay added a comment - Had a bit of a think around this - problem is that the JAR API is basically read-only. You could basically have a JARArchive that is a .jar file, a directory (exploded jar), or came from a stream (existing API). In the latter case, the JAR is definitely not updateable; the first two could potentially be updated... As an initial patch I have added an 'expand to directory' method - this allows a jararchive to be expanded so it can be modified and re-jarred up. I'm using this in the merging stuff to build the merged WAR files and is a generally useful feature. I have also refactored slightly to not load all of the file into memory in the event of the source being a File, because this can consume a lot of memory..
Hide
Permalink
Nigel Magnay added a comment -

Update (patch2.patch) to patch against latest SVN layout.

Show
Nigel Magnay added a comment - Update (patch2.patch) to patch against latest SVN layout.
Hide
Permalink
grimsell grimsell added a comment -

Applied patch. Thanks Nigel.
Changed the behaviour of findResource(String) to pass new test cases.

Show
grimsell grimsell added a comment - Applied patch. Thanks Nigel. Changed the behaviour of findResource(String) to pass new test cases.

People

  • Assignee:
    grimsell grimsell
    Reporter:
    Nigel Magnay
Vote (0)
Watch (0)

Dates

  • Created:
    Updated:
    Resolved: