Enhancement: Add bundle config property that allows custom libs to be available at server boot time / FISH-6305

[CarlosMOGoncalves]

Description

---

Hello friends,

With this issue I am requesting for a new configuration property to be added to the Payara Micro Maven Plugin, more specifically to the bundle goal.

The purpose of this proposed config property would be to define one or more jars that would be added to MICRO-INF/runtime directory within the generated bundle (or any other directory that would allow the bootstrap main class to have access to these immediatly at boot time).

The reasons for this are:

• There is a need to expand standard Payara Micro logging functionality and, in order to do this, one needs to provide a library with some JUL classes that must be present at boot time, so that there are no logs missed and so that each application doesn't need custom boot code to replace Handlers/Formatters
• Current config properties do allow for the inclusion of custom jars, but these are placed in MICRO-INF/lib in the case of customJars or MICRO-INF/deploy in the case of deployArtifacts. And both these directories do not make these jars available as soon as the server starts which makes their usage, for this end, impossible
• Using customJars almost allows this, but will only work if one uses --outputlauncher option on the bundle (it will copy the custom jars from /lib to /runtime an so they will be available at boot time), which is not a practical solution at all. In this Uber Jar world it is preferable to have it all packaged and then just java -jar on it
• I understand there is a config property in the start goal called classpathArtifactItems that performs something similar. However, it is not exactly the same thing because it won't package the lib into the uber jar, so one always needs to have access to maven (and then to the source repository) to fetch the dependencies at boot time (not exactly what you would want in a docker image, for example). Also if that jar we want has dependencies they must all be included even if they are already provided by the server. (Also, this property is not documented on the docs, I just found it digging through the repo)

Expected Outcome

A new configuration property to be defined on the bundle goal, like <runtimeLibs> or other name, which would allow for the definition of GAV coordinates that would include any jars declared into the MICRO-INF/runtime folder (or any other folder that can be added to classpath at boot) on the final microbundle generated.

Alteranatively, a flag property on customJar like <addToClasspath> which would add the declared jar to MICRO-INF/runtime, instead of MICRO-INF/lib, again included in the final microbundle.

Current Outcome

• customJars will include jars to MICRO-INF/lib which is not accessible at boot time, so these jars are not available for, let's say, logging initialisation.
• only possible to use these jars by separating the launcher from the application using --outputlauncher on the generated bundle.

Context

The main reason that drove to this enhancement proposal arose from this isse I have created here #5708 but also from another one #4546 with a similar problem.

I believe that this a much needed feature because logging frequently needs to be tweaked for several purposes, namely using custom formats to convey to any cloud standard (think logging to stdout instead of the default stderr, for exemple).

While I would argue that logging features would greatly benefit from being expanded on Payara as a whole, this solution would be a very good workaround because it would allow for JUL extensions to be developed and deployed on Payara with relative ease.

Also, despite this being specific for Maven plugin I would imagine that the folks that use Gradle could also benefit from it.

Thanks

Ecosystem Tool

[JamesHillyard]

Hi @CarlosMOGoncalves,

Thank you very much for creating a detailed enhancement request,

I have raised an internal issue FISH-6305 to address this enhancement. We always encourage you to contribute, so if you wish you can submit a PR to implement this improvement and we will gladly review it. Otherwise, we will pick up the issue at some point in the future.

Thanks,
James

[CarlosMOGoncalves]

Thanks a lot @JamesHillyard ,

I really look forward for news regarding this matter and I hope you will find it useful as well.

[CarlosMOGoncalves]

Hello @JamesHillyard ,
I just wanted to check whether the Payara team have considered this development?
Thanks!