Re: [HttpCore] EntityDeserializer and EntitySerializer public interfaces
Hi Oleg, With all the latest changes in HttpCore I no longer think that pluggable EntityDeserializer and EntitySerializer represent any real value. They just clutter the API. One can still override #receive/sendRequestEntity #send/receiveResponseEntity methods of the default client / server connection implementations to achieve the same net result. Would any one really miss these interfaces? I wouldn't. I had been thinking about an extra level in the connection implementation hierarchy just to have a place for them while not requiring them to be used for each implementation. cheers, Roland - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [HttpCore] non-blocking NIO HTTP transport (server and client side)
Hi Robert,
One thing with the example code that looks suspicious to me is the keep
alive handling both the client and the server contains something like:
if (!this.connStrategy.keepAlive(response, context)) {
conn.close();
}
Sure it is only a few lines of code, but why not say that client and
server always close the connection and then handle persistent
connections on a higher level (by the connection manager or whatever it
is called).
The current code demands that all users of http client does the right
thing with regards to keep alive.
There currently is no HttpClient 4.0. We only have HttpCore.
We'll add automatic keep-alive handling in the HttpClient.
The examples just show that keep-alive is possible with
HttpCore alone.
cheers,
Roland
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: HttpClient 3.1-beta1 release site preview
Hi Michael, We actually did do separate release notes for the 2.0/3.0 releases (link below). I would agree that they are not necessarily required, but don't feel constrained if you'd like to do two. If separate notes for the 3.x releases haven't been missed until now, this is not the time to put effort into it :-) cheers, Roland - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: HttpClient 3.1-beta1 release site preview
Hi Oleg, on the download page, the Release Notes links of both 3.0.1 and 3.1-beta1 point to the same location. At that location, release notes for 3.1 alpha 1 are located. Something's fishy here. Even assuming that the alpha notes will be replaced by the beta notes automatically at some point in the publishing process, the link for 3.0.1 should point to release notes for 3.0.1. cheers, Roland - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [HTTPClient 3.0.1] Bug: Multipart posts with files named using UTF-8 characters
Hi Odi, Look at RFC 2047 which updates RFC 1521. This method is quite popular in E-Mail traffic. Maybe real-world HTTP servers and clients support it? Maybe, but MIME encoding is not really our line of work. If somebody is willing to come up with a patch, I would suggest to implement something similar to the non-ASCII HTTP headers we already have, to be used at the application developer's risk. http://jakarta.apache.org/commons/httpclient/apidocs/org/apache/commons/httpclient/params/HttpMethodParams.html#HTTP_ELEMENT_CHARSET cheers, Roland - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Commented: (HTTPCLIENT-579) NTLMv2 support
Hi guys, is any one of you subscribed to legal-discuss@ ? I've tried to subscribe again, but no success yet. There was this ping message whether anybody still cares about using LGPL code, and somebody should send a YES in response. cheers, Roland - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [HttpCore] NIO extensions: event-driven non-blocking HTTP transport
Hi Oleg, just a short glimpse... ContentDecoder.isCompeted should be .isCompleted ContentEncoder.isCompeted should be .isCompleted NHttpClientConnection.getHttpResponse() NHttpServerConnection.getHttpRequest() We've avoided tying the request and response directly so far. But it's probably not a big issue, so leave it that way. NHttpServerConnection.submitContinue() I don't like this at all. You are assuming that 100 continue is the only preliminary response that will ever be sent. That is true for the current HTTP specifications, but HTTP explicitly allows for extensions. I don't see why we should restrict our API in this case. Alternatives: 1. NHttpServerConnection.submitPreliminary(HttpResponse) 2. NHttpServerConnection.submitResponse(HttpResponse, boolean preliminary) NHttpClientHandler.exception(...) Will the client handler get a chance to handle other kinds of exceptions, too? I usually prefer a generic error handling method, where the handler decides what to do (if anything): /** @return true if handled, false otherwise */ boolean NHttpClientHandler.exception(conn, Throwable) NHttpServerHandler.exception(...) See comments for client. Your JavaDocing is much improved! I noticed a typo in NHttpConnection.request*put: oprtations. cheers, Roland - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Commented: (HTTPCLIENT-579) NTLMv2 support
Hi Sebastian, http://www.apache.org/foundation/mailinglists.html says that the list is open to committers; others may be admitted on application to the board. Your e-mail: From: Roland Weber Sent: Monday, September 25, 2006 13:48 To: legal-discuss@apache.org Subject: LGPL and compile dummies? was forwarded to the list on 3rd Oct, but so far I can't trace any replies. Thanks for checking. I had a look at the public mailing list archive this week, too. That's why I tried to subscribe again yesterday. I guess the moderators check the moderate requests not too often. Maybe they pick up the subscription mail this week-end. If not, I'll ask Henri for ideas before mailing to [EMAIL PROTECTED] I've seen some posts from him there, so there's got to be some way in :-) cheers, Roland - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r463914 - in /jakarta/httpcomponents/httpcore/trunk/module-main/src: main/java/org/apache/http/entity/ main/java/org/apache/http/impl/ main/java/org/apache/http/impl/entity/ test/java/
Hi Oleg, I get build breaks in HttpCoreNIO: [javac] /home/rweber/HttpComponents/project-trunk/httpcore/module-nio/src/main/java/org/apache/http/nio/impl/AsyncHttpClientConnection.java:80: DefaultEntitySerializer(org.apache.http.entity.ContentLengthStrategy) in org.apache.http.impl.entity.DefaultEntitySerializer cannot be applied to () [javac] setEntitySerializer(new DefaultEntitySerializer()); [javac] ^ [javac] /home/rweber/HttpComponents/project-trunk/httpcore/module-nio/src/main/java/org/apache/http/nio/impl/AsyncHttpClientConnection.java:81: DefaultEntityDeserializer(org.apache.http.entity.ContentLengthStrategy) in org.apache.http.impl.entity.DefaultEntityDeserializer cannot be applied to () [javac] setEntityDeserializer(new DefaultEntityDeserializer()); [javac] ^ [javac] /home/rweber/HttpComponents/project-trunk/httpcore/module-nio/src/main/java/org/apache/http/nio/impl/AsyncHttpServerConnection.java:78: DefaultEntitySerializer(org.apache.http.entity.ContentLengthStrategy) in org.apache.http.impl.entity.DefaultEntitySerializer cannot be applied to () [javac] setEntitySerializer(new DefaultEntitySerializer()); [javac] ^ [javac] /home/rweber/HttpComponents/project-trunk/httpcore/module-nio/src/main/java/org/apache/http/nio/impl/AsyncHttpServerConnection.java:79: DefaultEntityDeserializer(org.apache.http.entity.ContentLengthStrategy) in org.apache.http.impl.entity.DefaultEntityDeserializer cannot be applied to () [javac] setEntityDeserializer(new DefaultEntityDeserializer()); [javac] ^ [javac] 4 errors cheers, Roland - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (HTTPCLIENT-579) NTLMv2 support
[ http://issues.apache.org/jira/browse/HTTPCLIENT-579?page=comments#action_12442369 ] Roland Weber commented on HTTPCLIENT-579: - Hello Konstantin, we have an NTLM FAQ now. Your question is #4. http://wiki.apache.org/jakarta-httpclient/FrequentlyAskedNTLMQuestions cheers, Roland NTLMv2 support -- Key: HTTPCLIENT-579 URL: http://issues.apache.org/jira/browse/HTTPCLIENT-579 Project: HttpComponents HttpClient Issue Type: Improvement Components: HttpAuth Affects Versions: 3.0 Final Environment: WIndows 2000 Pro SP4, JDK 1.4.2 Reporter: Konstantin Kasatkin Fix For: 3.1 Alpha 1 Attachments: NTLMv2.rar Hello guys, recently I've encouner the problem how to interact with HTTP resourses protected tough security policy allowed to use only NTLMv2 authorization scheme from a java application. Earlier I used httpclient to accomplish NTLMv1 authorization, but when I was requested to move to NTLMv2 I was surprised, that httpclient does not support this. I've dug all the Internet and found some articles and examples how to implement it, and finally having compiled all this enormous heap of information, I have a couple modified classes from httpclient project, that I'd like to share with you and other users of httpclient. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Commons HttpClient 3.1 BETA1
+0 Oleg Kalnichevski wrote: I propose that we mark the latest code in SVN trunk as 3.1-BETA1 and proceed with a release. Please vote as follows: -- Vote: HttpClient 3.1-BETA1 release [ ] +1 I am in favor of the release, and will help support it. [ ] +0 I am in favor of the release, but am unable to help support it. [ ] -0 I am not in favor of the release. [ ] -1 I am against this proposal (must include a reason). -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [HttpCore.NIO] Selector
Hi Oleg, I will be doing a lot of work on HttpCore NIO in the coming weeks, so IOReactor is very likely to undergo some major changes. Please do feel free to add more methods to the interface and/or the impl class if you think something is missing. I won't have time to do implementation work there. To better integrate with NIO functionality, we could also add getSelector() to the IOReactor interface and getSelectionKey() to the IOSession interface. Does the latter make sense? I do not know. I suspect direct manipulation of SelectionKey and Selector is very likely to break implementations of those interfaces. I would probably avoid exposing low level NIO primitives unless we have a very strong case for doing otherwise. If I understood the API correctly, something must be registered with a Selector so that the IOReactor gets any events to be handled at all. On the other hand, that could be done by implementation specific reactor methods rather than by exposing the Selector in the interface. I'll wait and see how things shape up in the future. cheers, Roland - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (HTTPCLIENT-604) Don't issue a warning when using getResponseBodyAsString
[ http://issues.apache.org/jira/browse/HTTPCLIENT-604?page=all ] Roland Weber closed HTTPCLIENT-604. --- Resolution: Duplicate Don't issue a warning when using getResponseBodyAsString Key: HTTPCLIENT-604 URL: http://issues.apache.org/jira/browse/HTTPCLIENT-604 Project: HttpComponents HttpClient Issue Type: Bug Affects Versions: 3.0.1 Reporter: Hans Dockter Priority: Minor If I use the method HttpMethodBase.getResponseBodyAsString I get a log message with log level warning. We take our log output very seriously. For us warning means, something has to done. But we use this method to get information from a trusted intranet webapplication. The http spec does not expect content-length to be set. So this intranet webapp behaves perfectly ok. And our application also does the right thing. Please, please (so many libraries are too verbose in there logging) put a warning in the javadoc but don't log a warning. For us this is a bug. We can't use this method. We have to use a workaround like this: IOUtils.toString(method.getResponseBodyAsStream()); Unfortunately we have to deal with the encoding by ourselves now. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[HttpCore.NIO] Selector
Hi Oleg, I am wondering whether we should define a more granular lifecycle for an IOReactor. More specifically, whether we should introduce a prepare() or initialize() method, after which the Selector for the IOReactor is known to exist. And maybe a cleanup() or destroy() method to be called after execute() returns? To better integrate with NIO functionality, we could also add getSelector() to the IOReactor interface and getSelectionKey() to the IOSession interface. Does the latter make sense? cheers, Roland - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [HttpCore][HttpAsync][POLL] Java 1.5 dependency for HttpCore NIO and eventually HttpAsync?
(resend, as a virus has allegedly been detected in the previous one) How would everyone feel about possibility of using Java 1.5 for HttpCore NIO (and possibly HttpAsync as it would also benefit greatly from using java.util.concurrent code instead of home brewed sync primitives)? I guess by the time HttpAsync is ready for a beta release we'll have Java 6 available and J2EE 5.0 as current. +1 cheers, Roland - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [HttpCore][HttpAsync][POLL] Java 1.5 dependency for HttpCore NIO and eventually HttpAsync?
FYI, I've checked the Java requirements of a few other projects: Synapse requires Java 1.4 Axis requires Java 1.3, recommends Tomcat as platform Tomcat 5.5 requires Java 1.5, or needs a 1.4 compatibility package We should try to restrict use of Java 1.5 to implementation classes and leave them out of the API. Maybe I'll split the Ant build process to compile API and implementation classes in two steps, so we can detect unwanted dependencies. One of these days, if time permits. cheers, Roland - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (HTTPCORE-14) Consider decoupling HttpHost and Scheme and moving Scheme, SocketFactory and SecureSocketFactory to HttpConn
[ http://issues.apache.org/jira/browse/HTTPCORE-14?page=comments#action_12438493 ] Roland Weber commented on HTTPCORE-14: -- Hi Oleg, I think the scheme should remain in HttpHost as a String. Maybe with automatic lowercase conversion. The getter method could be called getSchemeName instead of getScheme, to avoid confusion. Otherwise, I'm fine with this change. (I have one more idea for HttpCore, but it's rather a side issue and doesn't have to go into the next alpha.) cheers, Roland Consider decoupling HttpHost and Scheme and moving Scheme, SocketFactory and SecureSocketFactory to HttpConn Key: HTTPCORE-14 URL: http://issues.apache.org/jira/browse/HTTPCORE-14 Project: HttpComponents Core Issue Type: Improvement Components: HttpCore Reporter: Oleg Kalnichevski Priority: Minor Attachments: 20060927-httphost.patch SocketFactory interface in HttpCore implies a blocking process of opening a new socket. Moreover, there is no way to interrupt the process of opening a connection due to limitations of Java 1.3 API. I suggest the SocketFactory and SecureSocketFactory interfaces and the Scheme class dependent on those interfaces be moved to HttpConn and the HttpHost class be decoupled from Scheme. (This is going to be the last controversial bit I wanted to propose and once this issue is resolved I can safely declare I am done with HttpCore) Oleg -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (HTTPCORE-13) AbstractHttpProcessor is not really abstract
[
http://issues.apache.org/jira/browse/HTTPCORE-13?page=comments#action_12438496
]
Roland Weber commented on HTTPCORE-13:
--
Hi Oleg,
HttpInterceptorChain would be my favourite. But what if we just dropped
pre- and post- from method names and kept the interface name?
I'm fine with that, too. We could also go one step further and align the method
names
with those in Http{Request|Response}Interceptor. Then we'd have hierarchical
sets
of interceptors :-)
cheers,
Roland
AbstractHttpProcessor is not really abstract
Key: HTTPCORE-13
URL: http://issues.apache.org/jira/browse/HTTPCORE-13
Project: HttpComponents Core
Issue Type: Improvement
Components: HttpCore
Affects Versions: 4.0-alpha3
Reporter: Roland Weber
Assigned To: Roland Weber
Priority: Minor
Attachments: 2k6-09-25-core-proc-1.txt
AbstractHttpProcessor is declared abstract though it does not have any
abstract method. This artificially restricts use of the base class
functionality to subclassing and prohibits use by reference. That is one of
the reasons why HttpAsync has an ugly AsyncHttpProcessor class.
Patch follows.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (HTTPCORE-13) AbstractHttpProcessor is not really abstract
[ http://issues.apache.org/jira/browse/HTTPCORE-13?page=comments#action_12438177 ] Roland Weber commented on HTTPCORE-13: -- Hi Oleg, here are a few names I'd feel comfortable with, in alphabetical order: HttpHeaderHandler HttpHeaderProcessor HttpInterceptHandler HttpInterceptionHandler HttpPrePostProcessor cheers, Roland AbstractHttpProcessor is not really abstract Key: HTTPCORE-13 URL: http://issues.apache.org/jira/browse/HTTPCORE-13 Project: HttpComponents Core Issue Type: Improvement Components: HttpCore Affects Versions: 4.0-alpha3 Reporter: Roland Weber Assigned To: Roland Weber Priority: Minor Attachments: 2k6-09-25-core-proc-1.txt AbstractHttpProcessor is declared abstract though it does not have any abstract method. This artificially restricts use of the base class functionality to subclassing and prohibits use by reference. That is one of the reasons why HttpAsync has an ugly AsyncHttpProcessor class. Patch follows. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (HTTPCORE-13) AbstractHttpProcessor is not really abstract
[ http://issues.apache.org/jira/browse/HTTPCORE-13?page=comments#action_12437906 ] Roland Weber commented on HTTPCORE-13: -- Hi Oleg, I kind of feel that HttpProtocolHandler does not give the slightest indication what the class is supposed to do. I liked the HttpInterceptorChain suggestion better. When I worked on the patch I also considered HttpMessageProcessor. HTTP protocol handling is much more than just setting up or interpreting a few headers. Of course, processing is also a very generic term. Some clicks on WordNet (http://wordnet.princeton.edu/perl/webwn) lead me to shape or mould as alternatives to indicate that the purpose is to bring a message into a particular form suitable for the following step. HttpMessageShaper? HttpMessageSculptor? ;-) HttpMessageFilter is probably misleading. cheers, Roland AbstractHttpProcessor is not really abstract Key: HTTPCORE-13 URL: http://issues.apache.org/jira/browse/HTTPCORE-13 Project: HttpComponents Core Issue Type: Improvement Components: HttpCore Affects Versions: 4.0-alpha3 Reporter: Roland Weber Assigned To: Roland Weber Priority: Minor Attachments: 2k6-09-25-core-proc-1.txt AbstractHttpProcessor is declared abstract though it does not have any abstract method. This artificially restricts use of the base class functionality to subclassing and prohibits use by reference. That is one of the reasons why HttpAsync has an ugly AsyncHttpProcessor class. Patch follows. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (HTTPCORE-13) AbstractHttpProcessor is not really abstract
[ http://issues.apache.org/jira/browse/HTTPCORE-13?page=comments#action_12437918 ] Roland Weber commented on HTTPCORE-13: -- Hi Oleg, no problem. You can also change HttpRequestExecutor and HttpService back to subclassing, if you prefer that. I only changed them to use a reference because I moved the implementation to an impl package. cheers, Roland AbstractHttpProcessor is not really abstract Key: HTTPCORE-13 URL: http://issues.apache.org/jira/browse/HTTPCORE-13 Project: HttpComponents Core Issue Type: Improvement Components: HttpCore Affects Versions: 4.0-alpha3 Reporter: Roland Weber Assigned To: Roland Weber Priority: Minor Attachments: 2k6-09-25-core-proc-1.txt AbstractHttpProcessor is declared abstract though it does not have any abstract method. This artificially restricts use of the base class functionality to subclassing and prohibits use by reference. That is one of the reasons why HttpAsync has an ugly AsyncHttpProcessor class. Patch follows. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (HTTPCLIENT-602) refactor HttpClientConnection and HttpProxyConnection
[ http://issues.apache.org/jira/browse/HTTPCLIENT-602?page=comments#action_12437537 ] Roland Weber commented on HTTPCLIENT-602: - I just noticed that HttpClientConnection still has the getTargetHost() method. If our goal is to define only a minimal interface in HttpCore, that should be removed too. HttpRequestExecutor no longer creates the HttpContext, so the caller can initialize the target host in the context. cheers, Roland refactor HttpClientConnection and HttpProxyConnection - Key: HTTPCLIENT-602 URL: http://issues.apache.org/jira/browse/HTTPCLIENT-602 Project: HttpComponents HttpClient Issue Type: Improvement Components: HttpConn Reporter: Roland Weber Fix For: 4.0 Alpha 1 Attachments: 20060923-httpasync.patch, 20060923-httpcore.patch, 2k6-08-25-core-conn-1.tar Instead of trying to define a full abstraction for client connections, let's define only a minimal interface in HttpCore with only those methods actually needed in the core. In particular, the core does not need to open connections (since HTTPCORE-11), and it does not care whether a connection is direct or through a proxy. An abstraction for client connections can be defined in HttpConn. (original description:) As discussed on the mailing list, separating the responsibility for establishing connections from the connection objects could improve the design and help with proxy support. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (HTTPCORE-13) AbstractHttpProcessor is not really abstract
[ http://issues.apache.org/jira/browse/HTTPCORE-13?page=all ] Roland Weber updated HTTPCORE-13: - Attachment: 2k6-09-25-core-proc-1.txt Take 1. Idea: - define an interface for processing requests and responses - turn AbstractHttpProcessor into DefaultHttpProcessor, make processing methods public - move default implementation to an implementation package - HttpRequestExecutor and HttpService can no longer derive from DefaultHttpProcessor, since it is in an implementation package Observation: HttpService is in an API package but imports and instantiates two implementation classes. Maybe we should reconsider the whole protocol package with respect to API vs. implementation. Please let me know what you think. cheers, Roland AbstractHttpProcessor is not really abstract Key: HTTPCORE-13 URL: http://issues.apache.org/jira/browse/HTTPCORE-13 Project: HttpComponents Core Issue Type: Improvement Components: HttpCore Affects Versions: 4.0-alpha3 Reporter: Roland Weber Assigned To: Roland Weber Priority: Minor Attachments: 2k6-09-25-core-proc-1.txt AbstractHttpProcessor is declared abstract though it does not have any abstract method. This artificially restricts use of the base class functionality to subclassing and prohibits use by reference. That is one of the reasons why HttpAsync has an ugly AsyncHttpProcessor class. Patch follows. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (HTTPCORE-13) AbstractHttpProcessor is not really abstract
[ http://issues.apache.org/jira/browse/HTTPCORE-13?page=comments#action_12437598 ] Roland Weber commented on HTTPCORE-13: -- Hi Oleg, Wouldn 't HttpInterceptorChain be a better name for this interface, though? The interface in the patch makes no reference to interceptors except in the JavaDoc. If we include methods to add/remove interceptors to the interface, I agree. Right now, those methods are only in the implementation class. I think we'll have more of them in the future (like index-based ones), and I am reluctant to add the full selection to the interface. Read-only is enough for both request executor and service. cheers, Roland AbstractHttpProcessor is not really abstract Key: HTTPCORE-13 URL: http://issues.apache.org/jira/browse/HTTPCORE-13 Project: HttpComponents Core Issue Type: Improvement Components: HttpCore Affects Versions: 4.0-alpha3 Reporter: Roland Weber Assigned To: Roland Weber Priority: Minor Attachments: 2k6-09-25-core-proc-1.txt AbstractHttpProcessor is declared abstract though it does not have any abstract method. This artificially restricts use of the base class functionality to subclassing and prohibits use by reference. That is one of the reasons why HttpAsync has an ugly AsyncHttpProcessor class. Patch follows. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (HTTPCORE-13) AbstractHttpProcessor is not really abstract
[ http://issues.apache.org/jira/browse/HTTPCORE-13?page=comments#action_12437623 ] Roland Weber commented on HTTPCORE-13: -- take 1 committed with minor modifications to JavaDocs I also fixed HttpAsync so that it compiles again. The async fix is minimal and ugly. Things will have to be straightened out later by eliminating AsyncHttpProcessor altogether. The remaining functionality used from HttpRequestExecutor can be provided in AbstractHttpDispatcher instead. cheers, Roland AbstractHttpProcessor is not really abstract Key: HTTPCORE-13 URL: http://issues.apache.org/jira/browse/HTTPCORE-13 Project: HttpComponents Core Issue Type: Improvement Components: HttpCore Affects Versions: 4.0-alpha3 Reporter: Roland Weber Assigned To: Roland Weber Priority: Minor Attachments: 2k6-09-25-core-proc-1.txt AbstractHttpProcessor is declared abstract though it does not have any abstract method. This artificially restricts use of the base class functionality to subclassing and prohibits use by reference. That is one of the reasons why HttpAsync has an ugly AsyncHttpProcessor class. Patch follows. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (HTTPCORE-8) refactor HttpClientConnection and HttpProxyConnection
[ http://issues.apache.org/jira/browse/HTTPCORE-8?page=comments#action_12437223 ] Roland Weber commented on HTTPCORE-8: - Hi Oleg, no objections from my side. You should remove or fix the class end comment in HttpAsyncClientConnection, though :-) And the @author tag for both interface and implementation. cheers, Roland refactor HttpClientConnection and HttpProxyConnection - Key: HTTPCORE-8 URL: http://issues.apache.org/jira/browse/HTTPCORE-8 Project: HttpComponents Core Issue Type: Improvement Components: HttpCore Affects Versions: 4.0-alpha2 Reporter: Roland Weber Fix For: 4.0-alpha3 Attachments: 20060923-httpasync.patch, 20060923-httpcore.patch, 2k6-08-25-core-conn-1.tar Instead of trying to define a full abstraction for client connections, let's define only a minimal interface in HttpCore with only those methods actually needed in the core. In particular, the core does not need to open connections (since HTTPCORE-11), and it does not care whether a connection is direct or through a proxy. An abstraction for client connections can be defined in HttpConn. (original description:) As discussed on the mailing list, separating the responsibility for establishing connections from the connection objects could improve the design and help with proxy support. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (HTTPCORE-8) refactor HttpClientConnection and HttpProxyConnection
[ http://issues.apache.org/jira/browse/HTTPCORE-8?page=all ] Roland Weber updated HTTPCORE-8: Description: Instead of trying to define a full abstraction for client connections, let's define only a minimal interface in HttpCore with only those methods actually needed in the core. In particular, the core does not need to open connections (since HTTPCORE-11), and it does not care whether a connection is direct or through a proxy. An abstraction for client connections can be defined in HttpConn. (original description:) As discussed on the mailing list, separating the responsibility for establishing connections from the connection objects could improve the design and help with proxy support. was: As discussed on the mailing list, separating the responsibility for establishing connections from the connection objects could improve the design and help with proxy support. Assignee: (was: Roland Weber) Updated the description with the results of our last discussion on the mailing list. refactor HttpClientConnection and HttpProxyConnection - Key: HTTPCORE-8 URL: http://issues.apache.org/jira/browse/HTTPCORE-8 Project: HttpComponents Core Issue Type: Improvement Components: HttpCore Affects Versions: 4.0-alpha2 Reporter: Roland Weber Fix For: 4.0-alpha3 Attachments: 2k6-08-25-core-conn-1.tar Instead of trying to define a full abstraction for client connections, let's define only a minimal interface in HttpCore with only those methods actually needed in the core. In particular, the core does not need to open connections (since HTTPCORE-11), and it does not care whether a connection is direct or through a proxy. An abstraction for client connections can be defined in HttpConn. (original description:) As discussed on the mailing list, separating the responsibility for establishing connections from the connection objects could improve the design and help with proxy support. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Lessons Learned
Hello Asankha, Synapse would be expected to work with many messages concurrently (acting as an ESB) we do not want a huge number of threads to be doing IO - and hence the requirement for an async http client. Thanks for the update, I will consider this around christmas time. For the records: Let m be the number of messages processed concurrently and c the number of connections opened concurrently. The original idea of HttpAsync - without NIO - was to have O(c) threads for handling I/O, with a maximum of 2*c for maximum throughput and a minimum of c. With NIO, we can get that number below c as we don't need one thread per connection for receiving messages. But even without NIO, 2*c or c could be a significant improvement over O(m). Still, there is no point in pushing HttpAsync until we've figured out HttpCore and how to deal with opening connections. cheers, Roland - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
HttpCore connections
Hi Oleg, I've had some time to relax and think about connections. As a result, I would like to sum up what I think you are trying to achieve. Please have a look through it and correct me where I got you wrong... In HttpClient, the Connection class directly implemented all the functionality that was needed. In HttpCore, the HttpClientConnection interface started out in a similar fashion, providing basically all the methods we expected an application or any component to be interested in. If I got your intentions right this time, you are trying to change that. Instead of a full-blown abstraction for client connections, you want HttpCore to define a kind of adapter interface, which holds only those methods that are required within HttpCore. Defining a full-blown abstraction is left to HttpConn. The responsibility for opening a connection should be moved outside of HttpCore. Hence, the interface does not need to specify an open(...) method. HttpCore does not care where the connection points to, hence the interface does not need a getTargetHost() method. SocketFactory is only needed to open a connection, hence it is not needed in HttpCore. Have you considered ConnectionReuseStrategy? If opening connections is not the responsibility of HttpCore, then deciding on reuse vs. opening a new one shouldn't be either. cheers, Roland - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: HttpCore connections
Hi Oleg, I've had some time to relax and think about connections. As a result, I would like to sum up what I think you are trying to achieve. Please have a look through it and correct me where I got you wrong... [...] Precisely. Ok. Sorry for being so slow on the uptake. I got on the wrong track when we discussed turning the connection into a container. The idea of my patch for HTTPCORE-8 was to keep the full functionality and just split the responsibilities between the connection object and the operator. I'm fine with the new design. Let's do it. Axe the open(...) method, and getTargetHost() along with it. But this shift of a rather basic responsibility - opening connections - makes me feel even stronger that HttpConn should be released independently from HttpClient. No objections against initial development there, of course. We already had that discussion. I am trying to keep HttpCore as a minimalistic, transport agnostic protocol layer, that is usable with classic I/O sockets, NIO channels, abstract I/O transports such as MINA and what not. The job of HttpCore should be in my opinion to ensure RFC 2616 compliant serialization and deserialization of HTTP messages. The one thing we can't help is that it uses streams. But there's no point in defining yet another I/O abstraction to be mapped to streams and channels. ConnectionReuseStrategy is not really needed for the client side. It is a must for the server side HttpService, though. It is used on the server side to determine whether a connection can be used for subsequent requests or it should be dropped in order to delimiter the response content. Ok, then it remains in HttpCore. Should we cancel HTTPCORE-8 and reopen HTTPCORE-11? Redefine the objective of HTTCORE-8? Create a new issue? cheers, Roland - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: HttpCore connections
One more thing: if it can wait until Dec/Jan, I'll work on HttpConn. cheers, Roland - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: HttpCore NIO questions
Hi Oleg, We have to bear in mind that HttpCore is supposed to be useable without any other module. Moving default implementations for connections out of the core seems to clash with this goal. The default implementations should stay in HttpCore, but they should be (at least in my opinion) only implement a simple method allowing the connection to be bound to an open socket. Code aspects that define how exactly that socket gets initialized (directly or via a proxy) belongs to HttpConn in my opinion. This is just a proposal. If you object to such a change it will not happen. I don't feel well telling our users that HttpCore is useable by itself, but not giving them the infrastructure to open an SSL connection over a proxy (without authentication). Let me ponder this for a while. Opening a plain socket to an HTTP host or proxy is easily enough achieved using standard Java functionality. But that means that applications will have responsibilities on the socket level, while the API works on the HttpHost/ProxyHost level, and we'll have no way to ensure consistency. Maybe we can come up with a small module-conn for opening connections, while HttpConn deals with real connection management, that is pools of connections? cheers, Roland - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: HttpCore NIO questions
Hi Oleg, I believe strongly when it comes to libraries sometimes less is more. I very much rather prefer a library that does one thing and does it well to one that tries to be all sorts of things to all sorts of people. I agree. But I wonder how much connection opening is needed for HttpCore in order for it to work well. We cannot deliver a complete SSL tunneling solution in HttpCore without authentication, so probably we should not even try. Yes, I started to think along those lines when I wrote the last mail. Opening a plain socket to an HTTP host or proxy is easily enough achieved using standard Java functionality. But that means that applications will have responsibilities on the socket level, while the API works on the HttpHost/ProxyHost level, and we'll have no way to ensure consistency. They do not necessarily have to be consistent as HttpHost may well represent a virtual host, which does not directly correspond to the underlying physical socket. I do not see this as an issue. Maybe. Maybe HttpCore doesn't even have to know whether it is connected to a proxy or directly to a server. I need to think about this. Maybe we can come up with a small module-conn for opening connections, while HttpConn deals with real connection management, that is pools of connections? Then we rather keep this code in HttpCore base module, if you feel strongly about it. I don't feel strongly about it at this time. Let us step back for now and think things over. I definitely agree with that :-) Maybe others will throw in their ideas and opinions as well. That would be so welcome. I'm a bit tired of our stalemates with nobody joining the discussion to break the tie. Considering how often that happens, I am surprised about how much progress we're making :-) Two is a majority, as a friend of mine once observed. He was referring to a department of maybe 20 or 25 people. How many are on this mailing list? ;-) cheers, Roland - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SocketFactoryWrapper
Hi Mark, thanks a lot for this tip! We could add a wrapper class to the contrib section of HttpClient. Would you be willing to provide a patch? If you've attached some source code to your mail, it got stripped by the list server. The appropriate way to share code is to open a JIRA issue and attach a patch there. This will also record your approval to release the code under the terms of the APL. cheers, Roland - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Lessons Learned (was: HttpCore NIO questions)
Hi Oleg, everyone, it is a good and usually neglected practice to summarize and discuss the lessons learned during a project at some time. I planned to do that later this year, but since the opportunity presents itself, I'll do it now. The project in question is HttpAsync, or rather the client side thereof. I set out to contribute an API and initial implementation of HttpAsync last december. Since then, that has been the primary goal of my contributions to HttpComponents. When challenged with a task such as this at work, I would estimate an effort of about two weeks, excluding test cases. The result would not be as good as here due to the missing peer reviews - a lot of overdesigning and some smelly code. Still, within two weeks, I could deliver something that works and is a good starting point for improvements in the next iteration. Since I'm not developing for HttpComponents full time, let's translate the two weeks to 10 weekends. That's a net effort of about three months. Obviously, there were some points I did not take into account. First, I needed a lot more time than expected to familiarize myself with the environment. Setting up accounts, learning new tools, all that took quite some time. I'm still not finished, but I'm at least at a point where I am no longer having urgent issues with the environment. Next, I had to realize that the peer review process slowed me down considerably. It's not so much coming up with a modified patch after some feedback, but more the waiting for the feedback. If I create a patch on one weekend and put it up on Sunday, the review will have to wait until the following weekend, and the next iteration of the patch maybe until the weekend after that. Estimated effort 1 weekend, elapsed time 3 weekends. Even worse when Oleg and I disagree and multiple iterations are needed. One way to deal with this is to work on several isolated items in parallel. But HttpAsync is too narrow a codebase for that, and males are reportedly bad at multitasking anyway :-) Then, I expected about half of my weekends to be blocked by my lectures, while it was actually more like two thirds. And finally, I spent considerable time working on HttpComponents other than HttpAsync. So where is HttpAsync now? It's a pity, but HttpAsync is still at the same point where it was when we concluded the discussion about the threading design. When I entered a new coding phase several weeks back, I wanted to deal with HTTPASYNC-1 and HTTPASYNC-2: https://issues.apache.org/jira/browse/HTTPASYNC-1 https://issues.apache.org/jira/browse/HTTPASYNC-1 The idea was to get these things out of the way to prepare for another coding phase around christmas in which I wanted to tackle the real issues. Now the current coding phase is basically over, and I have not achieved a single item on my list. What's worse, I don't see the situation changing for the next coding phase around christmas. Maybe, just maybe, I'll get HTTPASYNC-1/2 finished then, and start thinking about the next step. Several months behind the revised plan, which is already several months behind the previous plan. Sure enough, I've achieved other things. We have a new Ant based build process, and a lot of work has gone into HTTPCORE-11 and some into HTTPCORE-8. These are important items, that's why I gave them priority over HttpAsync. It's not like I wasted my efforts. And still: my declared goal is to contribute HttpAsync, and I have not made any measurable progress towards that goal. With all the activities necessarily going on in HttpComponents, HttpAsync is constantly dangling at the end of my to-do list. Meanwhile, it is also a constant drag on my mind, and not only during the coding phases. And that's why I want it gone from my to-do list. I want to drive a stake through HttpAsync/CS, now. Let's revisit the ashes some time in the future, to see whether a phoenix is hiding in there. When the prerequisites are in place. With the HttpAsync monkey off my back, I can set new goals like improving the other components, and fixing the problems we meet on the way. Accomplishable short-term goals. Goals that allow me to see some progress. This way, I will get a little more satisfaction and a lot less frustration out of my activities. HttpAsync has not seen a single official release. There is no need to make any declarations. Fair enough. No official declaration needed. Whack! *puff* I have always been trying to say that controlled code duplication in HttpAsync is a lesser evil because it can shield HttpAsync from API instability in HttpCore. Go ahead and roll out an HttpAsync specific extension of HttpClientConnection interface and its default implementation. If I have to work on connection management code anyway, I prefer to do it for HttpConn. Let HttpAsync/CS rest in peace until the time is ripe for resurrection. cheers, Roland - To unsubscribe, e-mail: [EMAIL PROTECTED]
Re: Lessons Learned
Hi Oleg, I think you are over-reacting a little. Well, the frustration has been building up for quite a while. HttpComponents is just one of the things which I have to schedule, and right now there's a lot of them rushing at me. I need to make a cut at some point in time. First off, HttpComponents is a VERY small and unimportant project compared to many of its open-source peers. Such is the dynamics of a small-time open-source project: it is dog slow and boring. We just have to live with that. No one cares unless they are bitten by an annoying bug that directly affects their project. And to make matters worse, our flagship product HttpClient 3.x is not very buggy. Regarding HttpAsync, I'm not really bothered by the lack of additional contributors. I'm bother by my unability to deliver something that is rather clearly shaped in my mind and should not take long to implement. If there weren't popping up higher priority items left, right and center. Secondly, I felt HttpAsync was bound to hit a bumpy spot at some point of time because it lacked a clearly defined scope and a target user base. The functionality for the client side is rather clearly defined. Even if there is room for improvement using NIO and such: there's a few threads sending requests while a few others are receiving responses. I also expected a rough time waiting for users, but I expected that I could at least implement something that's useable. In time. I can't. I believe Apache Synapse expressed interest in an asynchronous HTTP client of a sort. Probably you should get in touch with those guys, see if they are still interested and get them articulate requirements for such a client. I don't see when I would be able to do something with those requirements. I know that I won't have time to do anything until December, and the items lining up so far have already taken months not to be implemented. I want to see HttpCore 4.0 alpha3 and HttpClient 4.0 alpha1 released first, at which point I want to take a serious look at HttpAsync. Let us re-focus for a little while. That's all. Agreed. I would expect the core alpha3 at the end of this year, and a client alpha 1 maybe next summer? There is no need for burials and resurrections. Well, then let's call it re-focussing for a little while. There is a russian proverb saying Call me a pot just do not put me in an oven ;-) When I am taking a break from a project, and I know that the break will last for many months, and I can't even give an estimate when it will be over, then I feel the need to express that this project is no longer under active development from my part. Without that, I would still feel responsible for working on it, and I would constantly feel bad about not making progress. I feel much better after saying: Whack! *puff* :-) cheers, Roland - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: HttpCore NIO questions
Hi Oleg,
I'll combine my responses in this mail.
AbstractIOReactor has code that deals with a server socket
channel. So it is exclusively server-side? If that is the case,
I would suggest a name change to AbstractServerIOReactor.
The SelectionKey.OP_CONNECT handling code will be added at some point.
I get it. If there is no server socket channel registered at the
selector, then key.isAcceptable() will never be true and no server
side code will ever be executed.
Was this document of any use at all?
http://wiki.apache.org/jakarta-httpclient/HttpCoreNioApi
Damn, I had forgotten about that. Yes, it would have been helpful :-(
[...HttpClientConnection.open() and where to put it...]
I _really_ would love to resolve this problem by simply moving the
extended connection interface and its default impl to the HttpClient
module
interface o.a.httpclient.HttpClientConnection
extends o.a.http.HttpClientConnection {
void open(...);
}
I hate having the same class/interface names in different packages.
I remember trying to override an initialization method that was given
a Properties argument. I failed miserably, until I realized that it
wasn't java.util.Properties but a project specific Properties class.
However, I understand you may want to use this interface in HttpAsync
We could start with an HttpConn module. The decision whether we'll
release it independently or only as part of HttpClient is still
pending, after all. See also below.
To make matters even worse we have the following feature request to take
care of:
https://issues.apache.org/jira/browse/HTTPCLIENT-475
This is yet another reason why I think there is no way around having a
HttpClient specific HTTP connection and connection management interfaces
and another motivating factor for me to reduce the connection management
code in HttpCore to an absolute minimum.
SocketFactory in HttpCore is very likely to be my next victim.
I am considering to officially declare HttpAsync defunct and pulling it
from the website. It was always caught between a rock and a hard place,
since it has to use HttpCore but also needs to provide functionality
for which (synchronous) APIs will only be discussed as part of HttpClient.
Now that we are even removing functionality from HttpCore, the work that
I would have to accomplish in order to make HttpAsync functional is
just piling up more and more. And whatever is put into HttpAsync now
will need to be reconsidered once we're working on the corresponding
part of HttpClient or one of the other modules. I can't help thinking
that any time spent on HttpAsync at this stage is wasted.
cheers,
Roland
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: HttpCore NIO questions
Hi Oleg, We could start with an HttpConn module. The decision whether we'll release it independently or only as part of HttpClient is still pending, after all. See also below. This is exactly what I see as a proper place for this kind of code We have to bear in mind that HttpCore is supposed to be useable without any other module. Moving default implementations for connections out of the core seems to clash with this goal. I am considering to officially declare HttpAsync defunct and pulling it from the website. [...] I disagree rather strongly. It is true that HttpAsync still lacks a clearly defined scope and it represents an experimental branch in HttpComponents development, but I certainly see HttpAsync as a very valuable and important development effort. I personally see it as a set of extensions to HttpCore and HttpClient targeted at those use cases where scalability and efficient thread management is a more important that raw performance delivered by blocking I/O. I also think it should be making an extensive use of NIO extensions to achieve those goals. I personally am very interested in working on an async equivalent of the HttpService class capable of handling a large number of high latency connections with a fixed number of threads. So, overall, it is very premature to declare HttpAsync as defunct. It may take a lower priority to delivering the first ALPHA of HttpClient 4.0, but it by no means a less interesting project. Well maybe not defunct, but at least suspended. The point is that most of the time I wanted to invest into implementing the pending changes to HttpAsync (client side) has gone into a new build process and redesigning connection handling in HttpCore, and now we're at a point where the HttpCore API is not even sufficient to implement HttpAsync/CS anymore. I'm tired of being delayed again and again. Every time I want to pick up on HttpAsync/CS development, I need to spend an hour with the code to even understand where I left it the last time. I'd rather call it quits until such time that the required base APIs are stabilized and I can concentrate on delivering HttpAsync/CS in one go. It's also fairer to the potential users to tell them that they have to wait for months, if not a year or so, until there's something to consider for use. Last December, I wrote that I hoped to contribute an initial implementation over the course of this year: http://mail-archives.apache.org/mod_mbox/jakarta-httpclient-dev/200512.mbox/[EMAIL PROTECTED] I am not much closer to this goal than at that time, and I don't see that changing for the coming months (6? 9? more?). Giving not only HttpCore but also HttpClient and related components a higher priority means that there will be none of my time left for the client part of HttpAsync that I wanted to contribute. And not giving them a higher priority would mean that I have to shoot at a moving target, spending considerable time to compensate for code changes in the base APIs, or to implement provisional versions of stuff that will most likely have to be rewritten completely later on. I consider my time too precious for that. It's better invested into HttpCore Co. Which means that HttpAsync/CS will lie dead until further notice. cheers, Roland - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Commented: (HTTPCORE-11)
Hi Oleg, All right. We pretty much agree to disagree for now. So it would seem :-) Could we at the very least remove these three methods from the HttpClientConnection interface? void setTargetHost(HttpHost targethost); InetAddress getLocalAddress(); void setLocalAddress(InetAddress localAddress); I'm fine with that. They were on my death list, too. (I have to take the time for a Kill Bill double feature one of these days :-) Are you going to replace the open() method with one that takes a target (and optional proxy) argument then? Opening without a way to specify the target would be pretty pointless. I can't promise, but I'll try to come up with a new version of the HTTPCORE-8 patch soon. One that includes my ideas on how NIO could be made to fit in. And it has to be soon, as the season of little time for OSS programming is about to start. cheers, Roland - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: HttpCore NIO questions
Hi Oleg, all my ideas about how to open a socket NIO style have gone down when I remembered the [Secure]SocketFactory. NIO socket opening is based on a SocketChannel and unconnected sockets. But the SocketFactory returns a Socket, and core-main is JDK 1.3 compatible while unconnected sockets were not introduced until JDK 1.4. I am giving up on suggesting anything here. cheers, Roland - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Commented: (HTTPCORE-11)
Hi Oleg, sorry, I didn't get the message before my departure. NIO based connections are not opened in the same sense as blocking connections, rather they are bound to an open socket (or IoSession in case of MINA) by an I/O reactor. I see. The socket is openend somewhere else and then attached to the connection later on. In other words asynchronous connections are not capable of opening themselves, hence my desire to get rid of the open() method in the generic interface, because it is too blocking I/O specific. And still, the opening of the socket has to be triggered somehow, and the information where the socket is supposed to point to should be made available too. Even though the connection can not open itself, it can provide the target information, set a trigger, and block the calling thread until the I/O reactor has bound a socket to it. Similar to what is done for receiveResponseHeader and receiveResponseEntity in the NIO data receiver, if I am not mistaken? UnsupportedOperationException is certainly an option, but should be the last resort in my opinion. Agreed. Actually I think HttpClientConnection and HttpServerConnection are not very good names for those interfaces. I would prefer those interfaces to be renamed to HttpOutgoingConnection and HttpIncomingConnection. I don't like these names. Connections are bidirectional, it's only the way of establishing connections that distinguishes a connection on a (client) socket from that on a server socket. At least that's what I keep telling my students once a year :-) I have no problem with the client/server in the name, because of the association with server sockets. Also, the association to the client and server side of an HTTP communication is obvious. But I don't mind searching for better names. My first ideas are not really suitable, because they are too long for my liking: HttpInitiatingConnection and HttpAcceptingConnection. And I'm sure you don't like the initiating, because it implies that the connection is actively establishing itself, rather than waiting to be bound :-) If do not object to such a change, would you mind if I spit the interface into HttpOutgoingConnection (sans #open()) and HttpClientConnection for the time being, so I could go ahead with my work on NIO extensions? I would prefer if you used the UnsupportedOperationException for the time being. cheers, Roland - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (HTTPCLIENT-600) Http Client does not fix incorrect content-lenght headers
[
http://issues.apache.org/jira/browse/HTTPCLIENT-600?page=comments#action_12434986
]
Roland Weber commented on HTTPCLIENT-600:
-
Hello Denis,
we won't add a String-to-int conversion (with exception handling for invalid
numbers) just to generate a warning.
Besides, we had other users complaining about warnings that were generated
about something they wanted
to do on purpose. Again: if you want the content length to be verified, please
implement that in your application.
cheers,
Roland
Http Client does not fix incorrect content-lenght headers
-
Key: HTTPCLIENT-600
URL: http://issues.apache.org/jira/browse/HTTPCLIENT-600
Project: HttpComponents HttpClient
Issue Type: Improvement
Components: HttpClient
Affects Versions: 3.1 Alpha 1
Environment: All
Reporter: Denis Valdenaire
I discovered that the method
addContentLengthRequestHeader (found in file
methods/MultipartPostMethod.java) doesn't fix the content-lenght when this
one is incorrect. It adds one if getRequestHeader(Content-Lenght) is null,
but it should also verify that the content-lenght is correct.
I suggest something like :
long len = getRequestContentLength();
if (getRequestHeader(Content-Length) == null ||
getRequestHeader(Content-Length) != len) {
setRequestHeader(Content-Length, String.valueOf(len));
}
Sending an incorrect Content-Length blocks the server if the string sent is
smaller than announced : waiting for more, and finally reset the connection.
If it's too big, you lose data.
I've seen this problem in a reverse proxy program (with httpclient
communicating with the real servers) when the client send urlencoded data and
this data is modified (partly urldecoded) but not the content-lenght.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Commented: (HTTPCORE-11)
Hi Oleg, I'm confident we can find an interface that serves the need of both NIO and Async without this ugly split. Maybe you can explain how you want to open connections in the NIO case? Like in the examples, let the application open the socket synchronously and then simply use it in the NIO classes? Or will there be an open call that just triggers an operation which completes only later? Could we use the trick from the transmitter and receiver, where the thread calling the operation is blocked until the background thread has done the work? Would it help to redeclare open as an operation that may complete asynchronously? Setting the target and/or proxy host can be done immediately, and the meaning of isOpen() could be changed, or an extra state can be introduced. Or we declare open an optional operation that can throw an UnsupportedOperationException, like Iterator.remove(). If it isn't called anyway, what does it matter if it's there? cheers, Roland - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (HTTPCORE-11) Provide generic server and client connection primitives that can work with arbitrary HTTP data receivers and transmitters.
[ http://issues.apache.org/jira/browse/HTTPCORE-11?page=comments#action_12433492 ] Roland Weber commented on HTTPCORE-11: -- Hi Oleg, the absence of an open(...) method in HttpClientConnection means that HttpAsync can no longer use the interface, but has to reference an implementation class or an extended interface. This could only be acceptable as a short-term intermediate step until we re-introduce some version of open(...) with HTTPCORE-8. I'm not sure there is a point in going this intermediate step, but since I won't find time to fix HttpAsync for another week, it doesn't matter much. The question really is whether I can fix HttpAsync before or after we've found a solution to HTTPCORE-8. cheers, Roland Provide generic server and client connection primitives that can work with arbitrary HTTP data receivers and transmitters. -- Key: HTTPCORE-11 URL: http://issues.apache.org/jira/browse/HTTPCORE-11 Project: HttpComponents Core Issue Type: Improvement Components: HttpCore Affects Versions: 4.0-alpha2 Reporter: Oleg Kalnichevski Assigned To: Oleg Kalnichevski Fix For: 4.0-alpha3 Attachments: conn.patch, httpclientconn-2.patch, httpclientconn.patch, httpcore-abstractconn.patch Provide generic server and client connection primitives that can work with arbitrary HTTP data receivers and transmitters. The default connection primitives in their present form are tightly coupled with the java.net.Socket class. There are cases when the underlying I/O transport is based on different media (MINA transport, NIO channels) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (HTTPCORE-11) Provide generic server and client connection primitives that can work with arbitrary HTTP data receivers and transmitters.
[ http://issues.apache.org/jira/browse/HTTPCORE-11?page=comments#action_12433177 ] Roland Weber commented on HTTPCORE-11: -- Hi Oleg, (1) passing HttpContext as parameter is fine. The further it spreads, the better I like it. Removing the connection argument is also fine. (2) I'm not so sure about. It's something that might be useful for HttpAsync, and I think it's a bit early to introduce a dependency on HttpClient there. Let me think about this for a while. cheers, Roland Provide generic server and client connection primitives that can work with arbitrary HTTP data receivers and transmitters. -- Key: HTTPCORE-11 URL: http://issues.apache.org/jira/browse/HTTPCORE-11 Project: HttpComponents Core Issue Type: Improvement Components: HttpCore Affects Versions: 4.0-alpha2 Reporter: Oleg Kalnichevski Assigned To: Oleg Kalnichevski Fix For: 4.0-alpha3 Attachments: conn.patch, httpclientconn.patch, httpcore-abstractconn.patch Provide generic server and client connection primitives that can work with arbitrary HTTP data receivers and transmitters. The default connection primitives in their present form are tightly coupled with the java.net.Socket class. There are cases when the underlying I/O transport is based on different media (MINA transport, NIO channels) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: help using client certificate
Hello Zohar, I'm trying to connect to a server using HTTPS. The server requires a client certificate. I was given a p12 file for the certificate and a password. Can anyone point me to an example of doing this please? That's basically the same question I answered yesterday on the user list: http://mail-archives.apache.org/mod_mbox/jakarta-httpclient-user/200609.mbox/[EMAIL PROTECTED] hope that helps, Roland - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (HTTPCORE-11) Provide generic server and client connection primitives that can work with arbitrary HTTP data receivers and transmitters.
[ http://issues.apache.org/jira/browse/HTTPCORE-11?page=comments#action_12432865 ] Roland Weber commented on HTTPCORE-11: -- Hi Oleg, the changes to HttpRequestExecutor break HttpAsync, but that was to be expected. Go ahead, and I'll take care of HttpAsync one of these days. It was on my list anyway :-) cheers, Roland Provide generic server and client connection primitives that can work with arbitrary HTTP data receivers and transmitters. -- Key: HTTPCORE-11 URL: http://issues.apache.org/jira/browse/HTTPCORE-11 Project: HttpComponents Core Issue Type: Improvement Components: HttpCore Affects Versions: 4.0-alpha2 Reporter: Oleg Kalnichevski Assigned To: Oleg Kalnichevski Fix For: 4.0-alpha3 Attachments: conn.patch, httpclientconn.patch, httpcore-abstractconn.patch Provide generic server and client connection primitives that can work with arbitrary HTTP data receivers and transmitters. The default connection primitives in their present form are tightly coupled with the java.net.Socket class. There are cases when the underlying I/O transport is based on different media (MINA transport, NIO channels) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Updated: (HTTPCORE-11) [3rd patch]
Hi Oleg, I may not have fully grasped the concept but I felt the proposed solution would not work well with NIO where the process of establishing a connection was non-blocking. I'm not sure how that works. The connection factory in your previous patch would also return a connection object, right? And yes, it is kinda complex ;-) Sorry, I couldn't think of an easier way :-) So, my intention was to remove all methods from HttpClientConnection interface that have to do with connection initialization, provide a simple mechanism to bind the default HttpClientConnection impl to an arbitrary socket and then deal with HTTPCORE-8 The idea of the patch in HTTPCORE-8 was to keep all connection init methods in the connection interface, but route them to the operator which gets exclusive internal access to the container object. I was really just trying to refactor the code for opening and closing sockets out of the connection. But the operator is nonetheless exposed through the HttpClientConnection interface, right? It is exposed as getter and setter, yes. But there are currently no methods in the operator that could be called directly. The getter/setter is intended mainly to change the operator while the connection is closed. And of course to initialize the container object after creation. I think Spring relies on getters and setters? ;-) So, every HTTP client connection would have to implement it even though not every kind of connection is capable of re-opening itself? It is only _suggested_ that reopening _tries_ to re-use the socket. It is perfectly acceptable that the operator simply closes the socket and creates a new one in response to the re-open call. That much should be supported by every container for a socket :-) Connections don't implement an operator, they are provided with one. It's supposed to be a mix-and-match relation between the two, unless somebody implements an operator that needs additional attributes in the connection. That operator would need to provide an extended connection implementation. Still, I don't know what implications that has regarding NIO. Maybe you can write a paragraph or two how a connection will be openend asynchronously, and how that will be synchronized with the operation of the application thread? cheers, Roland - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Updated: (HTTPCORE-11) [3rd patch]
Hi Oleg, I had a quick look and will share my initial thoughts here. Maybe I'll think differently after chewing on this for a while. Or maybe you can add some ideas of yours in response. (1) agreed. I hadn't seen that point before. (2) A connection manager (and/or operator) is responsible for more than one connection. Per-connection information is best kept with the connection itself. I don't see why the information shouldn't be publicly accessible in a read-only fashion. It allows for the implementation of strategies that are not tied to a specific connection manager (or whatever) implementation. Such as don't keep connections to host XYZ alive. (3) agreed Two weeks ago we discussed turning the connections into simple containers that don't know how to establish a connection. While your patch does achieve that, it also effectively turns connections into throw-away objects. On first thought, I don't like it because of a gut feeling. On second thought I don't like it because SimpleHttpDispatcher assumes to have *one* connection which can be pointed to different targets one after another. It's probably not hard to change, but throw-away connection objects clash with every thought about connection management I've ever had so far. cheers, Roland - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Updated: (HTTPCORE-11) [3rd patch]
Hi Oleg, I certainly do not have a problem with exposing the target host through the HttpClientConnection interface. We just have to make sure that HttpClientConnection cannot be (easily) put into an inconsistent state where the target host does not correspond to the remote address of the underlying socket. Agreed. The trouble is that I would not want the HttpClientConnection interface to be directly coupled with java.net.Socket. At the same time I cannot think of an elegant way to re-attach the existing client connection to a new network socket. Let us think it over. So you think the solution I proposed with HTTPCORE-8 is not elegant. I admit that it is slightly complex, but the objects have very well defined responsibilities. I would also prefer a solution where the calls to the operator do not have to be routed through the connection, but it somehow matches the telephone analogy :-) I am aware of two options for giving exclusive access to some of the methods. The first one is what I've done in HTTPCORE-8: use an extra callback object that is passed only to an entitled caller. The other one is based on passing a secret ticket object to restricted calls, which must have been set previously when the state became locked. Then only the owner of the secret can perform modifications. For the connections, I like the first solution better since it does not pollute the connection interface. The user of the connection does not even have to be aware of the connection/operator interaction. cheers, Roland - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [HttpCore] NIO extensions (first take) are ready for review
Hi Oleg, Sure. Some people just insist on being able to write directly to the output stream. I want to demonstrate that this is possible with the HttpCore API. I am not trying to say this approach is any better than using StringEntity. Ok, then it is just the example which I don't like :-) Now the Evil Plan (TM) is to start working on a asynchronous version of HttpService that decouples the process of receiving HTTP requests, generating response content and sending off resultant HTTP responses using a fixed pool of worker threads. I am not sure how exactly this is going to work (if at all) but I want to keep this idea on the back burner for some while. Sounds pretty much like what I'm heading to on the client side with HttpDispatcher. Sooner or later (I'm afraid later) I'll reach the point where I have to look into NIO in order to avoid having one worker thread per connection just to detect incoming responses. Lifting NIO up to the API itself would probably require rewriting half of HttpCore. There's no point in thinking about that until we have much more contributors. cheers, Roland - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Status of HttpAsync
Hi Oleg, I would like to contribute a server side HTTP processor, which can deal with a large amount of idle or high latency connections. I'll send a detailed proposal about it some time this month (depending on my workload with the day-time job). Sounds good. We've had so many people confuse async with NIO that it's probably time to put some NIO stuff into HttpAsync. I wonder whether I should change my email address to http-background. And we have to get rid of this stupid AsyncHttpProcessor one of these days :-) cheers, Roland - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [HttpCore] NIO extensions (first take) are ready for review
Hi Oleg,
here are a few comments, though they have little to do with NIO.
- the examples and at least some of the implementation classes
are missing the Apache copyright notice in the source files
- I still don't like the duplication of methods in IOSession
and HttpContext. The only reason I can see for not deriving
IOSession from HttpContext are the constants defined there.
Maybe we should separate declaration of the methods from
definition of the constants. Factor out the methods to a new
interface o.a.h.util.Attributable, derive both HttpContext
and IOSession from there?
- I will have to update build files so that the examples are
compiled and javadoced.
- The way you are using EntityTemplate in the examples,
I don't see the advantage over a StringEntity. For example:
EntityTemplate body = new EntityTemplate(new ContentProducer() {
public void writeTo(final OutputStream outstream)
throws IOException {
OutputStreamWriter writer =
new OutputStreamWriter(outstream, UTF-8);
writer.write(htmlbodyh1);
writer.write(File );
writer.write(file.getPath());
writer.write( not found);
writer.write(/h1/body/html);
writer.flush();
}
});
can be replaced by
StringEntity body =
new StringEntity(htmlbodyh1 +
File +file.getPath()+ not found +
/h1/body/html,
UTF-8);
which is just as readable and doesn't need an inner class.
The main problem I had with understanding your NIO activities
is now solved. I was always wondering how you were going to
expose the channels at the entities so applications can use
NIO features. From what I've seen now, you just don't.
Applications continue to use blocking streams, which are then
mapped to channels. Doesn't that mean that the context switches
you want to avoid are just moved from the general IO operations
to the NIO receiver/transmitter?
cheers,
Roland
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (HTTPCORE-11) Provide generic server and client connection primitives that can work with arbitrary HTTP data receivers and transmitters.
[
http://issues.apache.org/jira/browse/HTTPCORE-11?page=comments#action_12432368
]
Roland Weber commented on HTTPCORE-11:
--
Hi Oleg,
I guess I'll never ever be able to apply a patch without some kind of problem.
The patch tool didn't like the removed class, obviously because of expanded
$Revision$ and other tags. I deleted the class manually. What did the
subversion guys think when they implemented svn diff without a matching svn
patch?
The patch looks good by itself, but it raises some questions regarding
HTTPCORE-8. Most of them can be discussed as part of HTTPCORE-8, but there is
one thing I'd like to mention at this time: the class names. HTTPCORE-8 and
this patch both define an AbstractHttpClientConnection class. In HTTPCORE-8,
the class implements only the logic mandated by the interface, here it also
adds the receiver/transmitter/(de)serializer objects for our default
implementation.
I would not like to have both kinds of code in the same class. Think of an
embedded system where someone decides to implement the receive/transmit logic
in native code. The logic from HTTPCORE-8 would still be useful, but the
receiver/transmitter/(de)serializers would not. How do you think about renaming
the classes here to {Base|Basic}Http{Client|Server}Connection? Factoring out
the code mandated by the interface into AbstractHttp{Client|Server}Connection
could be done with HTTPCORE-8.
cheers,
Roland
Provide generic server and client connection primitives that can work with
arbitrary HTTP data receivers and transmitters.
--
Key: HTTPCORE-11
URL: http://issues.apache.org/jira/browse/HTTPCORE-11
Project: HttpComponents Core
Issue Type: Improvement
Components: HttpCore
Affects Versions: 4.0-alpha2
Reporter: Oleg Kalnichevski
Assigned To: Oleg Kalnichevski
Fix For: 4.0-alpha3
Attachments: conn.patch, httpcore-abstractconn.patch
Provide generic server and client connection primitives that can work with
arbitrary HTTP data receivers and transmitters. The default connection
primitives in their present form are tightly coupled with the java.net.Socket
class. There are cases when the underlying I/O transport is based on
different media (MINA transport, NIO channels)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Status of HttpAsync
Hello Asankha, I am from the Apache Synapse team, and would like to use HttpAsync in Apache Synapse as a non blocking HTTP client. However there doesn't seem to be any releases of HttpAsync yet on the maven repos. Could someone let me know the timelines when this would be made available.. I'm afraid we're still a long way from something I would consider release quality code. Even alpha. HttpAsync lacks in both functionality and tests. I wanted to work a little on it the last few weeks, but there were changes in HttpCore that simply have a higher priority at this time. Now autumn is coming near, which means I'll have to spend lots of my private time on preparing a lecture I'm teaching. Unlike in summer, I don't plan to cut HttpAsync development down to zero. Still, I don't expect major improvements until the end of my christmas holidays. Mid-January maybe. Whether that will be release quality is a different question. Of course things will change if other developers join the project :-) Suggestions, for example a list of requirements (and priorities?), would be very welcome, too. cheers, Roland - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [HttpComponents] Rename dev and commits lists?
Hi Oleg, How do you feel about renaming the httpclient-dev and httpclient-commits lists to httpcomponents-dev and httpcomponents-commits to reflect the new project scope. Sounds good. I am still not sure what to do about the user list. Shall we keep the httpclient list as is and create a new one for HttpComponents? That's probably the best. Current subscribers won't see a change, and new users of HttpClient won't have to figure out that they have to join the HttpComponents list. It will also be fun to see traffic on the HttpComponents list pick up over time, while that on the HttpClient list goes down. And then, finally, that moment of joy when we declare HttpClient as unsupported and shut the old list down... wanna take bets on when that will be? :-) cheers, Roland - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (HTTPASYNC-5) improve Ant based build targets
[ http://issues.apache.org/jira/browse/HTTPASYNC-5?page=all ] Roland Weber closed HTTPASYNC-5. Resolution: Fixed Hi Oleg, thanks for reviewing. The javadoc-src target should generate JavaDocs for both API and implementation, it just groups the overview in two different sections. I just verified that behavior for HttpCore. HttpAsync has a bug, javadoc-src will generate the same output as javadoc-addon there. I'll fix HttpAsync some time tomorrow. A new build for HttpClient will follow after HttpClient is back in the project-trunk. Closing this issue, as the bulk of the work is completed. cheers, Roland improve Ant based build targets --- Key: HTTPASYNC-5 URL: http://issues.apache.org/jira/browse/HTTPASYNC-5 Project: HttpComponents Async Issue Type: Improvement Components: HttpAsync Reporter: Roland Weber Assigned To: Roland Weber Priority: Minor Attachments: 2k6-08-13-async-build-3.tar, 2k6-08-20-core-build-4.tar The Ant based build targets have some annoying peculiarities, like - JavaDoc target depends on compilation target - no compilation/package target for contrib code - main, contrib and test sources are all compiled into same class tree -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Created: (HTTPCORE-8) refactor HttpClientConnection and HttpProxyConnection
Hi all, any comments on this one? The implementation classes of the patch no longer compile after the changes to HttpCore, but I'd like to get some feedback on the API before I work on the next version. cheers, Roland - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Created: (HTTPCORE-8) refactor HttpClientConnection and HttpProxyConnection
Hi Oleg, I looked at the patch and have a few comments. But I would like to get HTTPCORE-11 [1] resolved first, because it blocked the resolution of HTTPCORE-8. Ok, I'll have a look at it tomorrow. cheers, Roland - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [HttpCore] NIO extensions: progress report
Hi Oleg, At this point of time I tend to think NIO on the client side makes no sense at all, as it makes little sense for an HTTP client to keep hundreds of connections open. I agree. Server-side use will also be confined to very special purposes, as common server-side APIs like Servlet API and Portlet API are based on traditional IO. But special purpose server applications is just the niche where HttpComponents can shine. No need to review the NIO code. Just take a look at the public API and let me know if it feels okay. Ok, I'll find time for that. I do not expect any changes in the HttpServerConnection. It is the client side of the story that needs work. Once we have stabilized a new design on the client side, we should at least consider to restructure the server side based on the same principle. Implementation classes at least - AbstractHttpConnection will loose it's purpose, I'm afraid. I'll start checking in classes, which I have a certain degree of confidence in not being completely wrong. Go ahead. I'll let you know about JavaDoc warnings :-) cheers, Roland - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r437358
Hi Oleg, just a few minor observations: EventMask: unless you're going to add more, this should either be an interface or have the default constructor disabled. IOSession: the get/set/removeAttribute methods look exactly like those in HttpContext. Derive the session from the context? No JavaDoc warnings ;-) cheers, Roland - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r434476
Hi Ryan, To whomever it may concern, If you use an cool little IDE like Eclipse, they have excellent code formatting in 3.2 version making the nuances of code formatting completely trivial, you can configure pretty much any aspect of formatting code. I have stated my view on IDEs on other occasions. I think they are way less cool than you think they are. My Emacs is perfectly capable of indenting code, and that's all I want it to do. What I heard about automatic formatting of Eclipse based tools is that they have problems with fully qualified classnames at the line end: ... x instanceof fully. qualified. series. of. packages. before. ClassName)... Ever since this invention, i no longer spend even more than 2 seconds on code formatting issues. I just right click src format and it does the whole code tree. I usually do a src format once a month to clean out the cobwebs. If that's good enough for you. I expect code to be readable whenever I look at it, whether it's during development or when looking up something because of a user question. I've taught Emacs my preferred indenting style years ago. I had to adjust indentation for HttpClient, since we're using a different style here. But I sure won't swap my editor which has served my well since 15 years for an IDE. The main reason why I loathe IDEs - besides them not integrating Emacs - is that I have observed too much sloppiness about those things that the IDE makes seemingly easy. Indentation is just one example, build process another. Studying of documentation vs. automatic expansion of method names; generating bad code because it's so easy to refactor later (which hardly anyone actually does)... don't get me started! ;-) You know something's wrong with your development process when code is exchanged between developers by copying full projects using a USB stick instead of checking files in and out of a source code repository. Oh how they were jealous about my 512 MB stick, while they had 64 MB sticks on which only a single project would fit. cheers, Roland - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (HTTPCORE-8) refactor HttpClientConnection and HttpProxyConnection
refactor HttpClientConnection and HttpProxyConnection - Key: HTTPCORE-8 URL: http://issues.apache.org/jira/browse/HTTPCORE-8 Project: HttpComponents Core Issue Type: Improvement Components: HttpCore Affects Versions: 4.0-alpha3 Reporter: Roland Weber Assigned To: Roland Weber As discussed on the mailing list, separating the responsibility for establishing connections from the connection objects could improve the design and help with proxy support. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (HTTPCORE-8) refactor HttpClientConnection and HttpProxyConnection
[ http://issues.apache.org/jira/browse/HTTPCORE-8?page=all ] Roland Weber updated HTTPCORE-8: Attachment: 2k6-08-25-core-conn-1.tar Take 1 on alternative connection interfaces. Note that this is a tar, not a patch. I have used class and interface names that do not collide with existing ones. The idea is to have a few review cycles on the new interface before I have to modify all code that uses connections. Even so it took several hours longer than I had expected for a first draft. All classes and interfaces spelled connexion are supposed to be renamed to connection. (Did you know that connexion is an oldfashioned but correct british spelling?) The code in the default implementation classes is copied and pasted from existing implementations. They compile and javadoc, but they have not been tested. The general idea is to turn the connection into a simple container for a socket and associated objects. The logic for creating the socket, that is for establishing the connection, is moved to an operator (as in switchboard). The tricky part is that the operator must be able to modify the connection's state in ways that should not be available to an application developer. In order to achieve this, I have defined a third interface with internal operations that are only exposed to the operator. Here is a list of the new interfaces and classes: HttpClientConnexion - container for the connection, replaces HttpClientConnection and HttpProxyConnection. Knows it's operator and delegates calls such as open and close there. HttpClientConnInternal - internal operations for the connection. An instance of this interface is passed to the operator whenever the connection delegates a call there. HttpClientConnOperator - provides logic for opening and closing connections, uses the connection internal operations AbstractHttpClientConnection - defines all attributes mandated by the HttpClientConnexion and HttpClientConnInternal interfaces and implements the delegation to the operator. Internal operations are implemented by an inner class. Derived classes can focus on send/receive operations. impl.DefaultHttpClientConnexion - implements send/receive logic mostly copied over from DefaultHttpClientConnection and AbstractHttpConnection. impl.DefaultHttpClientConnOperator - implements socket creation logic mostly copied over from DefaultHttpClientConnection and DefaultHttpProxyConnection, and close/shutdown logic copied over from AbstractHttpConnection. I had some trouble in assigning the responsibility for the stale connection check (fallback implementation in DHCCOperator, better implementation in DHCConnexion) and the response availability check (connection, for now). The hooks that allow for the connection to create receiver/transmitter objects after the socket has been created by the operator need improvement. Anyway, you'll get the idea, and I have already spent three evenings with this. Please let me know what you think. I may find time for minor revisions this weekend, everything else must wait at least one week, probably two. cheers, Roland refactor HttpClientConnection and HttpProxyConnection - Key: HTTPCORE-8 URL: http://issues.apache.org/jira/browse/HTTPCORE-8 Project: HttpComponents Core Issue Type: Improvement Components: HttpCore Affects Versions: 4.0-alpha3 Reporter: Roland Weber Assigned To: Roland Weber Attachments: 2k6-08-25-core-conn-1.tar As discussed on the mailing list, separating the responsibility for establishing connections from the connection objects could improve the design and help with proxy support. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: GZIP Response
Hi B K, to return the inputstream. I now have a requirement to determine how large the compressed response is(to determine bandwidth usage), as the server is not returning content-length I thought I would do the following create a string buffer create a buffered reader for getResponseBodyAsStream() read the response and append to my string buffer As Robert pointed out, you have issues with character vs binary data and you are clogging memory with this approach. Instead of just wrapping the GZIPInputStream, you can implement your own wrapper stream that counts the number of bytes being read, then wrap the GZIPInputStream on top of that. Use java.io.FilterInputStream as a starting point and override all read() and skip() methods to count the number of bytes. hope that helps, Roland - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r434476
Hi Oleg, In this particular case, though, I think declaring an interface method public does not bring anything. All methods in an interface are public and public only. Is there a particular reason you want methods in this interface explicitly declared public? I find interfaces without public declarations a _little_ more readable than with. I don't like to have two different ways of declaring method signatures, and having to decide which one is appropriate. In this particular case, I copied and pasted the signature from the interface into the class in which I wanted to implement it, and it was wrong because of the missing public declaration which I had to substitute. It is quite common for me to paste signatures from interfaces into implementation classes. But since you are the lead developer, I'll refrain from adding public to (non-async) interfaces in the future. The new connection interfaces I am currently prototyping will have the public declaration, though. BTW, many thanks for cleaning up Javadocs. I, for one, owe you a lot for doing it. You're welcome. cheers, Roland - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r434476
Hi Oleg, There are no lead developers here. This is no I have a bigger title, I deserve a bigger bonus corporate shit. Your vote means as much as mine, so does your opinion. Please leave public declarations be if you find them useful. It's not corporate shit, but still: the more you contribute, the higher is your status in an open source community. It's a fact that you have put by far the most work into the HttpComponents code base, and that you are likely to continue to do so for the forseeable future. So there is no point in inconveniencing you often instead of inconveniencing me rarely. I'll leave the public declarations in the interface I already changed, but I won't add any more in the future. cheers, Roland - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r434476
Hi Julius, +1 to Oleg, because it shows excellent knowledge of Java language, and is certainly a little more readable, especially with those long method names that go beyond 80 columns. +1 to Roland, though, because when I implement the interface, I have weird habits and I always just copy paste from the interface, and then I get annoyed that I have to remember to add the public in my concrete class. To make the confusion complete: I am adding the public although I'm using an editor in 80 column mode. The trick is to add line breaks in places where they do not irritate the syntax highlighting :-) public final static Object createObject(String arg1, Map arg2) throws Exception But even so, when long class names of the return value _and_ an argument team up with a long method name, there's nothing I can do anymore... cheers, Roland - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: HttpClient-HttpComponents relationship
Hi Robert, Robert Olofsson wrote: Roland Weber wrote: BTW, I need to asynchronously get a lot of URLs (using pipelining if posible), HTTPAsync seems the right thing to use, but everybody points at HTTPClient. What do I do? Sorry to say, but HttpAsync is in a very early stage of development. If you need async handling more than you need HttpClient there may be some alternatives that you can look at. I suspect that you will have to modify them to suit your needs though. Thanks for the information. But I don't need HttpAsync, I'm developing it :-) Notice my email address? ;-) cheers, Roland - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Response Content Error
Hello Tom, FINE Accept-Encoding: gzip, deflate[\r][\n] HttpClient does not and will not support content compression. If you decide to send an Accept-Encoding header, then your application should be prepared to deal with compressed responses. Otherwise, don't send that header. See section 5.5 of the primer, last paragraph: http://wiki.apache.org/jakarta-httpclient/ForAbsoluteBeginners#head-8ce973d0347a2eba238f594c47f478035c51ea66 cheers, Roland - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Response Content Error
Hi Tom, I was trying to send the exact headers that my Web Browser sends when it connects to the site. The Client HTTP Programming Primer describes exactly the scenario of emulating browser behavior. You should read it to avoid those obvious pitfalls. http://wiki.apache.org/jakarta-httpclient/ForAbsoluteBeginners cheers, Roland - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: HttpClient-HttpComponents relationship
Hello Nicolas, BTW, I need to asynchronously get a lot of URLs (using pipelining if posible), HTTPAsync seems the right thing to use, but everybody points at HTTPClient. What do I do? Sorry to say, but HttpAsync is in a very early stage of development. My progress this year was much slower than I had hoped for. If you want to use something now, you can use the stable HttpClient 3.x or go with the HttpCore 4.0 alpha. Neither provides built-in pipelining support. We have refactored the connections in HttpCore to the point that they can be used for pipelining, so if you're willing to handle the gory details of multithreading and of request dispatching and of associating the incoming responses with the correct requests, you're welcome. We wouldn't mind some feedback on our code either. If I should make good progress, we may have a SimplePipeliningDispatcher over a single connection in a few months. But so far, progress was always slower then I had hoped for, and work on HttpCore has a higher priority than on HttpAsync. The SimpleHttpDispatcher is already asynchronous, but not pipelining. It will see a little refactoring and configurability soon. You could use it with multiple instances if you're prepared to do the request dispatching across the instances yourself. The upgrade path to the simple pipelining version would be smooth, but you have to expect API changes. HttpAsync is still a long way even from alpha. And I don't expect to have a non-simple dispatcher, that is one that uses more than one connection, ready this year. cheers, Roland - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [HttpCore] Proxy Support
Hi Oleg, Then we have to factor out the code to establish the connection and turn the connection into a simple container for the socket, which is filled from the outside. Actually this is something we should seriously consider. Ok, I'll ponder it for some sleepless nights or such :-) Regarding the responsibilities of connections and connection managers, my idea was to let the connection decide whether it is pointing to the target, and if it does the connection manager (or dispatcher) can ask the connection reuse strategy whether to keep it alive or not. Or something along that line. Maybe this is the right way to go for HttpAsync but I am not sure this is the case for HttpClient. Can you develop this code inside HttpAsync first and then we can decide whether it should be moved over to HttpCore. I don't insist on putting it into the connection, I just want to have it in some place where it's reusable. I'll keep the stuff in HttpAsync by extending some core interface or defining a new one. Can you look into decoupling the process of establishing a connection from the HttpClientConnection interface, if you happen to have some spare cycles left? I am stuck neck deep in my day job and NIO stuff and will have no time to look at HttpClientConnection until the first cut at HttpCore NIO extensions is complete. I can't promise this weekend, nor next. I'm on a business trip again next week. I'll keep thinking about it, and will come up with some ideas eventually. But I also want to get a few lines done on HttpAsync, especially now that somebody expressed interest :-) cheers, Roland - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [HttpCore] Proxy Support
Hi Oleg, Being proxied or not is a runtime property, and can not be reflected in the class hierarchy. I am not sure I agree with that. From the RFC 2616 standpoint there is no difference between proxied and plain client HTTP connection. I think this may be a rectangle vs. square problem. Mathematically, every square is a rectangle. Still, it's not a good idea to derive a square class from a rectangle class :-) (unless it is read-only) RFC 2616 considers connections as something to send data over. But our connection objects are more, since they include the logic to establish the connection. Having connection objects that only know how to establish a plain connection, and others that know how to tunnel over a proxy sounds wrong to me. The connection itself should not be aware of this distinction. Then we have to factor out the code to establish the connection and turn the connection into a simple container for the socket, which is filled from the outside. The special case is not connection proxying but rather connection tunneling. My first knee-jerk reaction was to put all the tunneling code into a separate super class I think inheritance is the problem, not the solution here. If it is proxied without (real) tunnelling, it can be kept alive even if the next request is going to a different target host but through the same proxy. Presently this is one of deficiencies of HttpClient 3.x (MTHCM to be exact). We definitely should try to make HttpClient 4.0 a bit smarter about pooling proxied connections. OK. Will be tough though. I've taken a look at MTHCM recently. It's massive. I believe that the connection itself would be a good place to implement the logic for deciding whether it is pointing correctly. I rather lean toward keeping this kind of logic in a connection manager, but am open to consider alternative approaches. In my opinion the job of connection is to shove around HTTP messages, whereas the decision about re-usability of connections should be left up to a connection manager My problem is that I don't want to make HttpAsync dependent on a connection manager. If you have a look at the open issues I have created for HttpAsync, you'll notice that it needs a completely different connection management interface. I've already pushed that to a future release, to reduce the bulk of work to a more manageable size. In fact, I had a very bad day a few weeks ago when thinking about HttpAsync, and pushing connection management to a future release was the one thing that helped me get over that mood. Regarding the responsibilities of connections and connection managers, my idea was to let the connection decide whether it is pointing to the target, and if it does the connection manager (or dispatcher) can ask the connection reuse strategy whether to keep it alive or not. Or something along that line. A minor detail is that only the HttpProxyConnection has an isSecure() method. A non-proxied connection can be secure, too :-) Another minor detail is the ProxyHost class, which is not used anywhere in the API, but only by the DefaultHttpProxyConnection. I'm not sure whether it adds any value. Let's fix it. OK. I'll try to come up with a patch this week. My suggestion would be to port MTHCM to the new API, hack up a very simple HttpClient prototype (no cookies, no authentication, no redirects) and see if we end up with some generic aspects that may prove useful in HttpAsync or HttpCore. It may be a little easier to observe commonalities rather than trying to 'guest' them. Do we need MTHCM for the proxy part? cheers, Roland - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (HTTPASYNC-5) improve Ant based build targets
[ http://issues.apache.org/jira/browse/HTTPASYNC-5?page=comments#action_12429512 ] Roland Weber commented on HTTPASYNC-5: -- When called from the main build file, compile.source and compile.target can only be set for all modules. I'll have to introduce module specific version properties. I'll work on it this week and commit the new version directly. cheers, Roland improve Ant based build targets --- Key: HTTPASYNC-5 URL: http://issues.apache.org/jira/browse/HTTPASYNC-5 Project: HttpComponents Async Issue Type: Improvement Components: HttpAsync Reporter: Roland Weber Assigned To: Roland Weber Priority: Minor Attachments: 2k6-08-13-async-build-3.tar, 2k6-08-20-core-build-4.tar The Ant based build targets have some annoying peculiarities, like - JavaDoc target depends on compilation target - no compilation/package target for contrib code - main, contrib and test sources are all compiled into same class tree -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (HTTPASYNC-5) improve Ant based build targets
[ http://issues.apache.org/jira/browse/HTTPASYNC-5?page=all ] Roland Weber updated HTTPASYNC-5: - Attachment: 2k6-08-20-core-build-4.tar Here's a take on modular build files for HttpCore. The module build files can be used directly as well as from the main build file. I've moved the compile-xxx, clean-xxx and run-tests tasks into the module build files. Everything that goes into dist/ remains in the main build file. So does the run-clover task. I'm not really happy with Ant's name collision handling with the import task. I've had to define additional tasks in the main build file as a workaround. The contrib code is currently treated as if it was part of module-main, although it's still directly in httpcore/contrib in SVN. I feel that it should be moved into a module, either module-main or a separate module-contrib. I've put work on a Wiki page about the build process on hold until we have worked out the details. cheers, Roland improve Ant based build targets --- Key: HTTPASYNC-5 URL: http://issues.apache.org/jira/browse/HTTPASYNC-5 Project: HttpComponents Async Issue Type: Improvement Components: HttpAsync Reporter: Roland Weber Assigned To: Roland Weber Priority: Minor Attachments: 2k6-08-13-async-build-3.tar, 2k6-08-20-core-build-4.tar The Ant based build targets have some annoying peculiarities, like - JavaDoc target depends on compilation target - no compilation/package target for contrib code - main, contrib and test sources are all compiled into same class tree -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[HttpCore] Proxy Support
Hello all, I've been waiting for a quiet week-end to collect my thoughts and questions about proxy support in HttpCore, or HttpComponents in general. Since a quiet week-end doesn't seem to come my way, I've decided to write down what I have in mind right now, to get the discussion going. We have two interfaces HttpClientConnection and HttpProxyConnection, along with a default implementation for each. Proxy is derived from Client, both in the interface and default implementation. I think it is a design flaw to separate plain and proxy connections. Consider connection management: we want to create and manage a number of connections, not knowing whether they'll be used through a proxy or not. The proxy connection is not layered on top of a plain connection, the class is derived from it. So we always have to create proxy connections for the connection manager in order to allow proxying. Then those proxy connections are used either as a plain or as a proxy connection. Being proxied or not is a runtime property, and can not be reflected in the class hierarchy. Another problem is that proxying is not transparent. There is a check in HttpRequestExecutor.doEstablishConnection whether the connection is pointing to the correct target host. It might have been me who introduced that method as part of some refactoring. They way it is used, the connection always points to the correct host because the invocation argument is taken directly from the connection. But in general, the decision whether a connection is pointing appropriately can not be made without knowing whether it is proxied. If it is connected to a proxy and using a tunnel, then both proxy and ultimate target host have to be the intended ones. If it is proxied without (real) tunnelling, it can be kept alive even if the next request is going to a different target host but through the same proxy. I think the general idea of HttpCore was that a connection would be established to the appropriate host or proxy prior to sending the request, so that HttpCore doesn't have to bother. But that idea is currently broken in HttpRequestExecutor. We either have to repair the request executor (and adapt the async processor to those changes), or we need a different idea for proxy handling in HttpCore. Proxy handling is also not transparent to a connection manager, for the keep-alive reason mentioned above. If there is a connection open to the proxy, and not tunnelled to a specific target host (and not associated with some inappropriate authentication state), then that connection can be re-used for a different target host. I believe that the connection itself would be a good place to implement the logic for deciding whether it is pointing correctly. A minor detail is that only the HttpProxyConnection has an isSecure() method. A non-proxied connection can be secure, too :-) Another minor detail is the ProxyHost class, which is not used anywhere in the API, but only by the DefaultHttpProxyConnection. I'm not sure whether it adds any value. Finally, I am wondering where we'll plug in logic for proxy selection. Before digging deeper into this, I thought we could have a request interceptor that picks a proxy for the request. But request interceptors are executed only after the connection is available, and we need the information about the proxy before requesting the connection from a connection manager. Also, there are problems with proxy requests having a different status line from non-proxy requests, which would be ugly to deal with in a request interceptor. Proxy selection will also affect HttpAsync. While it is possible to design HttpCore so that it does not establish connections and therefore does not have to know about a proxy, HttpAsync provides a different interface. It is the responsibility of an HttpDispatcher to establish connections, so those will need to know which proxy to use. I'd like to discuss this now, so we can agree on a common interface for HttpAsync and HttpClient. OK, I think that's about all that has been bugging me about our proxy support those last few months. Let me know what you think. cheers, Roland - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Project Activity
Hi all, in case you're not subscribed to the general mailing list, Henri Yandell has posted some statistics about Jakarta project activity there: Mail: (Aug 19 data) (includes commits, wiki, jira, bugzilla noise) 9486 - jakarta-commons-dev 3140 - jakarta-jmeter-user 2459 - jakarta-commons-user 1788 - jakarta-jmeter-dev 1512 - jakarta-httpclient-dev 1082 - jakarta-httpclient-user 901 - jakarta-poi-user 868 - jakarta-general 802 - jakarta-velocity-user 739 - jakarta-poi-dev 672 - jakarta-velocity-dev 580 - jakarta-slide-user 355 - jakarta-turbine-user 308 - jakarta-jcs-users 288 - jakarta-httpclient-commits [snip] SVN (Aug 11 data) 2273 - commons 747 - jmeter 282 - httpcomponents 159 - poi 129 - site [snip] We're the third most active project in Jakarta behind commons and JMeter. And we have only one and a half coding committers. That tells a lot about how much effort Oleg is putting into this project. Thanks, Oleg! Hipp hipp hooray! x3 But it also raises some concerns about the health of this project. I hope that we can deliver a fully functional release of HttpComponents eventually, and that more developers join after that. Until I see that happening, I will be in favor of changes that have a prospect of bringing more people on board. In particular Henri's suggestion of joining some developer mailing lists. I'm not sure how well we fit with Taglibs and Velocity, which is what he suggested, but I like the general idea of merging some subcommunities. cheers, Roland ---BeginMessage--- Torsten's emails got me wondering what our activity was looking like this year per project. Mail: (Aug 19 data) (includes commits, wiki, jira, bugzilla noise) 9486 - jakarta-commons-dev 3140 - jakarta-jmeter-user 2459 - jakarta-commons-user 1788 - jakarta-jmeter-dev 1512 - jakarta-httpclient-dev 1082 - jakarta-httpclient-user 901 - jakarta-poi-user 868 - jakarta-general 802 - jakarta-velocity-user 739 - jakarta-poi-dev 672 - jakarta-velocity-dev 580 - jakarta-slide-user 355 - jakarta-turbine-user 308 - jakarta-jcs-users 288 - jakarta-httpclient-commits 271 - jakarta-turbine-dev 248 - jakarta-slide-dev 230 - jakarta-bcel-dev 218 - jakarta-taglibs-user 207 - jakarta-jcs-dev 192 - jakarta-cactus-dev 145 - jakarta-site-cvs 125 - jakarta-taglibs-dev 86 - jakarta-bsf-dev 77 - jakarta-bcel-user 44 - jakarta-regexp-dev 30 - jakarta-bsf-user 19 - jakarta-announcements 18 - jakarta-oro-user 16 - jakarta-oro-dev 6 - jakarta-ecs-user 5 - jakarta-ecs-dev 3 - jakarta-regexp-user 2 - jakarta-alexandria-dev 1 - jakarta-turbine-tdk-dev SVN (Aug 11 data) 2273 - commons 747 - jmeter 282 - httpcomponents 159 - poi 129 - site 121 - jcs 85 - velocity 69 - bcel 58 - turbine 31 - cactus 19 - bsf 13 - taglibs 10 - slide 6 - oro 4 - regexp 2 - ecs Who knew that JMeter was far and away our second most active project? :) And what an active user list it has. Less so on the committer side, 99% of the commits come from the same person. Cactus-user doesn't show up because its archives are broken on mail-archives. Nothing since 2003. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] ---End Message--- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: The HttpState of HttpClient in a multithreaded scenario
Hello David, From looking at the source, the instance variable 'state' (of type HttpState) seems to be shared between all the concurrently executed methods, this might result in a indeterminate state of the http state. HttpState should be synchronized and therefore thread-safe. If you want different threads to have separate states, then keep a state in each thread and use the execute methods that take a state as an argument. hope that helps, Roland - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r431182 - /jakarta/httpcomponents/httpcore/trunk/build.xml
Hi Oleg, This is just to make sure all resources required by the test cases are available to the class loader when the tests are run. Maven2 actually encourages that resources be kept separate from java sources and be stored in a separate resource folder, but we might still want to make sure that resources stored along with the source code get copied to the target folder at compile time. Sorry, I forgot that you might want to run tests from your IDE instead of using the Ant target that would copy the properties before running. cheers, Roland - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Commented: (HTTPASYNC-5) improve Ant based build targets
Hi Oleg, Actually you may want to consider splitting HttpCore build file into multiple ones, one per module. It is getting quite complex and with a few more modules may simply become unmanageable How many modules do you have in mind? At the very least I would like to see a Spring integration module added at some point of time. I would not completely rule out introduction of other modules in the future We could move the contrib code to an extra module - since it won't be built, there's no need for a pom.xml :-) I have already started to work on modular Ant build files, but I'm not yet through with it. I hope to have them done sometime this weekend. cheers, Roland - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: NTLM supported in JRE 1.5.0_08
Ortwin Glück wrote: I don't know... I just saw it in the release notes. See for yourself: http://java.sun.com/j2se/1.5.0/ReleaseNotes.html#150_08 I guess they forked the 1.5.0 branch before NTLM was added to 1.4 and now merged that feature into 1.5 as well. cheers, Roland - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (HTTPASYNC-5) improve Ant based build targets
[ http://issues.apache.org/jira/browse/HTTPASYNC-5?page=all ] Roland Weber updated HTTPASYNC-5: - Attachment: 2k6-08-13-async-build-3.tar Build files for HttpAsync and HttpCore. Improvements in property naming to allow setting of component-specific properties from a shared build.properties. The JavaDocs have become pretty slick - HttpAsync links to HttpCore, and both to JDK. HttpClient is currently not in project-trunk, I'll add a build file there when it's back. cheers, Roland improve Ant based build targets --- Key: HTTPASYNC-5 URL: http://issues.apache.org/jira/browse/HTTPASYNC-5 Project: HttpComponents Async Issue Type: Improvement Components: HttpAsync Reporter: Roland Weber Assigned To: Roland Weber Priority: Minor Attachments: 2k6-08-06-async-build-1.tar, 2k6-08-10-async-build-2.tar, 2k6-08-13-async-build-3.tar The Ant based build targets have some annoying peculiarities, like - JavaDoc target depends on compilation target - no compilation/package target for contrib code - main, contrib and test sources are all compiled into same class tree -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (HTTPASYNC-5) improve Ant based build targets
[ http://issues.apache.org/jira/browse/HTTPASYNC-5?page=all ] Roland Weber updated HTTPASYNC-5: - Attachment: (was: 2k6-08-06-async-build-1.tar) improve Ant based build targets --- Key: HTTPASYNC-5 URL: http://issues.apache.org/jira/browse/HTTPASYNC-5 Project: HttpComponents Async Issue Type: Improvement Components: HttpAsync Reporter: Roland Weber Assigned To: Roland Weber Priority: Minor Attachments: 2k6-08-13-async-build-3.tar The Ant based build targets have some annoying peculiarities, like - JavaDoc target depends on compilation target - no compilation/package target for contrib code - main, contrib and test sources are all compiled into same class tree -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (HTTPASYNC-5) improve Ant based build targets
[ http://issues.apache.org/jira/browse/HTTPASYNC-5?page=all ] Roland Weber updated HTTPASYNC-5: - Attachment: (was: 2k6-08-10-async-build-2.tar) improve Ant based build targets --- Key: HTTPASYNC-5 URL: http://issues.apache.org/jira/browse/HTTPASYNC-5 Project: HttpComponents Async Issue Type: Improvement Components: HttpAsync Reporter: Roland Weber Assigned To: Roland Weber Priority: Minor Attachments: 2k6-08-13-async-build-3.tar The Ant based build targets have some annoying peculiarities, like - JavaDoc target depends on compilation target - no compilation/package target for contrib code - main, contrib and test sources are all compiled into same class tree -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [HttpCore] Updated site preview
Hi Oleg, I wonder whether we could/should link the generated JavaDocs from the website. I'm not sure where to find them after the changes in HttpCore. Btw, the Ant-based JavaDoc targets now group the packages into API and Implementation (and Examples and Contributions, if you generate the extended version). Can we implement that easily in Maven, too? cheers, Roland - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r431182 - /jakarta/httpcomponents/httpcore/trunk/build.xml
Hi Oleg,
description
-HttpAsync: Jakarta HttpComponents Core
+Jakarta HttpComponents Core
/description
oops :-)
@@ -302,6 +305,9 @@
/classpath
/javac
+copy todir=${build.core.nio.tests} filtering=on
+ fileset dir=${comp.core.nio.tests} excludes=**/*.java /
+/copy
/target
@@ -484,10 +490,6 @@
description=runs unit tests on HttpCore classes
-copy todir=${build.core.tests} filtering=on
- fileset dir=${comp.core.main.tests} excludes=**/*.java /
- fileset dir=${comp.core.nio.tests} excludes=**/*.java /
-/copy
Let me guess. Maven copies the files when compiling the tests, and
fails to run tests correctly when the compiling was done by Ant?
cheers,
Roland
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Commented: (HTTPASYNC-5) improve Ant based build targets
Hi Oleg, Actually you may want to consider splitting HttpCore build file into multiple ones, one per module. It is getting quite complex and with a few more modules may simply become unmanageable How many modules do you have in mind? I don't have a (big) problem with splitting the build files, provided that the contrib code is moved to the modules. We'll have to think of a way to generate combined JavaDocs, but that can be handled by a build.xml in httpcore. cheers, Roland - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Unable to parse header issue
Hello Robert, Only handling strict http/1.x will mean that httpclient can not be used for many things. Like cooking coffee :-) It can still be used for what it's meant to be used: communicating with HTTP. For now rabbit has a flag to enable/disable strict http. That flag has to be set to false as default. We whish we could do that as well. But we can't. The HttpClient 3.x code base is monolithic. We can't disable a strict check, we'd have to add code for tolerance. I have not checked if httpclient handles newline issues strict or if is forgiving there. Most of the problems I saw with strict http handling where with CGI sending \n\n instead of \r\n\r\n. It is forgiving, see HttpParser.readLine(InputStream, String). We are also forgiving about spurious newlines at the beginning of a response, which is necessary for keep-alive with servers that send an extra newline after the response. If I were to try to build a web proxy with httpclient it would not work well, so all I can recomend is to at least make it possible to handle broken headers similar to how browsers treat them. We are working on HttpComponents, which introduces a modular design. When that is ready for prime time, it shouldn't be too hard to plug in a different header parser that does something useful with non- header lines. Then one could implement two, one that considers trash as a trash line and continues to read headers, and one that considers trash as an indication of a missing empty line after the headers and finishes header parsing there. Has anyone tried to run something like the co-advisor http tests with httpclient? http://coad.measurement-factory.com/ Not that I know of. We know that the design of HttpClient 3.x is broken, so why should we run tests for things we wouldn't implement there anyway? The redesign is our first priority, and it will keep us very busy for months to come. Once we've got something we feel comfortable with, we can consider adding features, including fault tolerance. Thanks a lot for the link - sounds very interesting. I'll remember it until the time is ripe. Just my thoughts, now I need to read through the nio-version to see how httpclient handles that, just to compare it to my proxy (which uses full nio for all handling). HttpClient doesn't handle it at all. HttpComponents will, but NIO support is only just in the making. cheers, Roland - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [HttpComponents] HttpCore will be in a state of flux for some time
Hi Oleg,
The new directory structure is in place. One should be able to build
HttpCore along with NIO extensions and HttpAsync using Maven. HttpCore
site and assemblies are still broken. I am going to fix them over the
weekend. Meanwhile you can go ahead with fixing the Ant build
I've been working on the Ant build for a few hours now. I don't want
to use the Maven structure for intermediate and result files. It
simplifies the build.xml a bit if I can put them all under
httpcore/build and /httpcore/dist instead of splitting the stuff in
httpcore/module-main/{build|dist} and httpcore/module-nio/{build|dist}.
I'm also creating only a single JAR file with both traditional and
NIO classes. I'm not sure yet whether I'll implement conditional
compilation for JDK 1.3. I'm leaning towards no, as it saves time
and because we don't need to duplicate everything in our build.
I have noticed some inconsistencies in the directory structure.
The contrib package on the top level is fine by me. In both modules,
the main and test classes are below src/main/java and src/test/java.
But module-main/src/examples and src/contrib do not have a java
subdir. I guess the java subdir is coming from Maven, as I don't
see any point in it for our pure-Java project. No harm done though,
the nested directories are annoying with or without another one.
Then I noticed that the NIO classes are in org.apache.http.nio.
But they seem to be implementation classes only. Shouldn't they
be in org.apache.http.impl.nio instead?
cheers,
Roland
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: NTLM supported in JRE 1.5.0_08
Hi Odi, Oleg, It's maybe noteworthy that the HTTP client within the brand new JRE version now supports NTLM: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4626557 I don't see what this has to do with the brand new JRE version? The bug report says fixed since 1.4.2, and we've know that the 1.4 JDK on Windows supports NTLM for a while. The details about the fix in the issue report are kind of scarce. Does this require a native platform support for NTLM or is it truly pure Java implementation? Sun has licensed NTLM from Microsoft for the Windows platform only. See property http.auth.ntlm.domain in this document: http://java.sun.com/j2se/1.4.2/docs/guide/net/properties.html I'm not sure whether their NTLM implementation in general is pure Java. What I know is that when they access the credentials of the logged-in user from the operating system, they are using native code. And they don't get uid/pwd, but some hash value from those that is required and sufficient to perform NTLM authentication. There is no way we can plug into this, even in contrib code. cheers, Roland - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [HttpComponents] HttpCore will be in a state of flux for some time
Hi Oleg, I am working on restructuring HttpNIO into a sub-module of HttpCore project in SVN. While doing so I have been constantly bumping into problems because of non-standard project directory layout. I feel it is time we bit the bullet and made the directory layout of HttpCore complaint with Maven guidelines. This, unfortunately, will affect all local checkouts and most likely will break them. I apologize for inconveniences this may cause you. OK, and thanks for the warning. I'll wait with working on build.xml files for HttpCore until you're through with this set of changes. cheers, Roland - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (HTTPASYNC-5) improve Ant based build targets
[ http://issues.apache.org/jira/browse/HTTPASYNC-5?page=all ] Roland Weber updated HTTPASYNC-5: - Attachment: 2k6-08-10-async-build-2.tar Take 2 on a revised Ant build. The former component.* build* and dist* property names now have an async in their name. This way, it is possible to let build.xml from async, core, client and elsewhere read in a single build.properties with local definitions, which can define different properties for each component. Especially useful if you want to generate JavaDocs to a place that does not get deleted when clean is executed :-) If there are no objections or suggestions for improvement, I'll write build files with the same structure for HttpCore and HttpClient after Oleg has finished shuffling the directory structure. cheers, Roland improve Ant based build targets --- Key: HTTPASYNC-5 URL: http://issues.apache.org/jira/browse/HTTPASYNC-5 Project: HttpComponents Async Issue Type: Improvement Components: HttpAsync Reporter: Roland Weber Assigned To: Roland Weber Priority: Minor Attachments: 2k6-08-06-async-build-1.tar, 2k6-08-10-async-build-2.tar The Ant based build targets have some annoying peculiarities, like - JavaDoc target depends on compilation target - no compilation/package target for contrib code - main, contrib and test sources are all compiled into same class tree -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (HTTPCLIENT-596) read() on the stream returned by HttpMethod.getResponseBodyAsStream() cannot be simply canceled with Thread.interrupt
[ http://issues.apache.org/jira/browse/HTTPCLIENT-596?page=comments#action_12426650 ] Roland Weber commented on HTTPCLIENT-596: - Hello Arnaud, we have no way of changing the behavior of native methods, or of any method built into Java. SocketInputStream is clearly not our responsibility. You should try with different JVM implementations to find one that does not have this problem. If you have an idea how we could work around this problem, we'll consider it. Otherwise, I suggest to mark this issue invalid. cheers, Roland read() on the stream returned by HttpMethod.getResponseBodyAsStream() cannot be simply canceled with Thread.interrupt - Key: HTTPCLIENT-596 URL: http://issues.apache.org/jira/browse/HTTPCLIENT-596 Project: HttpComponents HttpClient Issue Type: Bug Components: HttpClient Affects Versions: 3.0 Final, 3.0.1 Environment: Windows XP Reporter: Arnaud Masson I have a working thread that needs to download some big file with HttpMethod.getResponseBodyAsStream(). A swing component displays a progress indication and has a stop button. When the stop button is clicked by the user, I would like to stop the download as soon as possible, so I call interrupt() on the working thread from the EDT, which should throw an InterruptedException or InterruptedIOException inside the working thread. But the read() operation on the stream returned by HttpMethod.getResponseBodyAsStream() is not interrupted. The working thread stacktrace is: SocketInputStream.socketRead0(FileDescriptor, byte[], int, int, int) //- blocking SocketInputStream.read(byte[], int, int) line: 129 BufferedInputStream.fill() line: 218 BufferedInputStream.read() line: 235 ChunkedInputStream.getChunkSizeFromInputStream(InputStream) line: 249 ChunkedInputStream.nextChunk() line: 220 ChunkedInputStream.read(byte[], int, int) line: 175 AutoCloseInputStream(FilterInputStream).read(byte[], int, int) line: 111 AutoCloseInputStream.read(byte[], int, int) line: 107 ... I know that the JRE SocketInputStream doesn't support interrupt() but HttpClient should hide this problem. A workaround is to use request.abort() but it should be possible to cancel a thread without knowing on what it is blocked. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (HTTPCLIENT-596) read() on the stream returned by HttpMethod.getResponseBodyAsStream() cannot be simply canceled with Thread.interrupt
[ http://issues.apache.org/jira/browse/HTTPCLIENT-596?page=comments#action_12426675 ] Roland Weber commented on HTTPCLIENT-596: - Hello Arnaud, NIO is not an option for HttpClient, which is JDK 1.2 compatible. Oleg is working on NIO support for HttpComponents (4.0). Starting an extra thread for each request sounds like a lot of overhead to fix a problem which most people don't have. You can run an extra thread in your application, can't you? cheers, Roland read() on the stream returned by HttpMethod.getResponseBodyAsStream() cannot be simply canceled with Thread.interrupt - Key: HTTPCLIENT-596 URL: http://issues.apache.org/jira/browse/HTTPCLIENT-596 Project: HttpComponents HttpClient Issue Type: Bug Components: HttpClient Affects Versions: 3.0 Final, 3.0.1 Environment: Windows XP Reporter: Arnaud Masson I have a working thread that needs to download some big file with HttpMethod.getResponseBodyAsStream(). A swing component displays a progress indication and has a stop button. When the stop button is clicked by the user, I would like to stop the download as soon as possible, so I call interrupt() on the working thread from the EDT, which should throw an InterruptedException or InterruptedIOException inside the working thread. But the read() operation on the stream returned by HttpMethod.getResponseBodyAsStream() is not interrupted. The working thread stacktrace is: SocketInputStream.socketRead0(FileDescriptor, byte[], int, int, int) //- blocking SocketInputStream.read(byte[], int, int) line: 129 BufferedInputStream.fill() line: 218 BufferedInputStream.read() line: 235 ChunkedInputStream.getChunkSizeFromInputStream(InputStream) line: 249 ChunkedInputStream.nextChunk() line: 220 ChunkedInputStream.read(byte[], int, int) line: 175 AutoCloseInputStream(FilterInputStream).read(byte[], int, int) line: 111 AutoCloseInputStream.read(byte[], int, int) line: 107 ... I know that the JRE SocketInputStream doesn't support interrupt() but HttpClient should hide this problem. A workaround is to use request.abort() but it should be possible to cancel a thread without knowing on what it is blocked. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [HttpAsync] build.xml
Hi Oleg,
Thanks for your feedback. See my comments below.
(1) Maven should stay the preferred building tool for HttpComponents
(not because I like it that much, but for the consistency sake with the
rest of Jakarta and ASF). Therefore, I would not invest too much efforts
into Ant build file beyond a reasonable minimum.
It isn't my preferred build tool, and I doubt it will ever become.
I've used the Ant build from the start, and as long as Maven does
not do anything that Ant couldn't, I'd like to keep it that way.
Unless we find a majority for getting rid of Ant altogether, but
I don't see that happening if Gump supports only Ant.
(2) The 'contrib' and 'example' artifacts (at least to this point) are
meant to be distributed in source as a reference material only. I would
not bother including 'contrib' and 'example' specific tasks into the
build file.
That's probably because you are using an IDE (Eclipse?) that compiles
everything you load into it. I don't. Without an Ant task to build
those packages, I will miss it if their code is broken by a change.
Which happened only last weekend in HttpCore. If the code is supposed
to compile, I want a build target to compile it :-) Defining a target
for packaging was only done for sake of consistency, since the compile
targets shouldn't define dependencies.
I think this is a difference in the way we develop code. An IDE gives
you a completely separate build environment for incremental compilation,
including JavaDoc-style popups for everything. I don't have that, so I
need the functionality readily accessible in a build process. As far
as I have learned by now, Maven provides a linear lifecylce with the
deliverable package at the end. Ant has more flexibility for defining
all kinds of intermediate or side-exit targets. That's why I consider
Maven the tool for cutting a release every few months, while Ant is
my tool of choice for day to day development. It's a replacement for
the IDE rather than for Maven.
Otherwise, look ok to me
Thanks. I've spotted a big problem, though. The properties do not have
a namespace. If build files for HttpCore, HttpClient and HttpAsync all
use the same build.properties file, then the property names for
defining target directories like ${dist.api} must be distinct.
I'll try to come up with a new version sometime this week.
Maybe we'll also get some more feedback until then.
cheers,
Roland
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (HTTPCLIENT-594) HttpMethodBase#aborted variable mistakenly declared transient instead of volatile
[ http://issues.apache.org/jira/browse/HTTPCLIENT-594?page=comments#action_12426307 ] Roland Weber commented on HTTPCLIENT-594: - I'm with Odi. No need for an emergency release if nobody is experiencing problems. I haven't used volatile since the times when I was programming in C and assembler, and I don't remember having Java threading issues because of that. Still, I'll keep it in mind and silently put some volatile declarations into HttpAsync :-) cheers, Roland HttpMethodBase#aborted variable mistakenly declared transient instead of volatile - Key: HTTPCLIENT-594 URL: http://issues.apache.org/jira/browse/HTTPCLIENT-594 Project: HttpComponents HttpClient Issue Type: Bug Components: HttpClient Affects Versions: 3.0.1, 3.1 Alpha 1 Reporter: Oleg Kalnichevski Assigned To: Oleg Kalnichevski Fix For: 3.1 Beta 1 Attachments: httpmethodbase.patch HttpMethodBase#aborted variable mistakenly declared transient instead of volatile. This is quite nasty. Do we want to cut an emergency release (3.0.2) because of that or can this wait until 3.1-beta1? Fix attached. Oleg -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [HttpComponents] build-common.xml
Hi Oleg, Agreed. build-common.xml must go. I'll take care of the HttpCore build file, unless someone beats me to it. If I knew what you have in mind, I might give you a run for your credit :-) I'll take care of http-async, to show what I have in mind. cheers, Roland - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (HTTPCORE-7) ConnectionReuseStrategy should have access to the connection
[ http://issues.apache.org/jira/browse/HTTPCORE-7?page=all ] Roland Weber resolved HTTPCORE-7. - Resolution: Fixed Assignee: Roland Weber patch committed ConnectionReuseStrategy should have access to the connection Key: HTTPCORE-7 URL: http://issues.apache.org/jira/browse/HTTPCORE-7 Project: HttpComponents Core Issue Type: Improvement Components: HttpCore Affects Versions: 4.0-alpha2 Reporter: Roland Weber Assigned To: Roland Weber Priority: Minor Fix For: 4.0-alpha3 Attachments: 2k6-08-05-core-reusestrategy-1.txt The ConnectionReuseStrategy should have access to the connection in order to allow strategies based on the connection state, like: - close after X requests/responses - close after X minutes of use patch follows cheers, Roland -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[HttpComponents] Gump, Maven, Ant
Hi folks, does GUMP rely on the Maven or Ant version of our build process? And are HttpComponents built by Gump yet in the first place? cheers, Roland - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
