5:39 a.m.
[
https://issues.jboss.org/browse/WFLY-3197?page=com.atlassian.jira.plugin....
]
Bartosz Baranowski edited comment on WFLY-3197 at 4/24/14 6:38 AM:
-------------------------------------------------------------------
Ok. I finally got a moment to try it out.
Well, workaround wont work in 100% cases - I'm actually facing one.
Condition that must be met, is that there are no class versions classhes - for instance
SecurityContextFactory and JBossSecurityContext. If there are, Proxy ( created from JNDI
Ref ) must run in proper CL, in this case, factory module CL which will isolate it from
AS7 env - keep all the factory module classes scoped and isolated.
Possibly application could create fake module (jboss-deployment-structure->module )
which would contain required classes from deployment and have dependency on factory module
to bring all those classes required for lookup. Just before call/lookup application would
have to switch TCCL to this fake module. However this is wrong:
- it moves CL magic into application - this is bad and this is the original reason
I've started to dig ExternalContextFactory.module
- ( I think ) it will make impossible to translate between classes that have two
different versions( one in AS7 space second in factory module ) - for instance security
packages suffer from this - iirc static methods -
org.jboss.security.SecurityContextFactory.createSecurityContext and
SecurityContextAssociation.*
was (Author: baranowb):
Ok. I finally got a moment to try it out.
Well, workaround wont work in 100% cases - I'm actually facing one.
Condition that must be met, is that there are no class versions classhes - for instance
SecurityContextFactory and JBossSecurityContext. If there are, Proxy ( created from JNDI
Ref ) must run in proper CL, in this case, factory module CL which will isolate it from
AS7 env - keep all the factory module classes scoped and isolated.
Possibly application could create fake module (jboss-deployment-structure->module )
which would contain required classes from deployment and have dependency on factory module
to bring all those classes required for lookup. Just before call/lookup application would
have to switch TCCL to this fake module. However this is wrong:
- it moves CL magic into application - this is the original reason I've started to
dig ExternalContextFactory.module
- ( I think ) it will make impossible to translate between classes that have two
different versions( one in AS7 space second in factory module ) - for instance security
packages suffer from this - iirc static methods -
org.jboss.security.SecurityContextFactory.createSecurityContext and
SecurityContextAssociation.*
ExternalContextFactory cuts context from deployment context/requires
dependency on module
-----------------------------------------------------------------------------------------
Key: WFLY-3197
URL: https://issues.jboss.org/browse/WFLY-3197
Project: WildFly
Issue Type: Enhancement
Security Level: Public(Everyone can see)
Components: Naming
Affects Versions: 8.0.0.Final, 8.1.0.CR1
Reporter: Bartosz Baranowski
Assignee: Bartosz Baranowski
Fix For: 8.1.0.Final
WFLY-2777 changed CCL for context creation(if module is set in external context factory).
This essentially cuts context from deployment classes during creation time. This can cause
problems when external-context-factory.module classes (ObjectFactories, etc) require
deployment classes to be visible from classloader which created context(
external-context.module ) and are not found.
Steps to reproduce:
1. define isolated module IM ( with classloader IM_CL )
2. create external-context-factory with module set to IM
3. create some deployment with interface, for which proxies should be looked up via
external-context ( with classloader D_CL ) - deployment has no dependency on IM, since it
may contain legacy classes or unwanted dependencies
4. lookup and invoke proxy
Now what will happen is during deployment external-context will be spawned just fine.
However, the runtime outcome wont be pleasing.
Case 1: application and custom context dont do CCL magic
- invocation happen in deployment CCL, hence IM_CL classes are not visible and no
classes required for deserialization can be loaded, this will fail ( return
javax.naming.Reference instance, since ObjectFactory from IM_CL cant be found )
Case 2: application or custom context switch CCL to IM_CL for lookup
- CCL is set to IM_CL, ObjectFactory can be found, but D_CL classes cant, hence some
naming error probably
Neither of above will work, unless IM_CL and D_CL have some sort of dependency on each
other, which just makes module CL configured in external-context-factory irrelevant, since
D_CL will require dependency on IM_CL.
Workaround:
yes, store IM_CL in context wrapper and upon first invocation obtain CCL( hopefuly
D_CL), create agregating CL and set it as CCL for each context invocation.
Possible fix:
1. pass D_CL and IM_CL as part of env to factory, to allow context/context-wrapper to do
some magic
2. alter ExternalContextFactory and create agregating/delegating CL, which will just
iterate over IM_CL and D_CL if present to load proper classes
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira