[jira] Commented: (MYFACES-1158) Use of context classloader as key in _registeredFactoryNames

["Sameer Nambiar (JIRA)" <de...@myfaces.apache.org>]

    [ https://issues.apache.org/jira/browse/MYFACES-1158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12612620#action_12612620 ] 

Sameer Nambiar commented on MYFACES-1158:
-----------------------------------------

Hello,

We are facing the exact issue stated above in the description while trying to get Myfaces to work within an OSGI environment. The initialization happening through the StartupServletContextListener and the servicing of the jsp request seem to be linking through to two different context class loaders.

Myfaces version: 1.2.3
OSGi framework: Equinox 3.3.2
Servlet engine: Jetty (wrapped by PAX)

The last comment on this issue was posted a while back. I am hoping there might be a solution to this issue since. Are there any workarounds or guidelines to follow while attempting to use Myfaces within OSGi?

Regards,
/Sameer.

> Use of context classloader as key in _registeredFactoryNames
> ------------------------------------------------------------
>
>                 Key: MYFACES-1158
>                 URL: https://issues.apache.org/jira/browse/MYFACES-1158
>             Project: MyFaces Core
>          Issue Type: Bug
>          Components: General
>    Affects Versions: 1.1.1
>         Environment: Any
>            Reporter: Toh Kim Huat
>            Priority: Minor
>
> In FactoryFinder.java, the context classloader is used as the key to set/retrieve the factoryClassNames Map from the _registeredFactoryNames map. Problems will occur if the context classloader used to put a factoryClassNames into the factoryClassNames Map is different from the context classloader used to retrieve a factoryClassNames from the factoryClassNames Map. The context classloader might be different if for instance the application uses a custom classloader which is inserted into the classloader hierarchy by setting the current context classloader as its parent classloader and then setting itself to be the current thread's context classloader.
> Is it possible not to use the context classloader as the Map's key? Or perhaps if an entry cannot be retrieved from the Map using the current context classloader, can we use its parent (iteratively) to retrieve from the Map until we get an entry?

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.