Hi Oded,
The use of these types comes from our desire (and our users desire) to work with Java
1.1, often in Applets in a web browser. This unfortunately means that the more
abstract collections framework introduced in 1.2 is not available.
While Collection has a toArray() method, Vector (or ma
Hi guys,
I have a small patch that a collegue is working on that I would like
to see on the 1.2 branch. It adds support for an input encoding to
XmlRpc. This allows it to work correctly on z/OS and other EBCDIC
systems, where the default encoding is EBCDIC but the network
is ASCII.
I will pus
Henri Gomez wrote:
Working in the financial area, I manage number which should
be exact, so I used BigDecimal instead of double or Double.
Could it be extended to :
else if (obj instanceof Double || obj instanceof Float ||
obj instanceof BigDecimal)
{
star
> [EMAIL PROTECTED] wrote:
> Guys. This can be done with sane XML-RPC request/response objects
> (think servlets) and an interceptor API, instead of creating N endpoint
> implementations.
In what way are XmlRpcRequest and XmlRpcClientRequest objects
not 'sane'?
Why is having n implementatio
> > Yes but this isn't XML-RPC and XML-RPC is what the Apache code is
> > supposed to implement.
>
> I thought the whole idea about abstracting the transport layer was
> breaking the spec.
The idea of abstracting the transport layer was to make it easier to work
with custom or different HTTP imple
> > > 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 f
> 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 co
> Hi, does anyone know if there is a way to make the server side handlers
> multi-threaded. By default when you try to access a particular method on
> the server, that method is always run from the same object creating a
> potential bottleneck. I realise the Connection objects spawned by the
> Web
I've just had a look at this myself, since I refactored some of the classes
involved recently. The proposed solution will work OK in a closed
system where you already know the encoding sent back by the server.
It may well break if you force the encoding to be something non-UTF
when it is really
> Andrew, Daniel, pay attention:
>
> 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 ti
> While we are making changes, why not vote on the release plan?
>
> Please vote on the following release plans as follows:
>
> +1 = In favor
> 0 = Don't care
> -1 = Against it
>
> Feel free to comment on why you voted as you did.
>
>
> Plan 1:
>
> I committed my authentication refactorings. They did not include any
> changes to the SunSSLTransportFactory, as it was too new for me to get
> comfortable with. (translation: I didn't take the time to understand it
> fully).
It's a bit 'magic' due to the way Sun decided to do a few things ;)
Hi guys,
I've just committed a bunch of changes to allow support for SSL
using the new Transport/TransportFactory paradigm. The hard work
was done by Chris Jackson and Larry Meader who have already posted
to this list.
I've created a new DefaultXmlRpcTransportFactory that can load other
XmlRpcTra
> 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 LiteXmlRpcTransport.
>
> It isn't there!
W
> 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
Hi guys,
I've just been doing some debugging of one of our packages that uses
XML-RPC to perform some of its communication. One thing we needed to
do is get accurate information about the methods and parameters sent
in RPC's. Having omitted to put this information into our own code,
I tried to use
> I had a need to use Java2 collections so I changed two
> classes (webserver.java and xmlwriter.java). The
> changes were fairly trivial - I switched to using
> interfaces where possible, so it wouldn't break
> existing 1.1 code (eg. Hashtable and Hashmap both
> implement Map) also, new collection
> Myself and another coder here are looking to implement some secure
> xml-rpc clients and services, but it looks like the current code base
> is very much in flux with the recent refactoring/addition of the
> XmlRpcTransport stuff. My question to the list is should we take a
> crack at implementin
> OK, so I got my system hitting the repository over SSH, but it doesn't
> look like the code Andrew sent me has been committed yet. Some of it
> is there but theres no new branch and XmlRpcClient is still the old
> version at least.
>
> Should I make a branch with the zip or wait for you to put
> This issues that you've brought up so far are now taken care of.
> Please let us know what other tweaks would make the library more
> easily embeddable -- this is an important use case for most of us.
> Also, if you plan on adopting CVS HEAD, let me know and I will slap
> another tag on the repos
> I have the CLDC code, but didn't find the interface. Is it hidden in
> CVS or elsewhere? Also I modified the XmlRpcClientLite, my
> recollection is that there are plans for this that will modify it
> significantly.
Ryan and I are sharing code via private email at the moment.
> This is the gis
> My java project include the xmlrpc-1.1.jar, so it also includes MinML,
> which has a BSD-like license.
>
> Can I release and distribute my project under the GNU-GPL license ?
>
> Can I apply the GNU-GPL to my own code and ship it in a tar.gz
> including xmlrpc-1.1.jar ?
>
> In that case, can I sa
> Had a look over the current snapshot of where you are. I like the
> ideas there, although I believe the authentication information may not
> belong in the base XmlRpcContext as there are probably people who want
> to do authentication "in band" instead of "out of band". I believe
> more dis
> Last January I was inquiring if anyone knew how to perform SSL session
> resumption using an XML-RPC client. I did not receive a solution so I
> finally went back and addressed the issue. My solution was to copy the
> XmlRpcClientLite class and change the init method to use SSL sockets
> config
> Instead of an XmlRpcClientContext class, I would instead suggest
> writing an XmlRpcTransport interface that is then implemented by each
> of our HTTPTransport classes:
>
> public interface XmlRpcTransport() {
>
>public InputStream executeRequest(URL url, byte[] requestBody);
>
> }
I like
> If we decide to go ahead and make an XmlRpcClient interface,
> we either have to decide to use some NonImplementedException
> framework for the features of the interface that
> XmlRpcClientLiteImpl does not implement, or we need to
> use an abstract class with the bare minimum for the root
> inte
> Heya Andrew. I committed your code contribution, but used a class
> loading pattern instead of the instance pattern you specified. This
> allows one to supply new implementations of your TypeFactory interface
> without writing sub-class of types.
>
> java -Dorg.apache.xmlrpc.TypeFactory=path.t
> As far as my original attempts to get the interceptors patch noticed,
> you can find some of the history here:
> http://marc.theaimsgroup.com/?a=9372481891&r=1&w=2
I just looked over the patch, and it seems to me to be inverting things
a little. An XmlRpcRequest is really a part of a large
> Is a handler name which isn't resolvable really an error to a
> XmlRpcHandlerMapping implementation? To the caller of getHandler(),
> sure it is. But is it to the XmlRpcHandlerMapping itself? (I'm not
> sure.) I prefer to use exceptions only in exceptional situations (see
> "The Practive of
> "Andrew Evers" <[EMAIL PROTECTED]> writes:
>
> It would be nice if one could get ahold of a single threaded object
> which can process XML-RPC calls like XmlRpcServer can. It would be
> very cool if someone would factor that code out of XmlRpcServer.
>
> I would very much like to dump the WebServer class in favor of
> wrapping the XmlRpcServer in a HttpServlet (and not using a XML-RPC
> client to make requests like the current XmlRpcProxyServlet does).
> Basically, we'd mark it as deprecated and cease maintainence on it. As
> is, it has serious
31 matches
Mail list logo
