You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@abdera.apache.org by Chris Berry <ch...@gmail.com> on 2007/10/09 16:03:10 UTC
unit testing RegexTargetResolver
Greetings,
I would like to write a compact JUnit test around the RegexTargetResolver.
This way I can verify that particular URLs resolves to the correct type;
SERVICE,COLLECTION,ENTRY
without having to bring in the rest of the Abdera machinery (i.e. having to
make an actual call)
I can get a hold of the RegexTargetResolver pretty easily.
But it requires a Request object;
public Target resolve(Request request)
And I don't see an easy way to create a Request to use in this scenario.
E.g. something like this;
AbderaClient client = new AbderaClient();
RequestOptions options = client.getDefaultRequestOptions();
// the following doesn't exist...
options.setURL( "http://localhost:8080/foo/bar" );
TargetType type = targetResolver.resolve( options ).getType();
assertTrue( type.equals( TargetType.SERVICE );
Is there a simple way to accomplish this??
Thanks much,
-- Chris
Re: unit testing RegexTargetResolver
Posted by James M Snell <ja...@gmail.com>.
The Target resolver mechanism was designed specifically to allow for
multiple implementation approaches. Having something easier than
regex's would be fantastic.
And yes, the target resolver does have a mechanism for extracting
information from the url.
- James
Jim Ancona wrote:
> Chris Berry wrote:
>> (RegExs are notoriously hard to get right, particularly when there are
>> a multitude of use cases ;-)
>
> I wonder if regular expressions are too powerful for this application.
> Perhaps something like Ant paths, as used in Spring's
> SimpleUrlHandlerMapping[1] would better hit the 80/20 point?
>
> So the example from the RegexTargetResolver javadocs would change from
>
> tr.setPattern("/atom/([^/#?]+)/([^/#?]+)",ResourceType.ENTRY);
>
> to
>
> tr.setPattern("/atom/*/*",ResourceType.ENTRY);
>
> If this sounds worthwhile, I could try putting an AntPathTargetResolver
> together.
>
> A related question: Does Abdera provide any support for getting the
> pattern matches from the Target? (I couldn't find any.) I ran into a
> Spring extension called ParameterizedUrlHandlerMapping[2] which
> addresses a similar problem by naming the patterns so they can be
> accessed downstream.
>
> Jim
>
> [1] -
> http://www.springframework.org/docs/api/org/springframework/web/servlet/handler/SimpleUrlHandlerMapping.html
>
> [2] -
> http://www.carbonfive.com/community/archives/2007/06/parameterized_rest_urls_with_spring_mvc.html
>
>
Re: unit testing RegexTargetResolver
Posted by Jim Ancona <ji...@anconafamily.com>.
Chris Berry wrote:
> (RegExs are notoriously hard to get right, particularly when there are a
> multitude of use cases ;-)
I wonder if regular expressions are too powerful for this application.
Perhaps something like Ant paths, as used in Spring's
SimpleUrlHandlerMapping[1] would better hit the 80/20 point?
So the example from the RegexTargetResolver javadocs would change from
tr.setPattern("/atom/([^/#?]+)/([^/#?]+)",ResourceType.ENTRY);
to
tr.setPattern("/atom/*/*",ResourceType.ENTRY);
If this sounds worthwhile, I could try putting an AntPathTargetResolver
together.
A related question: Does Abdera provide any support for getting the
pattern matches from the Target? (I couldn't find any.) I ran into a
Spring extension called ParameterizedUrlHandlerMapping[2] which
addresses a similar problem by naming the patterns so they can be
accessed downstream.
Jim
[1] -
http://www.springframework.org/docs/api/org/springframework/web/servlet/handler/SimpleUrlHandlerMapping.html
[2] -
http://www.carbonfive.com/community/archives/2007/06/parameterized_rest_urls_with_spring_mvc.html
Re: unit testing RegexTargetResolver
Posted by James M Snell <ja...@gmail.com>.
Look at org.apache.abdera.test.server.UtilityTest... there is a
DummyRequestContext that provides the basics. That can be pulled out so
as to be generally reusable.
- James
Brian Moseley wrote:
> On 10/9/07, Chris Berry <ch...@gmail.com> wrote:
>
>> FWIW, I think that many users will need to be able to do this.
>> (RegExs are notoriously hard to get right, particularly when there
>> are a multitude of use cases ;-)
>> So perhaps we should build this capability directly into Abdera??
>
> definitely. it's on my list of things to do when i get time :D
>
Re: unit testing RegexTargetResolver
Posted by Brian Moseley <bc...@osafoundation.org>.
On 10/9/07, Chris Berry <ch...@gmail.com> wrote:
> FWIW, I think that many users will need to be able to do this.
> (RegExs are notoriously hard to get right, particularly when there
> are a multitude of use cases ;-)
> So perhaps we should build this capability directly into Abdera??
definitely. it's on my list of things to do when i get time :D
Re: unit testing RegexTargetResolver
Posted by Chris Berry <ch...@gmail.com>.
Thank you Brian.
FWIW, I think that many users will need to be able to do this.
(RegExs are notoriously hard to get right, particularly when there
are a multitude of use cases ;-)
So perhaps we should build this capability directly into Abdera??
Thanks again Brian.
Cheers,
-- Chris
On Oct 9, 2007, at 9:43 AM, Brian Moseley wrote:
> On 10/9/07, Chris Berry <ch...@gmail.com> wrote:
>
>> I can get a hold of the RegexTargetResolver pretty easily.
>> But it requires a Request object;
>>
>> public Target resolve(Request request)
>>
>> And I don't see an easy way to create a Request to use in this
>> scenario.
>
> How about a mock implementation of Request? You could perhaps base it
> on Spring's MockHttpServlet, as i've done here:
>
> http://svn.osafoundation.org/server/cosmo/trunk/cosmo/src/test/unit/
> java/org/osaf/cosmo/atom/provider/mock/BaseMockRequestContext.java
S'all good --- chriswberry at gmail dot com
Re: unit testing RegexTargetResolver
Posted by Brian Moseley <bc...@osafoundation.org>.
On 10/9/07, Chris Berry <ch...@gmail.com> wrote:
> I can get a hold of the RegexTargetResolver pretty easily.
> But it requires a Request object;
>
> public Target resolve(Request request)
>
> And I don't see an easy way to create a Request to use in this scenario.
How about a mock implementation of Request? You could perhaps base it
on Spring's MockHttpServlet, as i've done here:
http://svn.osafoundation.org/server/cosmo/trunk/cosmo/src/test/unit/java/org/osaf/cosmo/atom/provider/mock/BaseMockRequestContext.java