Hi Matt, The LGPL license is more restrictive than the Apache license. Thus, any changes made to the Innovation HTTPClient must be distributed as LGPL. The other way around would be easier - contributing code from the Jakarta HttpClient to the Innovation HTTPClient project.
I had a quick look at the Innovation HTTPClient. There are some things it doesn't have: - HTTPS support - Connection pooling (like the HttpConnectionManager used in HttpMultiClient) I suspect that it might be acceptable for your application to use more than the usual two connections to retrieve data from the content servers, so the connection pooling should be important. Sometimes these content servers will be on the local network and then it will definitely be acceptable. I suspect that pipelining will also give you great performance improvements. So, I agree. The best would be for you to create wrappers for the Jakarta HttpClient. Enjoy! Evert On Wed, 2002-06-12 at 20:38, SkyLeach wrote: > Oh and BTW: one very big reason for using the handler option (at least in my > case) is that I want the whole container (in this case Weblogic) to use the > HttpClient package. I am forced to use the java.net.URL factory to get my > connections because it is part of the J2EE and Servlet specs (section 1.4 in > the J2ee specs). > > My library uses this specification to store connection handle instances in > user sessions and allow developers to imbed dynamic Zope content into JSP > pages. The end result in my production system is 100% of all content in > Zope and 100% of all business logic in Java, with all the perks of load > balancing, high availability and scaleability to boot. > > My problem started when I was asked to also draw content from Lotus Notes > servers and Noetix report servers. Those two servers require cookies, > Authentication and in the case of some things, SSL. None of those are > supported by the Sun packages and I am bound to them for speed reasons. > (You can see it in action, as it is, at http://www.ctipowersolutions.com, > http://www.petscanarizona.net, http://www.ncpic.info, > http://www.ahmansonpet.net, and several other portals). Notice that while > most of the content is the same, most of the images are different. I > realize that this can be done with several other packages, but try doing it > and having all the content in one central repository where each respective > company can edit the content and see it before it is published on the site. > Then do that while having all your business logic in EJBs. > > As it is, to add a piece of content from the database all our JSP developers > have to do is put in the tag <zope:content namespace="/some/zope/namespace" > content="somezopecontent"/>. I ported mod_rewrite to the library and you > can do RewriteCondition and RewriteRule statements on the content before it > goes into the page. This resolves relative links and images through a proxy > servlet. > > So as you can see, I would benefit from being able to pass that flag to the > JVM and not have to change all my code. > > Oh, and do you guys think that the commons could use my library? It's a > special case tool, but reliable. > > ----- Original Message ----- > From: "SkyLeach" <[EMAIL PROTECTED]> > To: "Jakarta Commons Developers List" <[EMAIL PROTECTED]> > Sent: Wednesday, June 12, 2002 2:20 PM > Subject: Re: REPOST: Handlers for HttpClient? > > > > Thanks for the response, that is what I was looking for. Debates about > how > > pretty this implementation by the JCP is aside, it does work. You can do > it > > both programatically or by passing the option to the JVM when your class > > loads. The benefit of doing this as opposed to locking a URL protocol > > enabled applicaiton to one particular implementation of an HttpClient is > > that you can mix and match your handlers. > > > > I was also wondering why/if this project: > > http://www.innovation.ch/java/HTTPClient/ > > which is licensed under the LGPL could be integrated with the Apache > Commons > > HTTPClient project. > > It has support for the handler: > > http://www.innovation.ch/java/HTTPClient/advanced_info.html#urlcon > > proxies: > http://www.innovation.ch/java/HTTPClient/advanced_info.html#proxies > > pipelines: > > http://www.innovation.ch/java/HTTPClient/advanced_info.html#pipelining > > > > So if this package is more advanced (and the code seems pretty clean) can > > they be integrated and exteded into one package? > > > > > > ----- Original Message ----- > > From: "Gunnlaugur Thor Briem" <[EMAIL PROTECTED]> > > To: "Jakarta Commons Developers List" <[EMAIL PROTECTED]> > > Sent: Wednesday, June 12, 2002 1:51 PM > > Subject: RE: REPOST: Handlers for HttpClient? > > > > > > I haven't been involved in the HttpClient project, but I can > > still answer Matt's question a little more clearly: no, this > > hasn't been done. For this to work, there would have to be a > > package named org.apache.jakarta.httpclient.http (and another > > named org.apache.jakarta.httpclient.https to handle the https > > protocol) and they would each have to contain a class named > > Handler, and there are no such packages or classes currently > > in CVS. > > > > - Gulli > > > > > > > > > -----Original Message----- > > > From: SkyLeach [mailto:[EMAIL PROTECTED]] > > > Sent: 12. júní 2002 16:27 > > > To: Jakarta Commons Developers List > > > Subject: REPOST: Handlers for HttpClient? > > > > > > > > > Nobody responded to this last time, and I still am interested in knowing > > the > > > answer. Please read if you are using HttpClient and let me know... > > > > > > thanks, > > > > > > ----- Original Message ----- > > > From: "Matt Gregory" <[EMAIL PROTECTED]> > > > To: <[EMAIL PROTECTED]> > > > Sent: Tuesday, June 11, 2002 11:39 AM > > > Subject: Handlers for HttpClient? > > > > > > > > > > Have handler classes been created to wrap the Commons project > > HttpClient? > > > > > > > > In other words, can I pass the > > > > "-Djava.protocol.handler.pkgs=org.apache.commons.httpclient" directive > > to > > > my > > > > JVM and expect to get an org.apache.commons.httpclient.HttpConnection > > back > > > > from a java.net.URL.openConnection() call when I specify the "http" > > > protocol? > > > > > > > > Please let me know, and if not then I will work to extend the package > > now. > > > > I must have this functionality ASAP because my package, PortletStreams > > is > > > in > > > > production but needs cookie handling and HTTP authentication. > > > > > > > > Thanks in advance... > > > > -Matt > > > > > > > > > > > > -- > > > > To unsubscribe, e-mail: > > > <mailto:[EMAIL PROTECTED]> > > > > For additional commands, e-mail: > > > <mailto:[EMAIL PROTECTED]> > > > > > > > > > > > > > > > > > -- > > > To unsubscribe, e-mail: > > <mailto:[EMAIL PROTECTED]> > > > For additional commands, e-mail: > > <mailto:[EMAIL PROTECTED]> > > > > > > > > > -- > > To unsubscribe, e-mail: > > <mailto:[EMAIL PROTECTED]> > > For additional commands, e-mail: > > <mailto:[EMAIL PROTECTED]> > > > > > > > > -- > > To unsubscribe, e-mail: > <mailto:[EMAIL PROTECTED]> > > For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> > > > > > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
