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