commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "SkyLeach" <skyle...@skyleach.com>
Subject Re: REPOST: Handlers for HttpClient?
Date Wed, 12 Jun 2002 18:38:43 GMT
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" <skyleach@skyleach.com>
To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
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" <gthb@dimon.is>
> To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
> 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:skyleach@skyleach.com]
> > 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" <matthew.gregory@skyleach.com>
> > To: <commons-dev@jakarta.apache.org>
> > 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:commons-dev-unsubscribe@jakarta.apache.org>
> > > For additional commands, e-mail:
> > <mailto:commons-dev-help@jakarta.apache.org>
> > >
> > >
> >
> >
> > --
> > To unsubscribe, e-mail:
> <mailto:commons-dev-unsubscribe@jakarta.apache.org>
> > For additional commands, e-mail:
> <mailto:commons-dev-help@jakarta.apache.org>
> >
>
>
> --
> To unsubscribe, e-mail:
> <mailto:commons-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail:
> <mailto:commons-dev-help@jakarta.apache.org>
>
>
>
> --
> To unsubscribe, e-mail:
<mailto:commons-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail:
<mailto:commons-dev-help@jakarta.apache.org>
>
>


--
To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>


Mime
View raw message