Re: [PATCH]: Alternative type mappings for primitive types.

[Ryan Hoegg]

Daniel Rall wrote:

Ryan Hoegg <[EMAIL PROTECTED]> writes:

Daniel Rall wrote:

"Andrew Evers" <[EMAIL PROTECTED]> writes:

From an overall embedding perspective it would be nice to specify

a property hash to a number of the constructors that could be
used to specify alternative classes for not only the type factory,
but also the request or response processor, or the worker. This
would provide more graceful construction as more optional features
are added.

The JNDI InitialContext and JAXP {SAXParser,DocumentBuilder}Factory
API's use similar concepts.

Interested in patching?

You might be interested in the Commons Discovery project, which
provides a standard (?) way to find implementations of a given
interface. I am going to look into this as a possibility for
streamlining the new XmlRpcTransport interface code I am working on
with Andrew Evers.


Project: http://jakarta.apache.org/commons/discovery.html

Good place to get a quick and dirty idea of what this stuff does:
http://jakarta.apache.org/commons/discovery/apidocs/org/apache/commons/discovery/DiscoverClass.html

Would this dependency only be necessary on the server side, or would
it be a requirement on the client side as well?

You have to forgive me, I spend most of my time programming larger applications where footprint isn't as much of an issue as with libraries such as this :) The JAR for 0.1 is 62K.

As far as I can tell this dependency would be introduced anywhere we want to automatically discover an implementation class for an interface. We could break it off into an AutoDiscoverFactory class that sits in another package. The reason I bring it up is that automatic discovery of classes provides a clean way to provide a default implementation while providing flexibility to the end user for specifying alternate implementations for an interface.

--
Ryan Hoegg
ISIS Networks
http://www.isisnetworks.net