Does parent_last affect other applications ?
Is my application using parent_last affected by other applications?
The server is set to "Multiple Classloaders" (one for each application IIUC).
In my understanding, this would mean that all classes are loaded from the application, correct?
What happens if another application loads a class present in websphere extensions, and lateron my application uses that class. Will it be reloaded, or will the one from parent be used? (it might be incompatible to the classes in my application).
The websphere manual says:
"By specifying Classes loaded with local class loader first (parent last), your application can override classes contained in the parent class loader, but this action can potentially result in ClassCastException or LinkageErrors if you have mixed use of overridden classes and non-overridden classes."
But I do not understand this potential risk. Can somone please provide examples for this?
Classes loaded by application class loader cannot interfere in any way with those loaded by other applications since application classloaders are isolated from each other.
The quote that you provided warns about potential problems that might occur when libraries have transitive dependencies. For example, your application uses libraryA that depends on libraryB. LibraryA is some sort of "standard" library provided by application server, so you don't package it with the application. Then, if for some reason you need to have libraryB in the application and the version of it is different from the one expected by libraryA, you might have problems with incompatibility.
Related
I have an ear file with a web module and a ejb module(just used for message driven beans). The ejb module has dependency on web module and it's classes. I would need to load the web module first and then ejb module. But the liberty always loading the ejb module first causing com.ibm.ws.container.service.state.StateChangeException: java.lang.NoClassDefFoundError:
How to control the order of modules loading within the same ear file? On traditional webshpere there is an option called 'Starting weight'. Whichever module has lowest value takes precedence and loads it first. so the application works good on tradition Websphere. However, this property seems missing on Liberty. I already looked at this. It only talks about deploying the multiple war files and their order.
If your EJB module depends on Web, that is bad design. It should be the other way around.
If you have such situation , proper way would be to extract shared classes in to a common jar file, let say mycommon.jar and then put that into ear\lib folder. In this way they will be visible by both modules ejb and web.
If your EJB module depends on the javax web api (e.g. servletRequest) that is even worse, and you should redesign such classes to POJO DTOs.
As a last resort you could try what is described here and add <initialize-in-order>true</initialize-in-order> in your application.xml.
FRowe's solution will not work, as classes are not shared between the applications, so changing load order of apps will not help. Each Java™ EE application has its own class loader in a running Liberty server.
Consider using the ability to control app start order as described here: https://www.openliberty.io/blog/2020/06/05/graphql-open-liberty-20006.html?_ga=2.4728563.17466047.1620833568-1423690488.1614284842&cm_mc_uid=99965752544816136653536&cm_mc_sid_50200000=61078141620909829332#ORDER
You'll have to deploy the war module as an app instead of packaging it within the ear, but you should be able to achieve the proper ordering.
I have a java application which is implemented to find providers of an interface using java.util.serviceLoader. When I a add a new provider jar at runtime to the classpath of the application the application is not finding it. If I restart the application the application finds the provider jar. Are there any options for java application to find the provider jar at runtime as I think that is what java serviceLoader is supposed to do.
I am following the instructions in this page.
http://cr.openjdk.java.net/~mr/jigsaw/spec/api/java/util/ServiceLoader.html
Deploying service providers on the class path
Explanation can be found here Creating Extensible Applications (at the end of the tutorial):
Limitations of the ServiceLoader API
The ServiceLoader API is useful, but it has limitations. For example, it is impossible to derive a class from the ServiceLoader class, so you cannot modify its behavior. You can use custom ClassLoader subclasses to change how classes are found, but ServiceLoader itself cannot be extended. Also, the current ServiceLoader class cannot tell your application when new providers are available at runtime. Additionally, you cannot add change-listeners to the loader to find out whether a new provider was placed into an application-specific extension directory.
Seems to apply to Java 8. Don't know if this has changed in the later editions.
I have a spring-boot app that acts as a small framework for other apps. It provides a couple of JMS queues and a DAO layer to retrieve and store data from a common set of data stores. The problem is that the original developer of this framework app is scanning all the package "com.mycompany" (rather than com.mycompany.framework) so that it can load the beans of the specific app that may be declared under com.mycompany.myapp1 or com.mycompany.myapp2 an which JARs are bundled together with the JARs of the framework.
We only load a single app in the JVM (app1 or app2), but these apps may share other libraries and sometimes we end up with beans in the context that we don't need. (these may be needed in app1 but not in app2)
So, what would be your advice ?
My problem is similar to what was described here:
https://github.com/spring-projects/spring-boot/issues/3300
I am debating if each app should be aware of the framework and load it. Or if the framework should instantiate a class loader and create a new Spring context loading the app specific code as suggested in the link above.
Perhaps you should consider leveraging some of Spring Boot's Auto Configuration capabilities such as #ConditionalOnProperty or #ConditionalOnClass in your framework. That way, you can only actually enable certain beans if and when the application using your framework takes some specific action (e.g. has a given jar on the classpath, or sets a configuration value). For reference check out: http://docs.spring.io/spring-boot/docs/current/reference/htmlsingle/#boot-features-developing-auto-configuration
I am just wondering, if the below is possible with Websphere or not?
I have an Enterprise application using Websphere 7 and with PARENT_LAST classloading mode. I am now trying to use a third party feature namely, gemfire in the application. My application with gemfire runs perfectly in PARENT_FIRST classloading mode. But, I can see some linkage errors occuring because of PARENT_LAST setting. Temperarly, I could solve them by removing the classes that are conflicting from gemfire jar(By this, I am actually asking those removed classes to be loaded from web app server). But, I am not sure if this will create some bigger issues as my appliaction grow to its fullest.
My question is : Suppose we have abc.jar in both web app server and also in gemfire.jar, with PARENT_LAST loading mode.Is it possible to solve the above class conflicts by not removing any class files from jars, instead tell the classloading mechanism to use the class loaded from web app server at a particular case and use the same class loaded from gemfire jar(meaning load from application) at another case?
Thanks
Yes, it is possible. We are using a similar setup. You should be very careful though and only use the exact same jars (or at least the same classes) in all the places you need to have them.
I am using JCS to store the ldap search results which should be shared by multiple EJB. I have created a singleton class to initialize JCS only once but due to EJB's classloader, it's been initialized multiple times with its own copy. so search resources are not shared.
How are you guys resolving issue where you need to share the cache across multiple beans?
I am looking for cache within JVM. (Not the remote e.g memcached etc.).
Glassfish is used as an application server.
I haven't been able to test it yet, but I think that one of the techniques explained in the "Circumventing Class Loader Isolation" chapter of the Application Development Guide for the version of Glassfish you are using may solve you problem.
Short version, at least valid for versions 2-3-4 : use the Common Classloader (what exactly this common classloader does and its relation to the other classloaders is explained in the same manual). There are several ways to do this:
copy the jar to domain-dir/lib
or copy the jar to as-install/lib
or run asadmin add-library --type common /path/to/your.jar (will only work in version 4 iirc)
There are several questions here on SO that are related to "Circumventing Class Loader Isolation" (just use that search term), look there for examples and more discussion.
Simply put, the singleton will likely "live" where your caching implementation class lives, as that's the classloader in the hierarchy that "owns" the class.
So, if each EJB is separately deployed, with their own copy of the cache lib jar, they'll each get their own copy.
If your beans are deployed in a composite EAR, sharing a single instance of the lib jar, then that cache will be shared across the beans in the EAR.
If you remove the lib from the deployment completely, and put it outside the container ($DOMAIN/lib/ext for example), then that cache will be shared by EVERYTHING in the domain (EJBs, EARs, WARs, etc.).