Ok, this is implemented in trunk and the doc was updated. I removed
"disableJarScanning" and "excludeJars" and added "includeJars". Only
jars whose URL matches one of the regexes in
"struts.convention.action.includeJars" will be scanned.

https://issues.apache.org/struts/browse/WW-2947

If everything is ok, I will rebuild on Monday 2.1.6 and call for a
vote. Do we need to keep the 2.1.3, 2.1.4 and 2.1.5 dirs in
p.a.o/builds/struts? Those are just taking space there.

regards
musachy

On Sat, Jan 3, 2009 at 12:17 PM, Musachy Barroso <[email protected]> wrote:
> Thanks for the feedback Jeromy! Things to point out:
>
> 1. If we add a setting like "includeJars", and get rid of
> "excludeJars" (very simple change, code wise), then we can enable jar
> scanning by default. I totally agree with this.
> 2. I am not sure about the camel case problem. I guess we could add
> another flag to search for camel-cased results, instead of the
> default. I am on the fence for this one, as actions names are built
> with "-" by default, and the idea behind the convention is that the
> result file has the same name as the action, but we can talk about it.
> 3. "Result [x] for action class [x] is missing the location". I left
> this around because I wasn't sure if we really needed it, it is gone
> now.
>
> I added a page with the changes that you mentioned
> here:http://cwiki.apache.org/confluence/display/WW/Converting+application+from+Codebehind+to+Convention+Plugin
> and linked to it from the convention and codebehind plugin pages. I
> will implement #1 and let you know so you can take it for an spin.
>
> musachy
>
> On Sat, Jan 3, 2009 at 12:35 AM, Jeromy Evans
> <[email protected]> wrote:
>>
>> I finally made time to convert some 2.1.3-SNAPSHOT applications to the
>> current trunk (2.1.6-SNAPSHOT).
>> All use a combination of the REST, Convention (replacing CodeBehind) and
>> Tiles plugins.
>>
>> Result: SUCCESS (eventually).  Nice work!
>>
>> I've redeployed a sample application at
>> http://www.blueskyminds.com.au/url-hierarchy/ that uses the rest plugin,
>> sitemesh, convention and a custom action mapper.  The source is there.  It
>> worked without too much trouble (changes below).
>>
>> I also migrated a non-trivial application (65 controllers) that makes proper
>> use of the REST plugin (a distributed app using the xml handlers for
>> server<->server comms).  It also uses results and actions scanned from jars,
>> custom results and interceptors, custom s2 tags, tiles, sitemesh and guice
>> so it serves as quite a comprehensive check. Unfortunately it's already full
>> of work-arounds for non-blocking issues so it may not reveal all potential
>> problems but anyway, it still works after the upgrade :-).
>>
>> The most complicated or time-consuming issues were:
>>  - discovering I required convention's "mapAllMatches" option set to setup
>> some controllers,
>>  - enabling convention's jar scanning and overriding the undocumented
>> excludeJars parameter,
>>  - updating uses of the Result annotation (not just search and replace), and
>>  - modifying some camel-case actions and results to meet Conventions
>> expectations:
>> ie. was get /anExample -> AnExampleController.index() ->
>> anExample-index.ftl,
>>     now get /an-example -> AnExampleController.index() ->
>> an-example-index.ftl
>> (I couldn't find a way to emulate CodeBehind's handling of camel-case action
>> to unknown result bindings)
>>
>> The struts.convention.action.excludeJars setting is a bit of a problem.  It
>> specifies which jars NOT to search and the default is a long list of regular
>> expressions defined inside struts.properties within the convention plugin.
>>  I found it could only be overridden using another struts.properties file
>> (not struts.xml).  Not setting it up correctly causes ClassNotFound
>> exceptions during initialisation for every class whose definition can't be
>> read by xwork's ClassFinder.  I'd prefer replacing it with an "includeJars"
>> pattern as some configuration is already required to enable jar scanning
>> (off by default).  It's quite painful as it throws exceptions for some jars
>> that are included only by the IDE.
>>
>> I also get a lot of unnecessary warnings "Result [x] for action class [x] is
>> missing the location" because not all results require a location parameter.
>>
>> When a vote is next called I'll switch to the appropriate tag and repeat.
>>
>> Summary of required changes:
>>
>> replace o.a.s2.config.Namespace with o.a.s2.convention.annotation.Namespace
>> replace o.a.s2.config.Results with o.a.s2.convention.annotation.Results
>> replace o.a.s2.config.Result with o.a.s2.convention.annotation.Result
>>
>> Update @Result uses to use result name instead of Class<Result>
>> Update @Result uses to use location instead of value attribute
>>
>> Update the constants in struts.xml to use setup convention+rest instead of
>> codebehind+rest.
>>
>> Check web.xml (filters and params)
>>
>> Update CamelCase action results and references to match Convention
>>
>> Hope that's useful to someone.
>>
>> regards,
>>  Jeromy Evans
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [email protected]
>> For additional commands, e-mail: [email protected]
>>
>>
>
>
>
> --
> "Hey you! Would you help me to carry the stone?" Pink Floyd
>



-- 
"Hey you! Would you help me to carry the stone?" Pink Floyd

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to