[
https://issues.apache.org/jira/browse/WICKET-5492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13885176#comment-13885176
]
Martin Grigorov commented on WICKET-5492:
-----------------------------------------
The configuration type is initialized just once.
See at
https://github.com/apache/wicket/blob/wicket-1.5.x/wicket-core/src/main/java/org/apache/wicket/protocol/http/WebApplication.java?source=c#L702
- if it is null then it is set to DEVELOPMENT.
This would explain some slowessness.
But I don't think WebApplication#getConfigurationType() would fail again and
again with SecurityException.
Can you please re-check that again ?
Logging a warning once at app start is OK-ish. But logging warnings again and
again when SecurityManager forbids System#getProperty() would be problematic.
> 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)
