[jboss-jira] [JBoss JIRA] (WFLY-3197) ExternalContextFactory cuts context from deployment context/requires dependency on module

[David Lloyd (JIRA)]

    [ https://issues.jboss.org/browse/WFLY-3197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12962111#comment-12962111 ] 

David Lloyd commented on WFLY-3197:
-----------------------------------

The real problem is that there isn't a right answer to the question "what class loader does this Reference refer to?".  This is basically a limitation of JNDI - References were never designed to handle isolated class loaders (they are quite old).  You can specify a factory class location URL in the Reference, but this will actually cause a new URLClassLoader to be created to load those classes on every lookup, which is even worse.

We created {{ModularReference}} to solve this problem, however, if something else is doing the binding, it doesn't help much unless you define some kind of hook to swap it out.

The only practical fix is to make sure TCCL can load the needed class.  You can use the fact that dependencies are non-transitive by default, combined with the ability to provide filters, to mitigate this problem.
                
> 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