[ 
https://issues.apache.org/jira/browse/WICKET-5492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13885194#comment-13885194
 ] 

Arjan Zwaan commented on WICKET-5492:
-------------------------------------

[~svenmeier] [~martin-g] 

We have the servlet configuration in the web.xml set to DEPLOYMENT.

                <init-param>
                        <param-name>configuration</param-name>
                        <param-value>DEPLOYMENT</param-value>
                </init-param>

The logging at our customer shows this call being the problem:

[1/28/14 10:14:56:361 CET] 0000007f SecurityManag 3   
Java SecurityException:
perm.getName<>: wicket.configuration
e.getMessage<>: Access denied (java.util.PropertyPermission 
wicket.configuration read)
Begin SecurityException
java.security.AccessControlException: Access denied 
(java.util.PropertyPermission wicket.configuration read)
      at java.security.AccessController.throwACE(AccessController.java:99)
      at 
java.security.AccessController.checkPermission(AccessController.java:173)
      at java.lang.SecurityManager.checkPermission(SecurityManager.java:558)
      at 
com.ibm.ws.security.core.SecurityManager.checkPermission(SecurityManager.java:214)
      at 
java.lang.SecurityManager.checkPropertyAccess(SecurityManager.java:1311)
      at java.lang.System.getProperty(System.java:397)
      at java.lang.System.getProperty(System.java:381)
      at 
org.apache.wicket.protocol.http.WebApplication.getConfigurationType(WebApplication.java:582)
      at org.apache.wicket.Component.getMarkupId(Component.java:1609)
      at org.apache.wicket.Component.getMarkupId(Component.java:1645)

Looking at the code in the component class, this line is calling the 
getConfigurationType:

                if 
(!Application.get().getConfigurationType().equals(Application.DEPLOYMENT))

which is in the getMarkupId method, as seen in the stacktrace.

Checking the link it seems that 1.5.x indeed only initializes it once, the 
1.4.x version however does not yet have this check.

So in 1.5.x it still ignores the exception, but only in 1.4.18 it causes the 
problems we have. I'll updated affected versions.

Unfortunately we are still stuck on WebSphere 6.1 and therefore Wicket 1.4.18 
for a little while, we are working on moving to Websphere 7 or above, but it is 
a slow process.


> WebApplication ignores a SecurityException
> ------------------------------------------
>
>                 Key: WICKET-5492
>                 URL: https://issues.apache.org/jira/browse/WICKET-5492
>             Project: Wicket
>          Issue Type: Bug
>          Components: wicket
>    Affects Versions: 1.4.18, 1.5.6
>         Environment: WebSphere 6.1 with shared classloading enabled. Linux 
> system.
>            Reporter: Arjan Zwaan
>              Labels: exception-handling, security
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> The WebApplication class has a piece of code in the method 
> getConfigurationType(), that ignores a SecurityException.
> Code snippet:
>                try
>                {
>                        result = System.getProperty("wicket." + 
> Application.CONFIGURATION);
>                }
>                catch (SecurityException e)
>                {
>                        // Ignore - we're not allowed to read system 
> properties.
>                }
> This apparently causes a performance problem at one of our customers, where 
> they had shared classloading enabled. 
> Permissions were set differently on shared classloader level, which caused 
> the retrieval of the property to fail silently, while taking about 10ms 
> longer. This code is called everytime Component.getMarkupId is called, which 
> means with 300+ components on a page, you get a delay of 3 seconds or more.
> Ofcourse the problem can be (and has been) solved with a correct 
> configuration. My request however is that the exception is atleast logged at 
> some level (warning for example), so spotting the problem will become a lot 
> easier (it took us 2 weeks to narrow it down).



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

Reply via email to