You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@incubator.apache.org by Steve Loughran <st...@apache.org> on 2007/10/08 12:37:00 UTC
Re: HttpClient, HttpComponents (was Jakarta)
Roland Weber wrote:
> A fallback option is to move from Jakarta to
> WebServices, exchanging one umbrella for another. That wouldn't
> move us forward, and the impression we got from Jakarta is that
> umbrellas are not in favour at the board.
> As a TLP, we will have a fighting chance to grow the project
> to the point where it no longer depends on just the two of us.
> Until that is achieved, we'll be one of those projects that
> Niall referred to, with community issues because they didn't
> pass through the Incubator. That's why I thought it was a good
> occasion to ask for suggestions. The new HttpComponents as well
> as the old HttpClient we maintain are being used by Apache
> projects, so coming into the Incubator is not an option for
> HttpComponents.
I dont consider http support in webservices as a general purpose
umbrella. Any Java stack that does SOAP or REST should be using
HttpClient unless they are naiive fools who believe that there is
someone that actually maintains java.net.HttpUrl, and that persion has
actually read the HTTP RFCs.
1. it is used in Axis, XFire, Alpine. I think the only mainstream stack
that doesnt use it is the Sun one, but they have the ability to fix bits
of java.net, and/or the naiive optimism I mentioned earlier.
2. It would be a good way of kickstarting more pure RESTy stuff in the
WS group.
3. this has been raised on ws pmc, we'd love to have the
HttpComponents/HttpClient team(s) on board if you want to join.
-steve
(still on the WS PMC, incidentally)
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: HttpClient, HttpComponents (was Jakarta)
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On 10/12/07, Roland Weber <os...@dubioso.net> wrote:
<snip>
> > I'd keep server side separate, but a rest-centric server side stack
> > (with no attempts to support WSDL) would be appealing, though restlets
> > exist for that purpose.
>
> Hmm. Can't say that I've ever perceived REST as much more than a
> buzzword,
FWIW REST is one of the better defined architectural styles
(http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm). if you
want to understand why ROA is becoming more important, read RESTful
Web Services (see http://www.crummy.com/writing/RESTful-Web-Services/,
for example).
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: HttpClient, HttpComponents (was Jakarta)
Posted by Eelco Hillenius <ee...@gmail.com>.
> Hmm. Can't say that I've ever perceived REST as much more than a
> buzzword
One of these things that started out as an architectural pattern, and
got hijacked for a thousand different interpretations. If it 'has'
REST, it's gotta be good ;-)
Eelco
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: HttpClient, HttpComponents (was Jakarta)
Posted by Roland Weber <os...@dubioso.net>.
Hi Steve, Niclas,
>>> Any Java stack that does SOAP or REST should be using
>>> HttpClient
>>
>> That seems to indicate that it should be a TLP in its own right.
>
> you want that, you get my support.
Thanks for your encouragement. I'm currently drowned in work,
but I intend to kick off the (hopefully last) TLP discussion
on httpcomponents-dev@jakarta before the end of this month.
Unless Oleg beats me to it :-)
> axis, ant-contrib, maven, jetty, wss4j, groovy. So not xerces or xalan.
> Maybe they are hoping someone will fix java.net.HttpUrlConnection now it
> is OSS/
Xerces and Xalan have plug-in interfaces for resolving external
references. They wouldn't do themselves a favour by adding an
external dependency for the default implementation. Just as we
wouldn't do ourselves a favour by shipping HttpComponents with
a specific SSL implementation.
http://xerces.apache.org/xerces2-j/javadocs/api/org/xml/sax/EntityResolver.html
http://xerces.apache.org/xerces2-j/javadocs/api/org/xml/sax/ext/EntityResolver2.html
http://xerces.apache.org/xerces2-j/javadocs/api/javax/xml/transform/URIResolver.html
http://xml.apache.org/xalan-j/apidocs/javax/xml/transform/URIResolver.html
>> And if the charter is extended to http server side as well (without
>> the servlet cruft ;o) ), we have a pretty immense project.
That already happened when HttpComponents left Commons
to become a separate Jakarta sub-project two years ago:
http://jakarta.apache.org/httpcomponents/charter.html
HttpComponents Core is agnostic, while HttpComponents Client is
the future replacement for the client-side 3.x codebase we'd like
to bury. The charter also includes specific statements that we will
not be developing server-side application layer APIs. I believe that
was necessary because others developing server-side HTTP (Tomcat?)
felt that we were stepping on their toes. At the time, it was
Apache policy to not allow competing projects, or so I've heard.
Your help to define the scope for the new project will be most
welcome.
> I'd keep server side separate, but a rest-centric server side stack
> (with no attempts to support WSDL) would be appealing, though restlets
> exist for that purpose.
Hmm. Can't say that I've ever perceived REST as much more than a
buzzword, but you're welcome to share your ideas. Even more so if
you bring in some folks who want to contribute code ;-) The current
developers are maxed out with pushing the two components we've got
towards production quality.
cheers,
Roland
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: HttpClient, HttpComponents (was Jakarta)
Posted by Steve Loughran <st...@apache.org>.
Niclas Hedhman wrote:
> On Monday 08 October 2007 18:37, Steve Loughran wrote:
>> Any Java stack that does SOAP or REST should be using
>> HttpClient
>
> That seems to indicate that it should be a TLP in its own right.
you want that, you get my support.
>
> Besides WS, we have;
> - Maven do the http client stuff... the naive version??
> - Ivy would be in the same boat.
> - Any XML parser and XSL transformer must be supporting externalizations.
> the list as you initiated will probably be long at exhaustive search.
gump shows some dependencies; a full walk of the m2 metadata will show
the rest
http://vmgump.apache.org/gump/public/httpcomponents/commons-httpclient/details.html
axis, ant-contrib, maven, jetty, wss4j, groovy. So not xerces or xalan.
Maybe they are hoping someone will fix java.net.HttpUrlConnection now it
is OSS/
>
> And if the charter is extended to http server side as well (without the
> servlet cruft ;o) ), we have a pretty immense project.
lovely servlet cruft. Much better than what sun builds in to java6.
I'd keep server side separate, but a rest-centric server side stack
(with no attempts to support WSDL) would be appealing, though restlets
exist for that purpose.
-steve
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: HttpClient, HttpComponents (was Jakarta)
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Monday 08 October 2007 18:37, Steve Loughran wrote:
> Any Java stack that does SOAP or REST should be using
> HttpClient
That seems to indicate that it should be a TLP in its own right.
Besides WS, we have;
- Maven do the http client stuff... the naive version??
- Ivy would be in the same boat.
- Any XML parser and XSL transformer must be supporting externalizations.
the list as you initiated will probably be long at exhaustive search.
And if the charter is extended to http server side as well (without the
servlet cruft ;o) ), we have a pretty immense project.
Cheers
--
Niclas Hedhman, Software Developer
I live here; http://tinyurl.com/2qq9er
I work here; http://tinyurl.com/2ymelc
I relax here; http://tinyurl.com/2cgsug
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org