Yes, the problem with a wildcard search is that different containers
or JVMs might sort the list differently. The current model already
loads multiple property files from multiple location according to a
predefined search pattern, and I expect it would handle the same way
we handle them now, which I suppose is last-one wins.  But, with a
wildcard it might be hard to predefine which file would be loaded
last.

-Ted.

On Nov 5, 2007 3:08 PM, Brian Pontarelli <[EMAIL PROTECTED]> wrote:
>
> How will this handle key collisions in large projects? Or collisions
> with resources on the classpath that aren't easily modified?
>
> -bp
>
>
> Ted Husted wrote:
> > I'm looking at  <https://issues.apache.org/struts/browse/WW-809> which
> > would let us load message resources by designating a package with a
> > wildcard character, like this
> >
> >  * webwork.custom.i18n.resources=ApplicationResources, actions/*
> >
> > in which case all the ".properties"  files in the "actions" package
> > would be added to the configuration.
> >
> > One aspect of this idea is that it might let us multiple resource
> > files, even when there is not a corresponding Action. The lack of an
> > Action came up in the extended CodeBehind thread, since we might have
> > a page that doesn't have it's own Action.
> >
> > There are other features to the patch, like optional recursion support
> > (which might also play nice with CodeBehind).
> >
> > My questions are
> >
> >  * Does this sound like a good idea to everyone?
> >
> >  * Is this a XWork level patch or something we should apply here?
> >
> >  * If we apply it here, is it big enough for a CLA?
> >
> > -Ted.
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>



-- 
HTH, Ted <http://www.husted.com/ted/blog/>

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to