Override Class loader “Parent First”
I have Java web application running on a web application server single node setup, in which I am using a liberary the I included in my Web-Inf and using in my code.
The issue is that I have another application that added its liberaries to the WebSphere parent lib folder, one of which are the same liberary I am using but with an older version, creating conflict and jamming my code.
The server class loader is configured Parent first unfourtunatly and I cannot change that fact. My question is, how can I make my app use my liberary, ignoring the one used by the class loader?
java java-ee websphere classloader
asked Nov 19 '18 at 16:51
WiredCoderWiredCoder
496328
add a comment |
I have Java web application running on a web application server single node setup, in which I am using a liberary the I included in my Web-Inf and using in my code.
The issue is that I have another application that added its liberaries to the WebSphere parent lib folder, one of which are the same liberary I am using but with an older version, creating conflict and jamming my code.
The server class loader is configured Parent first unfourtunatly and I cannot change that fact. My question is, how can I make my app use my liberary, ignoring the one used by the class loader?
java java-ee websphere classloader
asked Nov 19 '18 at 16:51
WiredCoderWiredCoder
496328
You can't. If you cannot re-configure classloader to "parent last", then you need a different instance, so 1) there is no conflicting classes in parent loader, or 2) you can configure "parent last" to resolve the conflict.
– Andreas
Nov 19 '18 at 16:57
add a comment |
I have Java web application running on a web application server single node setup, in which I am using a liberary the I included in my Web-Inf and using in my code.
The issue is that I have another application that added its liberaries to the WebSphere parent lib folder, one of which are the same liberary I am using but with an older version, creating conflict and jamming my code.
The server class loader is configured Parent first unfourtunatly and I cannot change that fact. My question is, how can I make my app use my liberary, ignoring the one used by the class loader?
java java-ee websphere classloader
asked Nov 19 '18 at 16:51
WiredCoderWiredCoder
496328
I have Java web application running on a web application server single node setup, in which I am using a liberary the I included in my Web-Inf and using in my code.
The issue is that I have another application that added its liberaries to the WebSphere parent lib folder, one of which are the same liberary I am using but with an older version, creating conflict and jamming my code.
The server class loader is configured Parent first unfourtunatly and I cannot change that fact. My question is, how can I make my app use my liberary, ignoring the one used by the class loader?
java java-ee websphere classloader
java java-ee websphere classloader
asked Nov 19 '18 at 16:51
WiredCoderWiredCoder
496328
asked Nov 19 '18 at 16:51
WiredCoderWiredCoder
496328
asked Nov 19 '18 at 16:51
WiredCoderWiredCoder
496328
asked Nov 19 '18 at 16:51
WiredCoderWiredCoder
496328
asked Nov 19 '18 at 16:51
WiredCoderWiredCoder
496328
496328
You can't. If you cannot re-configure classloader to "parent last", then you need a different instance, so 1) there is no conflicting classes in parent loader, or 2) you can configure "parent last" to resolve the conflict.
– Andreas
Nov 19 '18 at 16:57
add a comment |
You can't. If you cannot re-configure classloader to "parent last", then you need a different instance, so 1) there is no conflicting classes in parent loader, or 2) you can configure "parent last" to resolve the conflict.
– Andreas
Nov 19 '18 at 16:57
You can't. If you cannot re-configure classloader to "parent last", then you need a different instance, so 1) there is no conflicting classes in parent loader, or 2) you can configure "parent last" to resolve the conflict.
– Andreas
Nov 19 '18 at 16:57
You can't. If you cannot re-configure classloader to "parent last", then you need a different instance, so 1) there is no conflicting classes in parent loader, or 2) you can configure "parent last" to resolve the conflict.
– Andreas
Nov 19 '18 at 16:57
add a comment |
2 Answers
2
active
oldest
votes
The solution is to move the conflicting package to a shared library, configure the library to use an isolated class loader, and associate that library with your application or module. The "isolated class loader" setting creates a separate parent-last class loader for the shared library, so you get that behavior targeted to only the artifacts that need it rather than having to apply it to the entire application or module.
https://www.ibm.com/support/knowledgecenter/en/SSAW57_8.5.5/com.ibm.websphere.nd.multiplatform.doc/ae/tcws_sharedlib.html
I'm specifically referencing the "Use an isolated class loader for this shared library" setting.
answered Nov 19 '18 at 17:49
JaridJarid
1,04327
add a comment |
If you can't change your application server setup there are basically three things you can do:
Downgrade your application dependency to lower version used by WebSphere server and keep it in sync. This is preferable as it's least hassle.
Shade the dependency during build to your own package to prevent package clash. This can be done with Maven Shade Plugin, see Relocating Classes usage example.
Write a new custom classloader to work around the problem.
I'd try them in 1 -> 2 -> 3 order. Option 3 is possible but is an error-prone nightmare. I'd rather deploy to another server than do it.
answered Nov 19 '18 at 16:56
Karol DowbeckiKarol Dowbecki
20.4k92852
4. Start another WebSphere instance.
– Andreas
Nov 19 '18 at 16:59
"I'd rather deploy to another server than do it." - As would I. The OP's problem is one of the reasons why some people say "application servers are dead". It's often easier to just treat the server as a dependency of an application than going through all the hassle that comes with incompatibilities like that.
– Thomas
Nov 19 '18 at 17:01
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53379273%2foverride-class-loader-parent-first%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
The solution is to move the conflicting package to a shared library, configure the library to use an isolated class loader, and associate that library with your application or module. The "isolated class loader" setting creates a separate parent-last class loader for the shared library, so you get that behavior targeted to only the artifacts that need it rather than having to apply it to the entire application or module.
https://www.ibm.com/support/knowledgecenter/en/SSAW57_8.5.5/com.ibm.websphere.nd.multiplatform.doc/ae/tcws_sharedlib.html
I'm specifically referencing the "Use an isolated class loader for this shared library" setting.
answered Nov 19 '18 at 17:49
JaridJarid
1,04327
add a comment |
The solution is to move the conflicting package to a shared library, configure the library to use an isolated class loader, and associate that library with your application or module. The "isolated class loader" setting creates a separate parent-last class loader for the shared library, so you get that behavior targeted to only the artifacts that need it rather than having to apply it to the entire application or module.
https://www.ibm.com/support/knowledgecenter/en/SSAW57_8.5.5/com.ibm.websphere.nd.multiplatform.doc/ae/tcws_sharedlib.html
I'm specifically referencing the "Use an isolated class loader for this shared library" setting.
answered Nov 19 '18 at 17:49
JaridJarid
1,04327
add a comment |
The solution is to move the conflicting package to a shared library, configure the library to use an isolated class loader, and associate that library with your application or module. The "isolated class loader" setting creates a separate parent-last class loader for the shared library, so you get that behavior targeted to only the artifacts that need it rather than having to apply it to the entire application or module.
https://www.ibm.com/support/knowledgecenter/en/SSAW57_8.5.5/com.ibm.websphere.nd.multiplatform.doc/ae/tcws_sharedlib.html
I'm specifically referencing the "Use an isolated class loader for this shared library" setting.
answered Nov 19 '18 at 17:49
JaridJarid
1,04327
The solution is to move the conflicting package to a shared library, configure the library to use an isolated class loader, and associate that library with your application or module. The "isolated class loader" setting creates a separate parent-last class loader for the shared library, so you get that behavior targeted to only the artifacts that need it rather than having to apply it to the entire application or module.
https://www.ibm.com/support/knowledgecenter/en/SSAW57_8.5.5/com.ibm.websphere.nd.multiplatform.doc/ae/tcws_sharedlib.html
I'm specifically referencing the "Use an isolated class loader for this shared library" setting.
answered Nov 19 '18 at 17:49
JaridJarid
1,04327
answered Nov 19 '18 at 17:49
JaridJarid
1,04327
answered Nov 19 '18 at 17:49
JaridJarid
1,04327
answered Nov 19 '18 at 17:49
JaridJarid
1,04327
1,04327
add a comment |
add a comment |
If you can't change your application server setup there are basically three things you can do:
Downgrade your application dependency to lower version used by WebSphere server and keep it in sync. This is preferable as it's least hassle.
Shade the dependency during build to your own package to prevent package clash. This can be done with Maven Shade Plugin, see Relocating Classes usage example.
Write a new custom classloader to work around the problem.
I'd try them in 1 -> 2 -> 3 order. Option 3 is possible but is an error-prone nightmare. I'd rather deploy to another server than do it.
answered Nov 19 '18 at 16:56
Karol DowbeckiKarol Dowbecki
20.4k92852
4. Start another WebSphere instance.
– Andreas
Nov 19 '18 at 16:59
"I'd rather deploy to another server than do it." - As would I. The OP's problem is one of the reasons why some people say "application servers are dead". It's often easier to just treat the server as a dependency of an application than going through all the hassle that comes with incompatibilities like that.
– Thomas
Nov 19 '18 at 17:01
add a comment |
If you can't change your application server setup there are basically three things you can do:
Downgrade your application dependency to lower version used by WebSphere server and keep it in sync. This is preferable as it's least hassle.
Shade the dependency during build to your own package to prevent package clash. This can be done with Maven Shade Plugin, see Relocating Classes usage example.
Write a new custom classloader to work around the problem.
I'd try them in 1 -> 2 -> 3 order. Option 3 is possible but is an error-prone nightmare. I'd rather deploy to another server than do it.
answered Nov 19 '18 at 16:56
Karol DowbeckiKarol Dowbecki
20.4k92852
4. Start another WebSphere instance.
– Andreas
Nov 19 '18 at 16:59
"I'd rather deploy to another server than do it." - As would I. The OP's problem is one of the reasons why some people say "application servers are dead". It's often easier to just treat the server as a dependency of an application than going through all the hassle that comes with incompatibilities like that.
– Thomas
Nov 19 '18 at 17:01
add a comment |
If you can't change your application server setup there are basically three things you can do:
Downgrade your application dependency to lower version used by WebSphere server and keep it in sync. This is preferable as it's least hassle.
Shade the dependency during build to your own package to prevent package clash. This can be done with Maven Shade Plugin, see Relocating Classes usage example.
Write a new custom classloader to work around the problem.
I'd try them in 1 -> 2 -> 3 order. Option 3 is possible but is an error-prone nightmare. I'd rather deploy to another server than do it.
answered Nov 19 '18 at 16:56
Karol DowbeckiKarol Dowbecki
20.4k92852
If you can't change your application server setup there are basically three things you can do:
Downgrade your application dependency to lower version used by WebSphere server and keep it in sync. This is preferable as it's least hassle.
Shade the dependency during build to your own package to prevent package clash. This can be done with Maven Shade Plugin, see Relocating Classes usage example.
Write a new custom classloader to work around the problem.
I'd try them in 1 -> 2 -> 3 order. Option 3 is possible but is an error-prone nightmare. I'd rather deploy to another server than do it.
answered Nov 19 '18 at 16:56
Karol DowbeckiKarol Dowbecki
20.4k92852
answered Nov 19 '18 at 16:56
Karol DowbeckiKarol Dowbecki
20.4k92852
answered Nov 19 '18 at 16:56
Karol DowbeckiKarol Dowbecki
20.4k92852
answered Nov 19 '18 at 16:56
Karol DowbeckiKarol Dowbecki
20.4k92852
20.4k92852
4. Start another WebSphere instance.
– Andreas
Nov 19 '18 at 16:59
"I'd rather deploy to another server than do it." - As would I. The OP's problem is one of the reasons why some people say "application servers are dead". It's often easier to just treat the server as a dependency of an application than going through all the hassle that comes with incompatibilities like that.
– Thomas
Nov 19 '18 at 17:01
add a comment |
4. Start another WebSphere instance.
– Andreas
Nov 19 '18 at 16:59
"I'd rather deploy to another server than do it." - As would I. The OP's problem is one of the reasons why some people say "application servers are dead". It's often easier to just treat the server as a dependency of an application than going through all the hassle that comes with incompatibilities like that.
– Thomas
Nov 19 '18 at 17:01
4. Start another WebSphere instance.
– Andreas
Nov 19 '18 at 16:59
4. Start another WebSphere instance.
– Andreas
Nov 19 '18 at 16:59
"I'd rather deploy to another server than do it." - As would I. The OP's problem is one of the reasons why some people say "application servers are dead". It's often easier to just treat the server as a dependency of an application than going through all the hassle that comes with incompatibilities like that.
– Thomas
Nov 19 '18 at 17:01
"I'd rather deploy to another server than do it." - As would I. The OP's problem is one of the reasons why some people say "application servers are dead". It's often easier to just treat the server as a dependency of an application than going through all the hassle that comes with incompatibilities like that.
– Thomas
Nov 19 '18 at 17:01
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53379273%2foverride-class-loader-parent-first%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
You can't. If you cannot re-configure classloader to "parent last", then you need a different instance, so 1) there is no conflicting classes in parent loader, or 2) you can configure "parent last" to resolve the conflict.
– Andreas
Nov 19 '18 at 16:57