That said, there are several major changes we have informally planned
for 2.0. Some of these include:
- abstraction of HTTP transport from XML-RPC processing
- interceptors and introspection
- use of commons-logging, commons-httpclient, and commons-codec internally
Well, I've got the
Craig R. McClanahan wrote:
Why not just provide a trivially simple two-class JAR file that
defines
org.apache.commons.logging.Log and
org.apache.commons.logging.LogFactory
with exactly the same public APIs as the real ones? Then, just
ship
this tiny little JAR file with apps (or
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9931.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Andrew Evers wrote:
Hmm, thread revival. Had to go back to the archives to check out what I had
said. This proposal looks like a solution.
Log itself is an interface, LogFactory is a class. The tiniest possible
implementation
we could build would be to have our own LogFactory that copies the real
Andrew Evers wrote:
That said, there are several major changes we have informally planned
for 2.0. Some of these include:
- abstraction of HTTP transport from XML-RPC processing
- interceptors and introspection
- use of commons-logging, commons-httpclient, and commons-codec internally
Well,
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9931.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
