hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Roland Weber (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HTTPCORE-104) Handler Registry Should Match Using Regular Expressions
Date Mon, 23 Jul 2007 19:02:31 GMT

    [ https://issues.apache.org/jira/browse/HTTPCORE-104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12514731
] 

Roland Weber commented on HTTPCORE-104:
---------------------------------------

Hello Nels,

I don't think you should bother with Java 1.3 compatibility in your application, unless you
have to. We just make sure that the _source_ of HttpCore/main compiles and tests against Java
1.3. Even the binary releases we ship are built with Java 1.4 and not tested against 1.3.
If anyone has a need to use core in a Java 1.3 environment, they are supposed to compile the
sources themselves. As soon as you use something besides the core, you'll inherit a 1.4 dependency
anyway.
Please, do make use of Java 1.4 features. We also love to use them, anywhere but in core.
Implement your own handler and request class using 1.4, that's what we want you to do. Core
is meant to be used as a framework where you plug in what you need, making use of features
available in your application's target environment. We just can't accept such contributions
into the core itself, because we don't want to impose tougher requirements on other people's
applications.

cheers,
  Roland


> Handler Registry Should Match Using Regular Expressions
> -------------------------------------------------------
>
>                 Key: HTTPCORE-104
>                 URL: https://issues.apache.org/jira/browse/HTTPCORE-104
>             Project: HttpComponents Core
>          Issue Type: Improvement
>          Components: HttpCore
>    Affects Versions: 4.0-alpha4, 4.0-alpha5, 4.0-alpha6, 4.0-beta1, 4.0-rc1
>            Reporter: Nels N. Nelson
>             Fix For: 4.0-alpha6
>
>
> Hello!
> In HttpRequestHandlerRegistry, the method matchUriRequestPattern(final String pattern,
final String requestUri) uses what is, in my opinion, a poor strategy for pattern matching.
> This method is better and provides more flexibility to developers trying to add new Handlers:
> <code>
>     protected boolean matchUriRequestPattern(final String pattern, 
>         final URI requestUri) 
>     {
>         try {
>             String path = requestUri.getPath();
>             Pattern p = Pattern.compile(pattern);
>             Matcher matcher = p.matcher(path);
>             return matcher.matches();
>         }
>         catch (java.util.regex.PatternSyntaxException ex) {
>             return false;
>         }
>     }
> </code>
> These changes would make this code far more accurate:
> <code>
>     protected void doService(
>             final HttpRequest request, 
>             final HttpResponse response,
>             final HttpContext context) throws HttpException, IOException {
>         HttpRequestHandler handler = null;
>         if (this.handlerResolver != null) {
>             URI requestURI = request.getRequestLine().getUri();
>             handler = this.handlerResolver.lookup(requestURI);
>         }
>         if (handler != null) {
>             handler.handle(request, response, context);
>         } else {
>             response.setStatusCode(HttpStatus.SC_NOT_IMPLEMENTED);
>         }
>     }
> </code>
> These changes would allow developers to add new custom handlers in this way:
> <code>
> String pattern = ".*\\.extension";
> HttpRequestHandler handler = new HttpServletHandler(...);
> HttpRequestHandlerRegistry reqistry = new HttpRequestHandlerRegistry();
> reqistry.register(pattern, handler);
> </code>
> Currently, my version of the HttpComponents core software uses <code>URI</code>
to represent the <code>requestURI</code> parameter throughout the code.  This
has provided greater convenience, error handling (in the instantiation of the <code>BasicRequestLine</code>
class, for instance), and flexibility of extension.  I can enumerate the specifics on this,
if necessary, but I believe that would be a discussion for a separate Jira Issue, which I
will happily create, if I am convinced that its priority would be at least major, which currently,
I am not.  Such a change would cause several changes throughout multiple classes, stemming
from changes to the <code>RequestLine</code> interface as follows:
> <code>
> public interface RequestLine {
>     String getMethod();
>     HttpVersion getHttpVersion();
>     URI getUri();
>     
> }
> </code>
> Thanks for your attention to this issue.
> -Nels

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org


Mime
View raw message