[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
Mon Jul 18 14:41:16 CEST 2011
Hi
I have implemented this patch of Guillaume, whereas did some
modification to it.
The next steps are:
- Develop another matcher implementation which allows to use query
strings for mapping
- Make matcher configurable per yanel and per realm
Cheers
Michael
Am 04.12.09 22:19, schrieb Guillaume Déflache:
> Some progress report as Simon showed some renewed interest in this
> lately! ;)
> Cf.
> http://lists.wyona.org/pipermail/yanel-development/2009-December/004192.html
>
> Guillaume Déflache a écrit :
>> 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)
>
> Any opinion about these issues, esp. Simon? On the 3rd I'd personally
> go for the "match any other parameter" solution.
>
>
>> *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.)
>
> I did some (unfinished) work on this, please review the attachment.
> There is still some unfinished stuff, mainly around the TODO and XXX
> markers, please ask me as they probably won't make any sense to anyone
> else than me.
>
>
>> 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?
>
> The current interface has the same name but provide
> getResourceConfiguration(Environment environment, Realm realm, String
> path) instead: indeed IMHO what we need to be configurable is only the
> RC object selector, not a Resource selector (all Resource objects may
> be instantiated in the same way for now, better not expose
> classloading guts before we get our runtime-modularity story right).
>
>
>> 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
>
> That's more or less what is done in the patch.
>
>
>> 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 did not tackle that yet.
>
> We may not need to change Yanel#getResourceManager or even
> ResourceManager to do this, as ResourceManager#getResource has already
> the realm as parameter.
> Maybe the ResourceManager should/could become a registry of
> ResourceTypeMatcherV1 objects for all realms, adn then we would only
> need
> ResourceManager#setResourceTypeMatcherForRealm(ResourceTypeMatcherV1
> matcher, Realm realm)??? But then maybe we would only need
> ResourceTypeMatcherV1#getResourceConfiguration(Environment
> environment, String path) without the realm parameter?
>
> Or maybe we should wait and do that in ResourceTypeMatcherV2?
>
>
>> 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. It also
>
> This still can/should be done once dust has settled on all things above.
>
>> needs changing because Michi would like to be able to parametrize the
>> "map.rc-map" file name.
>
>
> This will probably be left as an exercise to casual contributors! :P
>
>
> Cheers,
> Guillaume
More information about the Yanel-development
mailing list