[Yanel-dev] [HEADS UP] ResourceManager and ResourceConfigurationMap class may die soon; resource-types' URL matching (e.g. on request parameters)

Michael Wechner michael.wechner at wyona.com
Wed Jun 24 10:53:07 CEST 2009


Guillaume Déflache schrieb:
> Hi!
>
> As discussed with Simon some time ago (unfortunately no one took notes 
> :(...) we would like to be able to choose the resource-type to use for 
> a request by matching the value or presence of HTTP request parameters 
> (ATM one can only match on the request URI).
>
> As far as Michi and I can remember, we then considered at least 2 
> options:
>
>
> *Option 1*: allow a syntax similar to "**?my-param-name=*" in 
> map.rc-map files in "matcher" elements for the "pattern" attribute.
>
> Some issues:
> - most probably we want to ignore the order of the request parameters 
> as they are written in the pattern, as anyway AFAIK the servlet spec 
> does not define it
> - should we also match parameters passed through POST, albeit the 
> syntax of the pattern could make use think it would only work for GET: 
> Mich and I would say we should, and the servlet API makes that choice 
> easier
> - what would "**" mean in the query string part? I'd suggest it should 
> either throw some parsing exception, or match any other parameter that 
> could also be present (would allow use to distinguish between the two 
> cases "only these parameters" and "these parameters and some others we 
> do not care about", although that might be somewhat counter-intuitive)
>
>
> *Option 2*: allow full customization of the matching policy by 
> introducing a new Java interface for it.
> (1st please note that #1 can readily be implemented independently of 
> #2 but of course we'd rather put new functionality in the new places 
> if possible.)
>
> This interface would be almost identical to the 
> org.wyona.yanel.core.ResourceManager class's (minus the deprecated 
> parts) and especially provide getResource(Environment environment, 
> Realm realm, String path, ResourceConfiguration rc): having access to 
> the environment should allow any future kind of matching imaginable 
> (see Apache Cocoon for wild ideas! ;) ).
> I'd suggest to use a better name (*Manager is rather uninspiring): 
> org.wyona.yanel.core.api.ResourceTypeMatcherV1 maybe?

+1
> Then as 1st step we would have to reimplement 
> org.wyona.yanel.core.ResourceManager using the new interface and still 
> use it as the default for backward-compatibility.
> Then we would have to allow configuration of the concrete matching 
> class. ATM this is done in the Yanel class, but Michi would like it to 
> be configurable per realm, and thanks to the way it's currently 
> encapsulated there this is also possible only with some more 
> deprecations (namely Yanel.getResourceManager).

I think it gives us more freedom re upgradeability, etc.

> I'd also suggest we hide functionality actually in 
> ResourceConfigurationMap in the concrete matcher implementations: the 
> class only has static methods and needlessly expose mechanics.

can you make a concrete suggestion for this?
> It also needs changing because Michi would like to be able to 
> parametrize the "map.rc-map" file name.
>
>
> WDYT?

since we discusssed this offline already, I am happy to agree to this 
summary and that we proceed like you described above ;-)

Cheers

Michael
>
>
> Cheers,
>    Guillaume



More information about the Yanel-development mailing list