Hi,
the DateFormat used in the DateTool is supporting only a subset of ISO
8601 date/times. In particular time zones are missing, likewise one must
not use milliseconds.
I suggest using the class XsDateTimeFormat from ws-jaxme instead, which
is a thread safe instance of Format. The only differen
On Do, 2004-06-17 at 03:32, Daniel Rall wrote:
> Jochen, this sounds like a reasonable activity for a target other than "jar"
> (perhaps a new target which has "jar" as a dependency).
Fine for me. I'd like to suggest, though, that the zip file is added to
the binary distribution as well, if noone
Thanks, committed in CVS rev 1.26.
Ryan Bloom wrote:
Index: src/java/org/apache/xmlrpc/WebServer.java
===
RCS file:
/home/cvspublic/ws-xmlrpc/src/java/org/apache/xmlrpc/WebServer.java,v
retrieving revision 1.24
diff -u -d -b -w -u -r1
dlr 2004/06/16 18:49:11
Modified:src/java/org/apache/xmlrpc WebServer.java
Log:
* src/java/org/apache/xmlrpc/WebServer.java
addDefaultHandlers(): Changed code to avoid deprecated call.
Submitted by: Ryan Bloom
Revision ChangesPath
1.26 +3 -1 ws-xmlr
dlr 2004/06/16 18:40:14
Modified:src/java/org/apache/xmlrpc AuthenticationFailed.java
DefaultHandlerMapping.java Invoker.java
MultiCall.java SystemHandler.java WebServer.java
XmlRpc.java XmlRpcRequestProcessor.ja
Ryan Bloom wrote:
Is there a reason that we are continuing to use the com.sun.net.ssl
classes for SSL? The javax.net.ssl classes are in JSSE 1.0.3_03 at least,
and it would mean that we could have a clean compile if we moved to the
non-deprecated classes.
Don't know off-hand, thought I suspect
Jochen, this sounds like a reasonable activity for a target other than "jar"
(perhaps a new target which has "jar" as a dependency). However, it would be
useful if the Maven-based build had parity here.
- Dan
Jochen Wiedmann wrote:
Hi,
the following makes the "jar" target create a file called
x
Ryan Bloom wrote:
I am getting a couple of files in my cvs diff output that should be
ignored.
Index: .cvsignore
===
RCS file: /home/cvspublic/ws-xmlrpc/.cvsignore,v
retrieving revision 1.7
diff -u -d -b -w -r1.7 .cvsignore
--- .cv
Jochen Wiedmann wrote:
Hi,
I suggest the following patch. By applying it, you get a project which
is almost immediately usable from within Eclipse, the exception being
that you have to add jar files to the "lib" directory. (Note, that I can
think of no reason, why these files shouldn't be added to
dlr 2004/06/16 18:16:42
Modified:.README.txt
Added: ..project .classpath
Log:
Basic facilities for building XML-RPC using Eclipse. I consider this
unsupported, but am not about to deny harmless contributions like this
from the user base.
* README
dlr 2004/06/16 18:10:03
Modified:..cvsignore
Log:
Ignore any local build.properties file.
Revision ChangesPath
1.8 +1 -0 ws-xmlrpc/.cvsignore
Index: .cvsignore
===
RCS file: /h
At 9:12 AM +0200 6/14/04, Jochen Wiedmann wrote:
Hi,
I understand that the spec doesn't handle null values. As xml-rpc
implements the SPEC, I find it completely valid, that null values are
rejected *by default*. However, I can think of no reason why they
shouldn't be supported *as a vendor extensio
Is there a reason that we are continuing to use the com.sun.net.ssl
classes for SSL? The javax.net.ssl classes are in JSSE 1.0.3_03 at least,
and it would mean that we could have a clean compile if we moved to the
non-deprecated classes.
Ryan
Index: src/java/org/apache/xmlrpc/WebServer.java
===
RCS file:
/home/cvspublic/ws-xmlrpc/src/java/org/apache/xmlrpc/WebServer.java,v
retrieving revision 1.24
diff -u -d -b -w -u -r1.24 WebServer.java
--- src/java/org/apache/xmlrpc/We
I am getting a couple of files in my cvs diff output that should be
ignored.
Index: .cvsignore
===
RCS file: /home/cvspublic/ws-xmlrpc/.cvsignore,v
retrieving revision 1.7
diff -u -d -b -w -r1.7 .cvsignore
--- .cvsignore 15 Aug 2
On Wed, 16 Jun 2004, Sebastian Dransfeld wrote:
> On Wed, 2004-06-16 at 15:20, Ryan Bloom wrote:
> > On Wed, 16 Jun 2004, Jochen Wiedmann wrote:
> >
> > > On Mi, 2004-06-16 at 15:08, Ryan Bloom wrote:
> > >
> > > > For some reason, just running ant test is failing one test for me.
> > > > Spec
On Tue, 15 Jun 2004, Adam Jack wrote:
>
> >
> > I am trying to get xmlrpc building, and I am running into problems with
> > commons-codec 1.2.
>
> Yup, Gump found these a few weeks ago. Basically the view from this
> list/community (of which I am just an observer, not a participant) is -- use
>
On Wed, 2004-06-16 at 15:20, Ryan Bloom wrote:
> On Wed, 16 Jun 2004, Jochen Wiedmann wrote:
>
> > On Mi, 2004-06-16 at 15:08, Ryan Bloom wrote:
> >
> > > For some reason, just running ant test is failing one test for me.
> > > Specifically, org.apache.xmlrpc.CommonsXmlRpcTransportTest, isn't a
On Mi, 2004-06-16 at 15:20, Ryan Bloom wrote:
> That's insane! I need an XMLRPC library for a project that I am working
> on, and I would really like to use this one, but I am having a hard time
> trusting it currently. I am going to start by going through and cleaning
> up all of the depreca
On Wed, 16 Jun 2004, Jochen Wiedmann wrote:
> On Mi, 2004-06-16 at 15:08, Ryan Bloom wrote:
>
> > For some reason, just running ant test is failing one test for me.
> > Specifically, org.apache.xmlrpc.CommonsXmlRpcTransportTest, isn't able to
> > connect to a server. I would have thought tha
On Mi, 2004-06-16 at 15:08, Ryan Bloom wrote:
> For some reason, just running ant test is failing one test for me.
> Specifically, org.apache.xmlrpc.CommonsXmlRpcTransportTest, isn't able to
> connect to a server. I would have thought that "ant test" would have run
> the server before trying
For some reason, just running ant test is failing one test for me.
Specifically, org.apache.xmlrpc.CommonsXmlRpcTransportTest, isn't able to
connect to a server. I would have thought that "ant test" would have run
the server before trying to run the client, but that doesn't seem to be
the ca
Nevermind, Jochen already posted one.
Ryan
On Wed, 16 Jun 2004, Ryan Bloom wrote:
>
> OK, I'll post the patch today.
>
> Ryan
>
> On Tue, 15 Jun 2004, Jochen Wiedmann wrote:
>
> > On Di, 2004-06-15 at 19:01, Ryan Bloom wrote:
> >
> > > So, I have one option (which kind of sucks), I can cas
OK, I'll post the patch today.
Ryan
On Tue, 15 Jun 2004, Jochen Wiedmann wrote:
> On Di, 2004-06-15 at 19:01, Ryan Bloom wrote:
>
> > So, I have one option (which kind of sucks), I can cast the byte[] to an
> > Object in the calls to encode/decode to retain compatibility between codec
> > 1.
Hi,
the following makes the "jar" target create a file called
xmlrpc--src.zip as well. This file contains the sources.
The reason for doing so is, that such files are quite convenient for
attaching them to the Java debugger. For example, in Eclipse I am always
adding the jar file and the source
Hi,
the following patch replaces the ancient SAX 1 drivers with SAX 2
drivers.
Use within applets is no reason for keeping SAX 1, IMO. I have
successfully used the (relatively small) Crimson parser for years.
Besides, if anyone exists, it should be no problem to update MinML to
support at least
Hi,
the following patch makes XmlRpc running with codec 1.2.
Jochen
Index: DefaultTypeFactory.java
===
RCS file: /home/cvspublic/ws-xmlrpc/src/java/org/apache/xmlrpc/DefaultTypeFactory.java,v
retrieving revision 1.3
diff -u -r1.3
Hi,
I suggest the following patch. By applying it, you get a project which
is almost immediately usable from within Eclipse, the exception being
that you have to add jar files to the "lib" directory. (Note, that I can
think of no reason, why these files shouldn't be added to the
repository. The l
28 matches
Mail list logo
