[jira] Resolved: (WICKET-1847) Custom, user defined, configuration types plus configuration type change during runtime

["Igor Vaynberg (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/WICKET-1847?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Igor Vaynberg resolved WICKET-1847.
-----------------------------------

    Resolution: Not A Problem

this doesnt really make sense because all over the code we do the check if the app is running in dev mode or not and if it is we perform additional logging/checks. once we introduce custom profiles this will become impossible.

> Custom, user defined, configuration types plus configuration type change during runtime
> ---------------------------------------------------------------------------------------
>
>                 Key: WICKET-1847
>                 URL: https://issues.apache.org/jira/browse/WICKET-1847
>             Project: Wicket
>          Issue Type: New Feature
>          Components: wicket
>            Reporter: Bruno Borges
>            Assignee: Igor Vaynberg
>             Fix For: 1.5-M4
>
>         Attachments: patch.diff
>
>
> Currently, there's only two configuration types (DEVELOPMENT, DEPLOYMENT) and both are hardcoded. Because Application.configure() is final, there's no (easy) way to provide customized configurations and no out-of-box API to code these.
> The idea is to give org.apache.wicket.Application a new method called add(IApplicationConfiguration<? extends Application>) and from there, the user can define custom configuration types.
> Wicket's default configuration types will still be there if the user do not replace them (creating configurators with "deployment" or "development" as the name, but still is possible to override).
> There will be also the possibility to change the configuration type easily during runtime with setConfigurationType.
> The default configuration type will still be defined the current way (VM parameter, Filter parameter)
> The configuration is now made during the initializeComponents() because of procedural methods. Calling setConfigurationType(String) with the user defined *hard-coded* getDefaultConfigurationType() during internalInit() would throw an exception because the custom IApplicationConfigurator hasn't been added yet (it is added during init() ... usually).
> This patch also avoids subsequent calls to initializeComponents(), throwing an IllegalStateException. 
> * Issues with this patch
> - There are 6 references pointing to getConigurationType comparing the returned value with Application.DEVELOPMENT to do certain things.
> - The method getConfigurationType() is now final (and of course, implemented). People who wants to change the configuration type, should call setConfigurationType(String). This will recall configure() method to reconfigure the application (runtime configuration type change support)
> The patch does not break those references at all with current implementations, as the two default configuration types still live in there, but it would be better to turn those if conditions to some sort of settings.
> Also, the patch fixes WICKET-1317 for 1.4/1.5 as well.
> ** IMPORTANT NOTE **
> Because of some problem with Eclipse, the provided code formatter didn't work well, so before applying the patch, format the code and confirm the differences with trunk.

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