myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Toh Kim Huat (JIRA)" <>
Subject [jira] Reopened: (MYFACES-1158) Use of context classloader as key in _registeredFactoryNames
Date Wed, 01 Mar 2006 07:20:43 GMT
     [ ]
Toh Kim Huat reopened MYFACES-1158:

Hi Dennis,

Thank you for your fast reply. I downloaded the JSF specification and referred to section The only thing mentioned about the webapp classloader there is that once the class
name of the factory implementation class is found, the webapp classloader is used to load
the factory implementation class. 

It does not mention the constraint that the context classloader cannot be changed during the
lifetime of the application. If I follow the specification correctly, the factory implementation
class's name should be able to be found even if the context classloader is changed. 

But in the myFaces implementation of FactoryFinder, it seems that the logic used to find the
factory implementation class name is tied to the classloader. 

Therefore, I would appreciate if you can revisit this issue to see whether the context classloader
really cannot be changed during the lifecycle of the application. Thank you very much.


Kim Huat

> Use of context classloader as key in _registeredFactoryNames
> ------------------------------------------------------------
>          Key: MYFACES-1158
>          URL:
>      Project: MyFaces Core
>         Type: Bug
>   Components: General
>     Versions: 1.1.1
>  Environment: Any
>     Reporter: Toh Kim Huat
>     Assignee: Dennis Byrne
>     Priority: Minor
>      Fix For: 1.1.1

> In, 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.
If you think it was sent incorrectly contact one of the administrators:
For more information on JIRA, see:

View raw message