[
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
