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

[Bartosz Baranowski (JIRA)]

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

Bartosz Baranowski commented on WFLY-3197:
------------------------------------------

Ok, so main purpose of having module CL in external context object factory is to allow AS7/8 to load some 3rd part context stuff. Thats nice and all. However devil lies in details. Current code will work under certain conditions:
1. application declares dependency on context factory module
2. there are no conflicts between context factory module and EAPx/ASx modules.

Now lets see where code flow will take us:
https://github.com/wildfly/wildfly/blob/master/naming/src/main/java/org/jboss/as/naming/ExternalContextObjectFactory.java#L83
and
https://github.com/wildfly/wildfly/blob/master/naming/src/main/java/org/jboss/as/naming/ExternalContextObjectFactory.java#L87
https://github.com/wildfly/wildfly/blob/master/naming/src/main/java/org/jboss/as/naming/ExternalContextObjectFactory.java#L88

will set CCL to context factory module and use that CL to load context class. This will work for startup and no error should show( if said module has all required classes)

First glitch: Application does remote lookup, context receives Reference. Now, if application does not embed context calls in context factory module or depend on it, Context.lookup and most likely other ops will fail.
Reason: http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/6-b14/javax/naming/spi/NamingManager.java#299 which dives into EAP/ASx code --> https://github.com/wildfly/wildfly/blob/master/naming/src/main/java/org/jboss/as/naming/context/ObjectFactoryBuilder.java#L170
ObjectFactoryBuilder requires CCL to have definition of factory class. If deployment( which is default CCL ) does not have it, lookup will fail, because L170 in ObjectFactoryBuilder cant load it. Lookup will return Reference as result to calling app.


Second glitch: Same situation as before, but application embeds context calls in context factory module CL. This will fail in similar way, however due to a bit different reason( still CNFE )
Reason: http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/6-b14/javax/naming/spi/NamingManager.java#321 this piece of code requires classes( interfaces ) which are in deployment to create Proxy object from factory.
                
> 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