You are viewing a plain text version of this content. The canonical link for it is here.
Posted to xmlrpc-dev@ws.apache.org by John Wilson <tu...@wilson.co.uk> on 2002/11/11 11:24:40 UTC
Re: REPOST: https
----- Original Message -----
From: "Mauro Canal" <de...@canalsystems.net>
To: <rp...@xml.apache.org>
Sent: Monday, November 11, 2002 9:47 AM
Subject: REPOST: https
> Hi
>
> I recently implemented an easy to use start up functionality (including
SSL)
> for the Apache XML-RPC package.
>
> Configuration of the build in servers (WebServer and SecureWebServer) and
> assosciated handlers is done in a XML file (conf/server.xml).
>
> I put all together on http://canalsystems.net/xml-rpc/index.html
Mauro,
I have taken a very quick look at the source. In StartupHelper on line
720 you have:
public void characters(char[] buf, int start, int length) throws
SAXParseException {
String s = new String(buf, start, length).trim();
currentValue.append(s);
}
A SAX parser is allowed to make multiple calls to characters (e.g. it could
make one call per character). So the trim() call will produce a result which
can differ between parsers. It's better to accumulate the characters in the
StringBuffer and call trim in the end element callback.
Re: REPOST: https
Posted by John Wilson <tu...@wilson.co.uk>.
Ryan Hoegg wrote:
> John Wilson wrote:
[snip]
>
> On the JDK 1.2 issue, what is the use case for 1.1 support on the
> server side? My understanding is that we are trying to support 1.1
> for the client software to allow its use in applets.
Ryan,
J2ME users have issues with JDK 1.2 support. J2ME doesn't have JDK 1.2
Collections.
Actually. J2ME support is quite a complex issue. I would expect that a user
would have to make some changes to the XML-RPC implementation to get it to
work on their implementation but I think it would be desirable to minimise
this work (i.e. not using HashMap and not requiring Log4J).
John Wilson
The Wilson Partnership
http://www.wilson.co.uk
Re: REPOST: https
Posted by John Wilson <tu...@wilson.co.uk>.
Ryan Hoegg wrote:
> John Wilson wrote:
[snip]
>
> On the JDK 1.2 issue, what is the use case for 1.1 support on the
> server side? My understanding is that we are trying to support 1.1
> for the client software to allow its use in applets.
Ryan,
J2ME users have issues with JDK 1.2 support. J2ME doesn't have JDK 1.2
Collections.
Actually. J2ME support is quite a complex issue. I would expect that a user
would have to make some changes to the XML-RPC implementation to get it to
work on their implementation but I think it would be desirable to minimise
this work (i.e. not using HashMap and not requiring Log4J).
John Wilson
The Wilson Partnership
http://www.wilson.co.uk
Re: REPOST: https
Posted by Ryan Hoegg <rh...@isisnetworks.net>.
John Wilson wrote:
>I have just started to look at the Apache Commons Logging package which seems to offer a wrapper which allows actual logging implementations to be plugged in to an application and has support for Log4J. LogKit, JDK 1.4 and a simple file logging mechanism. has anybody any experience with this?
>
I would be interested in using this. The commons-logging.jar is 26K and
the commons-logging-api.jar is only 18K. As far as I can tell the only
difference is that the API jar omits the Log4J and LogKit support.
On the JDK 1.2 issue, what is the use case for 1.1 support on the server
side? My understanding is that we are trying to support 1.1 for the
client software to allow its use in applets.
--
Ryan Hoegg
ISIS Networks
http://www.isisnetworks.net
Re: REPOST: https
Posted by Ryan Hoegg <rh...@isisnetworks.net>.
John Wilson wrote:
>I have just started to look at the Apache Commons Logging package which seems to offer a wrapper which allows actual logging implementations to be plugged in to an application and has support for Log4J. LogKit, JDK 1.4 and a simple file logging mechanism. has anybody any experience with this?
>
I would be interested in using this. The commons-logging.jar is 26K and
the commons-logging-api.jar is only 18K. As far as I can tell the only
difference is that the API jar omits the Log4J and LogKit support.
On the JDK 1.2 issue, what is the use case for 1.1 support on the server
side? My understanding is that we are trying to support 1.1 for the
client software to allow its use in applets.
--
Ryan Hoegg
ISIS Networks
http://www.isisnetworks.net
Re: REPOST: https
Posted by Daniel Rall <dl...@finemaltcoding.com>.
"John Wilson" <tu...@wilson.co.uk> writes:
...
> I think that a standard logging interface for XML-RPC as a whole may be a
> good idea. One of the adavanatades of the Apache XML-RPC implementation at
> the moment is that you get all you need in a single download but because it
> uses SAX you can replace the parser if you prefer to use something else.
> Log4J is quite substantial (340Kb jar file) and is not everybody's choice
> for a Java logging package. I have just started to look at the Apache
> Commons Logging package which seems to offer a wrapper which allows actual
> logging implementations to be plugged in to an application and has support
> for Log4J. LogKit, JDK 1.4 and a simple file logging mechanism. has anybody
> any experience with this?
Yes. I was actually going to suggest the use of Jakarta Commons
Logging, +1.
...
> I think the next MinML release should go into the XML_RPC release. This is
> mainly because I'm changing the licence to the modified BSD licence so that
> GPL users can include the MinML code.
+1, very nice!
--
Daniel Rall <dl...@finemaltcoding.com>
Re: REPOST: https
Posted by Daniel Rall <dl...@finemaltcoding.com>.
"John Wilson" <tu...@wilson.co.uk> writes:
...
> I think that a standard logging interface for XML-RPC as a whole may be a
> good idea. One of the adavanatades of the Apache XML-RPC implementation at
> the moment is that you get all you need in a single download but because it
> uses SAX you can replace the parser if you prefer to use something else.
> Log4J is quite substantial (340Kb jar file) and is not everybody's choice
> for a Java logging package. I have just started to look at the Apache
> Commons Logging package which seems to offer a wrapper which allows actual
> logging implementations to be plugged in to an application and has support
> for Log4J. LogKit, JDK 1.4 and a simple file logging mechanism. has anybody
> any experience with this?
Yes. I was actually going to suggest the use of Jakarta Commons
Logging, +1.
...
> I think the next MinML release should go into the XML_RPC release. This is
> mainly because I'm changing the licence to the modified BSD licence so that
> GPL users can include the MinML code.
+1, very nice!
--
Daniel Rall <dl...@finemaltcoding.com>
Re: REPOST: https
Posted by John Wilson <tu...@wilson.co.uk>.
Mauro Canal wrote:
> Hello John
>
> Yes, you are right with the trim() issue in StartupHelper. I have
> fixed it and published the new version.
Excellent
>
> In my project, I need the Log4J implementation for the server process
> to log the handled request.
> On the client side the logger capability is not needed at all.
I think that a standard logging interface for XML-RPC as a whole may be a
good idea. One of the adavanatades of the Apache XML-RPC implementation at
the moment is that you get all you need in a single download but because it
uses SAX you can replace the parser if you prefer to use something else.
Log4J is quite substantial (340Kb jar file) and is not everybody's choice
for a Java logging package. I have just started to look at the Apache
Commons Logging package which seems to offer a wrapper which allows actual
logging implementations to be plugged in to an application and has support
for Log4J. LogKit, JDK 1.4 and a simple file logging mechanism. has anybody
any experience with this?
>
> For the matter of the JDK 1.1 compatibility I share the opinion to
> keep it for the client code.
> The server should implement the best afford for JDK 1.2 instead.
> Specially if used for SSL connections (eg. java.security.KeyStore).
I don't see any real objection to the SSL support requireing JDK 1.2 or
better. I would like to still be able to use a non SSL server implementation
in a JDK 1.1 environment.
>
> OFF-TOPIC: Why are you using MinML 1.6 in XML-RPC instead of the
> current version (MinML 1.7)?
I think it's because none of the problems fixed in 1.7 impacted XML-RPC.
> I also realized that
> MinML.setDocumentHandler(org.xml.sax.DocumentHandler) does not set
> the Locator for the passed DocumentHandler. This behavior throws
> a NullPointerExceptions when the Locator is referenced in
> StartupHelper. Is this an issue to be fixed?
Thanks for the bug report - I'll fix it in the next release (I you would
like a pre relase please contatct me off list).
I think the next MinML release should go into the XML_RPC release. This is
mainly because I'm changing the licence to the modified BSD licence so that
GPL users can include the MinML code.
John Wilson
The Wilson Partnership
http://www.wilson.co.uk
Re: REPOST: https
Posted by John Wilson <tu...@wilson.co.uk>.
Mauro Canal wrote:
> Hello John
>
> Yes, you are right with the trim() issue in StartupHelper. I have
> fixed it and published the new version.
Excellent
>
> In my project, I need the Log4J implementation for the server process
> to log the handled request.
> On the client side the logger capability is not needed at all.
I think that a standard logging interface for XML-RPC as a whole may be a
good idea. One of the adavanatades of the Apache XML-RPC implementation at
the moment is that you get all you need in a single download but because it
uses SAX you can replace the parser if you prefer to use something else.
Log4J is quite substantial (340Kb jar file) and is not everybody's choice
for a Java logging package. I have just started to look at the Apache
Commons Logging package which seems to offer a wrapper which allows actual
logging implementations to be plugged in to an application and has support
for Log4J. LogKit, JDK 1.4 and a simple file logging mechanism. has anybody
any experience with this?
>
> For the matter of the JDK 1.1 compatibility I share the opinion to
> keep it for the client code.
> The server should implement the best afford for JDK 1.2 instead.
> Specially if used for SSL connections (eg. java.security.KeyStore).
I don't see any real objection to the SSL support requireing JDK 1.2 or
better. I would like to still be able to use a non SSL server implementation
in a JDK 1.1 environment.
>
> OFF-TOPIC: Why are you using MinML 1.6 in XML-RPC instead of the
> current version (MinML 1.7)?
I think it's because none of the problems fixed in 1.7 impacted XML-RPC.
> I also realized that
> MinML.setDocumentHandler(org.xml.sax.DocumentHandler) does not set
> the Locator for the passed DocumentHandler. This behavior throws
> a NullPointerExceptions when the Locator is referenced in
> StartupHelper. Is this an issue to be fixed?
Thanks for the bug report - I'll fix it in the next release (I you would
like a pre relase please contatct me off list).
I think the next MinML release should go into the XML_RPC release. This is
mainly because I'm changing the licence to the modified BSD licence so that
GPL users can include the MinML code.
John Wilson
The Wilson Partnership
http://www.wilson.co.uk
RE: REPOST: https
Posted by Mauro Canal <de...@canalsystems.net>.
Hello John
Yes, you are right with the trim() issue in StartupHelper. I have fixed
it and published the new version.
In my project, I need the Log4J implementation for the server process
to log the handled request.
On the client side the logger capability is not needed at all.
For the matter of the JDK 1.1 compatibility I share the opinion to
keep it for the client code.
The server should implement the best afford for JDK 1.2 instead.
Specially if used for SSL connections (eg. java.security.KeyStore).
OFF-TOPIC: Why are you using MinML 1.6 in XML-RPC instead of the current
version (MinML 1.7)?
I also realized that MinML.setDocumentHandler(org.xml.sax.DocumentHandler)
does not set the Locator for the passed DocumentHandler. This behavior
throws
a NullPointerExceptions when the Locator is referenced in StartupHelper.
Is this an issue to be fixed?
I would like to thank you all for the great work on the Apache XML-RPC
project, which helps me to implement a flexible distributed
management system.
Mauro Canal
mcanal@canalsystems.net
----------------------------------------------------------------------
canal systems GmbH http://canalsystems.net
Kreuzlingerstrasse 132
CH-8587 Oberaach Tel. +41-71 411 10 80
> -----Original Message-----
> From: John Wilson [mailto:tug@wilson.co.uk]
> Sent: Monday, November 11, 2002 11:25 AM
> To: rpc-user@xml.apache.org
> Cc: rpc-dev@xml.apache.org
> Subject: Re: REPOST: https
>
>
>
> ----- Original Message -----
> From: "Mauro Canal" <de...@canalsystems.net>
> To: <rp...@xml.apache.org>
> Sent: Monday, November 11, 2002 9:47 AM
> Subject: REPOST: https
>
>
> > Hi
> >
> > I recently implemented an easy to use start up functionality (including
> SSL)
> > for the Apache XML-RPC package.
> >
> > Configuration of the build in servers (WebServer and
> SecureWebServer) and
> > assosciated handlers is done in a XML file (conf/server.xml).
> >
> > I put all together on http://canalsystems.net/xml-rpc/index.html
>
> Mauro,
>
> I have taken a very quick look at the source. In StartupHelper on line
> 720 you have:
>
> public void characters(char[] buf, int start, int length) throws
> SAXParseException {
> String s = new String(buf, start, length).trim();
> currentValue.append(s);
> }
>
> A SAX parser is allowed to make multiple calls to characters
> (e.g. it could
> make one call per character). So the trim() call will produce a
> result which
> can differ between parsers. It's better to accumulate the
> characters in the
> StringBuffer and call trim in the end element callback.
>
> From a XML-RPC project point of view this code adds dependencies to Log4J
> and JDK 1.2 or better. We have discussed moving from JDK 1.1 on this list
> before in when we looked at moving from Hashtable to HashMap and there was
> strong objection from some of the user community (applet and J2ME users).
>
>
> Logging is an interesting issue - I think we should chew it over
> on rpc-dev
> before adopting a standard solution.
>
> I have cross posted this reply to rpc-dev as the JDK 1.2 and Log4J
> discussion is probably better conducted there.
>
> John Wilson
> The Wilson Partnership
> http://www.wilson.co.uk
>
>
RE: REPOST: https
Posted by Mauro Canal <de...@canalsystems.net>.
Hello John
Yes, you are right with the trim() issue in StartupHelper. I have fixed
it and published the new version.
In my project, I need the Log4J implementation for the server process
to log the handled request.
On the client side the logger capability is not needed at all.
For the matter of the JDK 1.1 compatibility I share the opinion to
keep it for the client code.
The server should implement the best afford for JDK 1.2 instead.
Specially if used for SSL connections (eg. java.security.KeyStore).
OFF-TOPIC: Why are you using MinML 1.6 in XML-RPC instead of the current
version (MinML 1.7)?
I also realized that MinML.setDocumentHandler(org.xml.sax.DocumentHandler)
does not set the Locator for the passed DocumentHandler. This behavior
throws
a NullPointerExceptions when the Locator is referenced in StartupHelper.
Is this an issue to be fixed?
I would like to thank you all for the great work on the Apache XML-RPC
project, which helps me to implement a flexible distributed
management system.
Mauro Canal
mcanal@canalsystems.net
----------------------------------------------------------------------
canal systems GmbH http://canalsystems.net
Kreuzlingerstrasse 132
CH-8587 Oberaach Tel. +41-71 411 10 80
> -----Original Message-----
> From: John Wilson [mailto:tug@wilson.co.uk]
> Sent: Monday, November 11, 2002 11:25 AM
> To: rpc-user@xml.apache.org
> Cc: rpc-dev@xml.apache.org
> Subject: Re: REPOST: https
>
>
>
> ----- Original Message -----
> From: "Mauro Canal" <de...@canalsystems.net>
> To: <rp...@xml.apache.org>
> Sent: Monday, November 11, 2002 9:47 AM
> Subject: REPOST: https
>
>
> > Hi
> >
> > I recently implemented an easy to use start up functionality (including
> SSL)
> > for the Apache XML-RPC package.
> >
> > Configuration of the build in servers (WebServer and
> SecureWebServer) and
> > assosciated handlers is done in a XML file (conf/server.xml).
> >
> > I put all together on http://canalsystems.net/xml-rpc/index.html
>
> Mauro,
>
> I have taken a very quick look at the source. In StartupHelper on line
> 720 you have:
>
> public void characters(char[] buf, int start, int length) throws
> SAXParseException {
> String s = new String(buf, start, length).trim();
> currentValue.append(s);
> }
>
> A SAX parser is allowed to make multiple calls to characters
> (e.g. it could
> make one call per character). So the trim() call will produce a
> result which
> can differ between parsers. It's better to accumulate the
> characters in the
> StringBuffer and call trim in the end element callback.
>
> From a XML-RPC project point of view this code adds dependencies to Log4J
> and JDK 1.2 or better. We have discussed moving from JDK 1.1 on this list
> before in when we looked at moving from Hashtable to HashMap and there was
> strong objection from some of the user community (applet and J2ME users).
>
>
> Logging is an interesting issue - I think we should chew it over
> on rpc-dev
> before adopting a standard solution.
>
> I have cross posted this reply to rpc-dev as the JDK 1.2 and Log4J
> discussion is probably better conducted there.
>
> John Wilson
> The Wilson Partnership
> http://www.wilson.co.uk
>
>