Maven 2.x Webstart Plugin

[webstart] Pack200 shouldn't effect the original jar files.

Details

  • Type: Improvement Improvement
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Won't Fix
  • Affects Version/s: None
  • Fix Version/s: None
  • Component/s: pack
  • Labels:
    None
  • Number of attachments :
    1

Description

When creating a webstart artifact, the pack200 process shouldn't effect the original jars. (if someone disagrees with this then please feel free to comment!)

Packing and unpacking using the pack200 process results in a smaller jar with some of the class files' internal information removed. This may result in unpredictable behaviour when using clients that don't support pack200 at all.

I've attached a patch where I've tried to separate the pack200 process completely from the signing of the original jar files.

The patch also aims to solve the problems of signing webstart jar files that are already signed by a 3rd party certificate. This causes problems with pack200 because packing a file ruins the digital signature by virtue of changing the class files. I've failed in this regard because jarsigner doesn't seem to give you a way of checking whether a jar is already signed correctly. It doesn't differentiate between an unsigned jar and an invalid manifest format.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Jerome Lacoste added a comment -

David, thanks for the patch.

Questions:

> This may result in unpredictable behaviour when using clients that don't support pack200 at all.

I believed that deciding to pack200 was a conscious decision from the part of the application deployer. Do you deploy the same application in both pack200 and normal format?

What is your use case?

> The patch also aims to solve the problems of signing webstart jar files that are already signed by a 3rd party certificate

I have something to commit regarding that.

Other notes: I wonder if some people sign jars in separate modules and install them signed in the local repository.

Show
Jerome Lacoste added a comment - David, thanks for the patch. Questions: > This may result in unpredictable behaviour when using clients that don't support pack200 at all. I believed that deciding to pack200 was a conscious decision from the part of the application deployer. Do you deploy the same application in both pack200 and normal format? What is your use case? > The patch also aims to solve the problems of signing webstart jar files that are already signed by a 3rd party certificate I have something to commit regarding that. Other notes: I wonder if some people sign jars in separate modules and install them signed in the local repository.
Hide
Permalink
David Boden added a comment -

> I believed that deciding to pack200 was a conscious decision from the part of the application deployer. Do you deploy the same application in both pack200 and normal format?

When packaging an application, you can choose whether to support pack200 in addition to the normal jar downloads. These pack200 files will only be used if:

  • The webstart client suports pack200 compression format.
  • The web application that serves up the jars uses the JnlpDownloadServlet (or similar custom code) which knows how to route requests for .jar files to the corresponding .jar.pack files if and only if the client has specified in the HTTP header that pack200 is supported.

The deployer doesn't have control over all webstart target environments. By choosing to support pack200, the deployer is giving users who have pack200 compatable clients the choice to use this smaller, faster download. This addional feature should be invisible to users with clients that do not support pack200. That is, the original jar files should be left untouched by pack200.

Show
David Boden added a comment - > I believed that deciding to pack200 was a conscious decision from the part of the application deployer. Do you deploy the same application in both pack200 and normal format? When packaging an application, you can choose whether to support pack200 in addition to the normal jar downloads. These pack200 files will only be used if: The webstart client suports pack200 compression format. The web application that serves up the jars uses the JnlpDownloadServlet (or similar custom code) which knows how to route requests for .jar files to the corresponding .jar.pack files if and only if the client has specified in the HTTP header that pack200 is supported. The deployer doesn't have control over all webstart target environments. By choosing to support pack200, the deployer is giving users who have pack200 compatable clients the choice to use this smaller, faster download. This addional feature should be invisible to users with clients that do not support pack200. That is, the original jar files should be left untouched by pack200.
Hide
Permalink
Jerome Lacoste added a comment -

David, FYI, I've checked in code that will allow unsigning of the jars. I lack code that allow me to check which signature is currently applied on a jar.

Show
Jerome Lacoste added a comment - David, FYI, I've checked in code that will allow unsigning of the jars. I lack code that allow me to check which signature is currently applied on a jar.
Hide
Permalink
Jerome Lacoste added a comment -

Unfortunately this patch has bit rotten...

If there's anyone interested in this functionality, please try to revive it. I don't use pack200 so it's a bit hard for me to test the thing. I can help produce the patch if necessary.

Show
Jerome Lacoste added a comment - Unfortunately this patch has bit rotten... If there's anyone interested in this functionality, please try to revive it. I don't use pack200 so it's a bit hard for me to test the thing. I can help produce the patch if necessary.
Hide
Permalink
Jerome Lacoste added a comment -

Moving to 1.0-alpha-3 to cut a release soon.

Show
Jerome Lacoste added a comment - Moving to 1.0-alpha-3 to cut a release soon.
Hide
Permalink
Tony Chemit added a comment -

Extensions were introduce to deal with already signed dependencies, but I thnik this make the usage of the pack200 a bit messy, we should have a better look to this point.

Anyway once this done, can I close this issue or is there someone that has something to propose ?

Show
Tony Chemit added a comment - Extensions were introduce to deal with already signed dependencies, but I thnik this make the usage of the pack200 a bit messy, we should have a better look to this point. Anyway once this done, can I close this issue or is there someone that has something to propose ?
Hide
Permalink
Tony Chemit added a comment -

Extensions are a way to deal with already signed dependencies and it is not possible to pack200 with such dependencies.

There is no solution about this issue (FMHO).

Show
Tony Chemit added a comment - Extensions are a way to deal with already signed dependencies and it is not possible to pack200 with such dependencies. There is no solution about this issue (FMHO).

People

  • Assignee:
    Tony Chemit
    Reporter:
    David Boden
Vote (1)
Watch (3)

Dates

  • Created:
    Updated:
    Resolved: