Uploaded image for project: 'WildFly'
  1. WildFly
  2. WFLY-3197

ExternalContextFactory cuts context from deployment context/requires dependency on module

    XMLWordPrintable

Details

    • Enhancement
    • Status: Closed (View Workflow)
    • Major
    • Resolution: Rejected
    • 8.0.0.Final, 8.1.0.CR1
    • No Release
    • Naming
    • None

    Description

      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

      Attachments

        Activity

          People

            rhn-cservice-bbaranow Bartosz Baranowski
            rhn-cservice-bbaranow Bartosz Baranowski
            Votes:
            0 Vote for this issue
            Watchers:
            7 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: