Bug 15216 / JXTA XML-RPC

Hi, I was looking over your bug report, and see no reason that your suggested changes should be blocked. I took a look at the site you linked to, and am a bit puzzled. The XML-RPC spec explicitly mentions HTTP POST as the transport. Now, of course you are free to write it using an asynchrono

DO NOT REPLY [Bug 9931] - Base64 decoder chokes on a whitespace: FASTER?

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug

DO NOT REPLY [Bug 9931] - Base64 decoder chokes on a whitespace: FASTER?

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug

Authentication: Whose responsibility?

I know what you're thinking: Here we go again! But I think we should revisit authentication now that we have abstracted the transport from the XML-RPC client. As I go through implementing (cleanly) my new XmlRpcTransport, I took a look at the authentication piece of DefaultXmlRpcTransport and

Apache e-mail

Couple of questions related to my apache.org account: Am I receiving e-mail there? If so, can I access it with POP or IMAP? How? Second, should I be listing my business e-mail address in @author lines or my apache.org address? -- Ryan Hoegg ISIS Networks http://www.isisnetworks.net

DO NOT REPLY [Bug 9931] - Base64 decoder chokes on a whitespace: FASTER?

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug

DO NOT REPLY [Bug 9931] - Base64 decoder chokes on a whitespace: FASTER?

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug

DO NOT REPLY [Bug 9931] - Base64 decoder chokes on a whitespace: FIXED?

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug

DO NOT REPLY [Bug 9931] - Base64 decoder chokes on a whitespace

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug

DO NOT REPLY [Bug 9931] - Base64 decoder chokes on a whitespace

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug

Re: [GUMP] Build Failure - xml-rpc

I just looked in project.xml, and theres a unitTest node. Part of what I committed were two abstract classes that match **/*Test.java. Perhaps this is what broke it? Maven / Gump experts? -- Ryan Hoegg ISIS Networks http://www.isisnetworks.net Ryan Hoegg wrote: Hey, I suppose my commits yes

Re: [GUMP] Build Failure - xml-rpc

Hey, I suppose my commits yesterday broke Gump, but I don't know how. the build works fine for me, and the tests all pass. Any ideas? Sam Ruby wrote: This email is autogenerated from the output from:

Re: Logging API

Andrew Evers wrote: I've just had a look, and the commons-logging package is 26K, or 18K for the '-api' version (that includes all we need in applets). OTOH, the classes I mentioned total to 6K. Even allowing another 3K for the cut-down loader solution I proposed and you still only reach half the

Re: Logging API

> I am almost convinced. I am unfamiliar with the functional > requirements of an applet developer for our library, but I will accept > at face value that an 80% increase in the file size of our applet jar > is unacceptable. > My concerns would be that the Commons Logging group already put plent

[GUMP] Build Failure - xml-rpc

This email is autogenerated from the output from: Buildfile: build.xml env: [echo] java.home = /usr/java/j2sdk1.4.1_01/jre