Improvement #1479
Switch context class loader for defined z2 programming models
0%
Description
It has become a nuisance that it is often necessary to switch context classloaders (e.g. via ThreadUtil) when processing callbacks from Z2 as in IDependencyComponent.
As it is safer than not to always try to set the java component's private loader as context classloader, it is suggested to do so. In almost all cases, the declared component's java component's private loader is the semantically best and most well-defined choice anyway.
Candidates:
- IDependencyComponent
- ICompiler
- IResourceProvider
Also check on the base component types:
- com.zfabrik.ee.webcontainer.jetty.fileUserRealm (com.zfabrik.servletjsp/fileRealms)
- com.zfabrik.cluster.invalidator (com.zfabrik.workers/invalidatorFactory)
- com.zfabrik.homeLayout (com.zfabrik.workers/homeLayoutFactory)
- javax.sql.DataSource (com.zfabrik.db.data/dataSources)
- org.apache.log4j.configuration (org.apache.log4j/logConfigurations)
- com.zfabrik.compiler (com.zfabrik.boot.components.basic/compilerFactory)
- com.zfabrik.ee.webcontainer.jetty (com.zfabrik.servletjsp/servers)
- com.zfabrik.naming.jndi.provider (com.zfabrik.naming/namingProviders)
- com.zfabrik.mainProgram (com.zfabrik.boot.components.basic/mainPrograms)
- com.zfabrik.swing.component (com.zfabrik.swing/swingApplications)
- com.zfabrik.gitcr (com.zfabrik.boot.gitcr/gitComponentRepositories)
- com.zfabrik.resourceProvider (com.zfabrik.boot.components.basic/resourceProviderFactory)
- com.zfabrik.fscr (com.zfabrik.boot.repos/fileSystemComponentRepositories)
- com.zfabrik.ee.webapp (com.zfabrik.servletjsp/webapps)
- com.zfabrik.coreRevisionCheck (com.zfabrik.dev.util/revisionChecks)
- com.zfabrik.systemState (com.zfabrik.boot.components.basic/statesFactory)
- com.zfabrik.worker (com.zfabrik.workers/workerFactory)
- com.zfabrik.svncr (com.zfabrik.boot.svncr/svnComponentRepositories)
- java.util.logging.configuration (java.util.logging/JULConfigurations)
- com.zfabrik.synchronizer (com.zfabrik.boot.components.basic/synchronizerFactory)
- com.zfabrik.management.jmxLogger (com.zfabrik.management/jmxLoggerFactory)
- com.zfabrik.worker.MessageHandler (com.zfabrik.workers/messageHandlerFactory)
- com.zfabrik.files (com.zfabrik.boot.components.basic/filesFactory)
- javax.security.auth.spi.LoginModule (com.zfabrik.servletjsp/loginModules)
- com.zfabrik.any (com.zfabrik.boot.components.basic/anyFactory)
- java.util.Properties (com.zfabrik.components/properties)
- com.zfabrik.hubcr (com.zfabrik.boot.hubcr/hubComponentRepositories)
- Spring beans
Updated by Henning Blohm about 10 years ago
There are two driving expectations here:
Implementer expectation¶
If an interface is made to be implemented by applications or platform extensions (i.e. what is typically called a programming model), then the callee can expect to have the right context set. This, for example, applies to ICompiler. This is in particular true for all implementations of a component type.
Invoker expectation¶
From a caller perspective, if an interface is predominantly considered a client interface, then it should not be expected that the client needs to switch context.
In between¶
Some interfaces are light-weight extensions and there is not necessarily a factory layer in between. In that case, the implementer should be aware and switch context. Typically, it should be obvious to the callee where responsibilities lie. For example, an any type component cannot expect any magic wrapper to ensure context when providing some interface.