With the introduction of Resource Group Templates (RGTs), applications may be directly deployed to RGTs. When a partition’s Resource Group (RG) refers to such an RGT, the application is deployed to such a partition independently.
All application instances have their own class loader structures. An application programmer can provide directive to share loading of classes. This directive is only supported for EAR applications. The approach is to declare some jars in an EAR’s weblogic-application.xml as a directive. If other conditions are conducive, the classes in these jars would be loaded by a shared app class loader that is shared by application instances of such an application.
Say we have an application called school.ear that has two modules, administration.war and academics.war. Further, say there are some jar files in the ear, logging.jar and reports.jarschool.ear|— META-INF||— weblogic-application.xml|— APP-INF||— lib|||— logging.jar|||— reports.jar|— administration.war|— academics.war
If the application developer thinks that all the jars in APP-INF/lib can be shared across application instances, she may specify such a directive in weblogic-application.xml<class-loading> <shareable dir=“APP-INF-LIB”/></class-loading>
This is a directive for the server to consider all the jars in APP-INF/lib as shareable. The class of this jar will be loaded in a shared class loader if other requirements are met.There are three possible values support for the “dir” attribute:“APP-INF-LIB" to identify WebLogic style APP-INF/lib "LIB-DIR" to identify JavaEE style library-directory (default or configured via application.xml) "APP-INF-CLASSES" to identify WebLogic style APP-INF/classes
If the user wants to add specific jars from the lib directory (only for options APP-INF-LIB and LIB-DIR), she can add addition include or exclude elements.Here is how we can add only reports.jar from the APP-INF/lib<class-loading> <shareable dir=“APP-INF-LIB”> <include>reports.jar</include> </shareable></class-loading>
If we want to add all jar from a lib dir but exclude some, we could use the exclude element. Here is how we could provide a shareable directive for all jars but logging.jar<class-loading> <shareable dir=“APP-INF-LIB”> <exclude>logging.jar</exclude> </shareable></class-loading>
Such directive is only valid for packaging unit it is added to. For example, such directive would be needed separately for EAR applications and EAR libraries. Any configuration from EAR application will not apply to EAR libraries that the application refers to.
Shared class loader does not have any visibility into instance class loaders. Therefore we should have any jars that are identified shareable depend on jars that are not marked shareable. This will lead to NoClassDefFoundError or ClassNotFoundException
This directive is a memory optimization and the application developer must not functionally depend on it. In some cases, the sharing may not be enabled. So, the developer must not depend on sharing, but provide it as a directive. This directive helps optimize memory usage in production.
As a reminder, these directives work for EAR deployments in RGTs only. This is only supported for production mode. Filtering configuration must not be different or modified differently using deployment plan override for each application instance.