You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Oct 23, 2019. It is now read-only.
Right now we maintain as a group 2 different extension images, aws and azure, and I'm sure there are probably a few internal ones throughout the community. With the recent change to use spring-boot 1.5 we had to change the jar loading mechanism. This new mechanism doesn't require unpacking the jars anymore as they can be referenced directly by loader.path. This property is what I would expect we leverage.
This is its javadoc:
/** * Properties key for classpath entries (directories possibly containing jars or * jars). Multiple entries can be specified using a comma-separated list. {@code * BOOT-INF/classes,BOOT-INF/lib} in the application archive are always used. */publicstaticfinalStringPATH = "loader.path";
Since it can take a directory that possibly includes jars, I think it would make sense to create a well known path that extensions can just drop their jars in and have it just work.
I'll file a PR with my idea when I get a free hour
The text was updated successfully, but these errors were encountered:
So sounds like mount and JAVA_OPTS (or args.. I forget which we call it) or
a new variable? Anyway interested and thanks for thinking about this.
Note I forget which repo, but there is some change to watch out for on this
wrt boot 2.0 (maybe only build related)
On 26 Apr 2017 11:34 pm, "Brian Devins" ***@***.***> wrote:
Right now we maintain as a group 2 different extension images, aws and
azure, and I'm sure there are probably a few internal ones throughout the
community. With the recent change to use spring-boot 1.5 we had to change
the jar loading mechanism. This new mechanism doesn't require unpacking the
jars anymore as they can be referenced directly by loader.path. This
property is what I would expect we leverage.
This is its javadoc:
/** * Properties key for classpath entries (directories possibly containing jars or * jars). Multiple entries can be specified using a comma-separated list. ***@***.*** * BOOT-INF/classes,BOOT-INF/lib} in the application archive are always used. */
public static final String PATH = "loader.path";
Since it can take a directory that possibly includes jars, I think it
would make sense to create a well known path that extensions can just drop
their jars in and have it *just work*.
I'll file a PR with my idea when I get a free hour
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#140>, or mute the
thread
<https://github.com/notifications/unsubscribe-auth/AAD612riU9ybTKaMEL0W05jm_kv5TuI5ks5rz2PvgaJpZM4NJCr2>
.
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Right now we maintain as a group 2 different extension images,
aws
andazure
, and I'm sure there are probably a few internal ones throughout the community. With the recent change to use spring-boot 1.5 we had to change the jar loading mechanism. This new mechanism doesn't require unpacking the jars anymore as they can be referenced directly byloader.path
. This property is what I would expect we leverage.This is its javadoc:
Since it can take a directory that possibly includes jars, I think it would make sense to create a well known path that extensions can just drop their jars in and have it just work.
I'll file a PR with my idea when I get a free hour
The text was updated successfully, but these errors were encountered: