guice servlet: capturing parts of the URIs

[gissuebot]

From peter.hausel on July 19, 2009 10:00:32

I implemented a django-like named group capturing feature in guice
servlet whereas named regex groups would be saved as request
attributes.

example:
serveRegex("/myrest/<name>(.)/<id>(.)").with(MySerlvet.class)

this will capture the regexp groups and save the values as 'name' and
'id' request attributes

if you are interested the patch is here: https://code.google.com/p/guice-maven/source/browse/trunk/guice_servle.. .

please let me know what you think

Original issue: http://code.google.com/p/google-guice/issues/detail?id=405

[gissuebot]

From peter.hausel on July 19, 2009 07:01:29

sorry, this is the correct url: https://code.google.com/p/guice-maven/source/browse/trunk/guice_servlet_named_group/guice-servlet.patch

[gissuebot]

From dhanji on July 19, 2009 16:13:34

This is very cool. However will this break existing regexes? =(

[gissuebot]

From peter.hausel on July 19, 2009 23:10:38

I do not think this would break existing code.

if there was not any regexp group found (or the feature is not implemented yet ie for
normal web.xml matching), then

Map<String,Object> map =
patternMatcher.getPatternWithNamedGroups(request.getServletPath());
+     if ( map != null) {
+       for (Map.Entry<String,Object> entry: map.entrySet()) {
+         request.setAttribute(entry.getKey(),entry.getValue());
+       }
+     }

[gissuebot]

From dhanji on July 19, 2009 23:14:11

No, but isn't /myrest/<name> a valid regex?

[gissuebot]

From peter.hausel on July 19, 2009 23:23:48

I do not think /myrest/<name> is a valid URI (at least I have not seen <> used in URIs)

[gissuebot]

From limpbizkit on July 19, 2009 23:32:25

Hmm... I already want us to change the path dispatcher to capture the proper capture group; see issue 376 .

Could we just add an annotated binding for the Matcher that matched the current servlet? Then the user can
interpret this however he wants:
  @Provides @Named("Request ID")
  String provideRequestedId(@Named("Request Path") Matcher matcher) {
    return matcher.group(1);
  }

Perhaps this is too loose, but I'd prefer to avoid creating a metalanguage for servlets. That's for rich
frameworks to do.

[gissuebot]

From peter.hausel on July 19, 2009 23:49:19

I think the main difference is that in my proposed solution everything is in one
place (which was the main motivation for me),
by looking at this
serveRegex("/myrest/<name>(.)/<id>(.)").with(MySerlvet.class)
I know a) what's the URI to match b) what are the variable names that need to be
captured.

Obviously it's your call though.

Originally I wanted to add my implementation on top of guice servlet but the whole
package is very restrictive (ie most of the things are defined as package private).
Would it be possible to at least open up guice servlet for extensions like this?
(Right now I need to host my patched version)

[gissuebot]

From dhanji on July 19, 2009 23:55:46

When you say open up, do you mean with a before/after processor or something like that?

Or do you mean allowing people to plug in their own path matchers? (I can see us doing the latter a bit more
easily)

[gissuebot]

From peter.hausel on July 20, 2009 00:07:18

in ServletModule :

 private final FiltersModuleBuilder filtersModuleBuilder = new FiltersModuleBuilder();
  private final ServletsModuleBuilder servletsModuleBuilder = new
ServletsModuleBuilder();

(on top of this, the builders are package private)

so it would be great if the builders (ServletsModuleBuilder,FiltersModuleBuilder)
were only protected and I could inject my own versions of ServletsModuleBuilder,
FiltersModuleBuilder and matchers.

[gissuebot]

From sberlin on February 21, 2011 17:48:17

(No comment was entered for this change.)

Labels: Extension-Servlet