On Oct 11, 2007, at 6:56 AM, Carsten Ziegeler wrote:
Now, all this sounds very cool and indeed it is - but users always had
the problem that they had to use the source resolver instead of plain
java.net.url classes. So before getting content you needed to get a
source resolver first. If you know how to do this, its really easy,
but
if not it is painfull.
Therefore we always had the dream in Cocoon to use plain java.net
classes to access any resource. In the last weeks I developed the
excalibur jnet package which hopefully makes this dream come true
in the
near future. It is a package which is able to install own url handlers
in a webapp environment and which is able to make source
implementations
available through java.net.URL class. The idea is to use well known
api
and classes to access custom stuff. Even for the XML streaming
stuff, I
created a prototype which (ab)uses the getContent(Class[]) method.
I don't think that is a good idea. java.net.URL is infamous for
being the worst web API on the planet -- it scrambled the concept
of a simple federated identifier (data) into what is basically the
HTTP interface (without actually knowing HTTP). Most web apps
that used it had to be completely rearchitected because the API
interferes with sensible design.
A good web API is going to look a lot like an HTTP server, with
connection handling being managed below message handling, which in
turn is below URI mapping to resources, and finally mapping of
HTTP method to actions on the resource. I think we should avoid
the standard Java APIs like the plague.
....Roy
