Jbang ignores bundled MANIFEST.MF options in file of binary jar. #1852
Labels
bug
Something isn't working
Comments
|
Hmmm :/ yeah we don't call via jar because then it's impossible to add dependenicies vis class path reliably. At least thats my memory :) Is the jar supposed to be self-contained ? |
|
Yes. It's supposed to be a runnable, self-contained runtime that can be called to deploy a .war file. |
|
@pedanticdev could you pass the error you are getting? I've just tried this with JDK17 and 22 and in both cases things seem to Just Work(tm)? Edit: ah no, I see there is a warning somewhere in the log about a missing "opens". So it's not that the app fails to start but it just does n't work as it's supposed to. |
Indeed, according to the docs:
Seems to me that the only recourse we have is to support all the MANIFEST options that |
|
The server starts, but deployment fails as shown below But running the jar directly, I get If there is a way to pass the add-opens, I believe that should should be a workaround? Pardon me if I'm missing something obvious. |
|
@pedanticdev yes, there is Probably in the case of running a jar archive with a manifest.mf in it already should at least consider copying or somehow obeying what is listed in the manifest...because yeah, the issue is that |
|
I tried: basically add all opens by hand, but now fails with a bunch of runtime exceptions in hazelcast and others (too long to paste :) so its probably more than just all opens. |
|
Works fine here. But looks very ... intimidating. Is there a way to add the -R options to the json catalog file? |
Yes, there is a |
|
Ok this works Thanks a lot everyone. Still getting the hang of JBang. |
|
No, thank you for pointing out an issue we were not aware of! :-) |
|
So I'm not actually sure what is the "right" solution here. If calling a jar with zero dependecies we could just run the jar directly. But then can't add additional jars. So then we could consider adding a "-jar" option that honors jar run semantics. But question is then if we copy all the manifests flags when running normally we can't actually just copy to a manifest but rather have it be converted to explicit command line options... But not sure that will actually be equivalent behaviour. |
|
Well, couldn't we simply honor the |
|
Yes - could work. but I'm not sure about the module name. Does it matter? Or should we just treat the top level as unnamed module ? |
|
Well, I was hoping we could just take the names from those values and add |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the bug
It appears jbang does not call the jar file using the standard -jar. This results in ignoring any bundled MANIFEST.MF file. In the case of a jar file like Payara Micro, the manifest file contains the needed java modules for it to fully work. ATM jbang introspects the manifest file, and then proceeds to call the Main class of the jar file, passing it any Payara Micro args. This causes the startup to fail because Payara Micro doesn't have all the needed java modules to run properly. The same jar file starts fine with java -jar.
To Reproduce
Expected behavior
Payara Micro starts passing in the required params specified in the manifest (add-opens) file of the jar, reproduced below
JBang version
Paste output of
jbang version --verboseThe text was updated successfully, but these errors were encountered: