[
https://issues.apache.org/jira/browse/CLK-661?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12884490#action_12884490
]
Bob Schellink commented on CLK-661:
-----------------------------------
Why do you say it becomes a mess?
WRT to deployFiles, I think AbstractConfigService only needs to deploy files
from the classpath (Servlet 3.0 spec):
deployResourcesOnClasspath();
I don't find the other options very practical or useful.
PS: I've noticed Tomcat 7 is near completion so at some stage we should start
checking which container Click is running on. If on a Servlet3.0 we don't have
to deploy anything, as that is taken care of by the container itself.
> Add Java based configuration
> ----------------------------
>
> Key: CLK-661
> URL: https://issues.apache.org/jira/browse/CLK-661
> Project: Click
> Issue Type: Improvement
> Reporter: Bob Schellink
> Assignee: Finn Bock
> Fix For: 2.3.0-M1
>
> Attachments: abstract-config-service.patch, defaultconfigservice.patch
>
>
> click.xml has grown over the years especially since we introduced the service
> based architecture. Some of the problems with xml based configurations is:
> - no compile time checking
> - no JavaDoc help in IDE
> I propose we add a new DefaultConfigService class that is Java based which
> XmlConfigService extends from.
> Its advantages is the polar opposite of xml disadvantage:
> - compile time checking
> - JavaDoc help in IDE
> - More powerful configuration options, e.g. its possible to configure
> FileUpload in ways not exposed by xml config. Also possible to create more
> powerful algorithms e.g. which templates to include/exclude.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
