[
https://issues.apache.org/jira/browse/MYFACES-2806?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Struberg resolved MYFACES-2806.
------------------------------------
Fix Version/s: 2.0.1
Resolution: Fixed
> possible bug in shared ClassLoader scenarios
> --------------------------------------------
>
> Key: MYFACES-2806
> URL: https://issues.apache.org/jira/browse/MYFACES-2806
> Project: MyFaces Core
> Issue Type: Bug
> Components: General
> Affects Versions: 2.0.0
> Reporter: Mark Struberg
> Priority: Critical
> Fix For: 2.0.1
>
>
> There is some code (mostly checked the facelets part yet) which is not aware
> of Multi-ClassLoader scenarios like one has in J2EE environments where
> MyFaces is installed inside the containers SharedClassLoader.
> An example: if you look at MetaRulesetImpl, you will see
> private final static WeakHashMap<String, MetadataTarget> _metadata = new
> WeakHashMap<String, MetadataTarget>();
> Assuming that myfaces-impl.jar gets shared between multiple WebApps, this is
> utterly evil since this map only exists once for all WebApps.
> I found this issue because I got weird ClassCastExceptions in my project
> which contains 2 WAR files in an EAR and those WAR files both contains
> primefaces.jar.
> I first hit a page from webapp1 which loads Watermark.class via webapp1
> WebAppClassLoader.
> If you access a page from webapp2 after that and this also uses p:watermark,
> it will find the cached method for Watermark, but this still is the class
> loaded via the webapp1 ClassLoader. So on evaluating the EL it creates a
> ClassCastException because WaterMark loaded via ClassLoader of webapp1 !=
> WaterMark loaded via ClassLoader of webapp2.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
