PAYARA-1161 added ability to customise contents of Micro uberjar #1569
Conversation
|
jenkins test please |
|
One or more tests have failed |
|
jenkins test please |
|
All tests have passed |
|
|
||
| JarEntry deploymentEntry = new JarEntry(copyDirectory + file.getPath().replace(basePath, "")); | ||
| jos.putNextEntry(deploymentEntry); | ||
| Files.copy(file, jos); |
There was a problem hiding this comment.
I think that it's not enough that JAR files are copied as is - due to how Payara Micro works since version 171, all loadable JAR files should be uncompressed. Is that right, @smillidge, @Pandrex247 ?
Otherwise an attempt to load compressed JARs (which is almost every 3rd party distributed JAR) would lead to ZIP exceptions like the one reported here: https://groups.google.com/d/msgid/payara-forum/0f0e28fb-0645-4992-bdf0-6201d09d3df0%40googlegroups.com
There was a problem hiding this comment.
I think this would only be necessary if the JARs are to be placed into the MICRO-INF/lib folder. But it wouldn't hurt to convert all JARs to uncompressed JARs, because it would be very rare that users would want to place JARs somewhere else.
There was a problem hiding this comment.
the 3rd party jar does not need to be uncompressed but the zip entry storing it must be if placed in MICRO-INF/runtime or MICRO-INF/lib. However this is only a requirement if running with the nested jar classloader which be default Payara Micro doesn't
See https://github.com/payara/Payara/blob/master/appserver/extras/payara-micro/payara-micro-core/src/main/java/fish/payara/micro/impl/UberJarCreator.java#L191 it's an easy change
There was a problem hiding this comment.
What is the difference between this and deploymentDir (line 242)?
There was a problem hiding this comment.
@smillidge it's an easy change
I think that the code you linked works only if the original entry is uncompressed, otherwise size != compressed size, throwing an exception as reported in the mailing list. The fix needs to uncompress JAR files if the method is DEFLATED and store them uncompressed, it's not enough to just set the method to STORE.
There was a problem hiding this comment.
hmm true. I assume the person who asked the question had manually added the entry via zip or something.
There was a problem hiding this comment.
Deployment dir doesn't matter as it is not loaded via the nested classloader. Having the entry in STORED is only for the nested classloader which isn't the default anyway.
|
jenkins test please |
97cdd25 to
ee429e2
Compare
|
All tests have passed |
No description provided.