You are viewing a plain text version of this content. The canonical link for it is here.
Posted to rpc-dev@xml.apache.org by Daniel Rall <dl...@finemaltcoding.com> on 2002/10/29 22:18:22 UTC
Re: [PATCH]: Alternative type mappings for primitive types.
"Andrew Evers" <ae...@redwood.nl> writes:
> > 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.to.my.CustomTypeFactory ...
> >
> > Let me know if this suites you.
>
> I like the class loading pattern, but I'm not sure about the global
> nature of the system property. However, it is sufficient for our
> application.
That's a very good point. I would like having class loading as the
default behavior, but allow the flexibility of overriding that on a
case-by-case basis.
> >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?
> > Did you ever happen to integrate JUnit tests for this functionality? --
>
> No, but it's on the list of stuff to do when I recover from jet-lag,
> along with finding my luggage ;)
Heh, damn throwers! On my last trip to Europe, they lost my luggage
in both directions.
--
Daniel Rall <dl...@finemaltcoding.com>
Re: [PATCH]: Alternative type mappings for primitive types.
Posted by Ryan Hoegg <rh...@isisnetworks.net>.
Daniel Rall wrote:
>Ryan Hoegg <rh...@isisnetworks.net> writes:
>
>
>
>>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.
>>
>>
>
>Definitely useful, but IMHO not worth 62k on the applet side.
>
>
You're probably right. Perhaps we should revisit this when Andrew and
my code changes settle down. We have started discussing breaking things
down into more modular packages with dependencies going only up the tree
(org.apache.xmlrpc.XXX can depend on whatever but org.apache.xmlrpc can
not depend on anything downstream).
--
Ryan Hoegg
ISIS Networks
http://www.isisnetworks.net
Re: [PATCH]: Alternative type mappings for primitive types.
Posted by Ryan Hoegg <rh...@isisnetworks.net>.
Daniel Rall wrote:
>Ryan Hoegg <rh...@isisnetworks.net> writes:
>
>
>
>>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.
>>
>>
>
>Definitely useful, but IMHO not worth 62k on the applet side.
>
>
You're probably right. Perhaps we should revisit this when Andrew and
my code changes settle down. We have started discussing breaking things
down into more modular packages with dependencies going only up the tree
(org.apache.xmlrpc.XXX can depend on whatever but org.apache.xmlrpc can
not depend on anything downstream).
--
Ryan Hoegg
ISIS Networks
http://www.isisnetworks.net
Re: [PATCH]: Alternative type mappings for primitive types.
Posted by Daniel Rall <dl...@finemaltcoding.com>.
Ryan Hoegg <rh...@isisnetworks.net> writes:
> Daniel Rall wrote:
>
> >Ryan Hoegg <rh...@isisnetworks.net> writes:
> >
> >>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 :)
Tell me about it. SourceCast is freakin' HUGE -- currently 924 MB for
a built source tree. Perhaps that gives you guys an indication of
where all my time is going. ;)
> The JAR for 0.1 is 62K.
IMHO, every little bit matters on the applet side. Last time we
polled, it seemed we had enough users that it was worth still
supporting that use case.
> 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.
Definitely useful, but IMHO not worth 62k on the applet side.
--
Daniel Rall <dl...@finemaltcoding.com>
Re: [PATCH]: Alternative type mappings for primitive types.
Posted by Daniel Rall <dl...@finemaltcoding.com>.
Ryan Hoegg <rh...@isisnetworks.net> writes:
> Daniel Rall wrote:
>
> >Ryan Hoegg <rh...@isisnetworks.net> writes:
> >
> >>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 :)
Tell me about it. SourceCast is freakin' HUGE -- currently 924 MB for
a built source tree. Perhaps that gives you guys an indication of
where all my time is going. ;)
> The JAR for 0.1 is 62K.
IMHO, every little bit matters on the applet side. Last time we
polled, it seemed we had enough users that it was worth still
supporting that use case.
> 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.
Definitely useful, but IMHO not worth 62k on the applet side.
--
Daniel Rall <dl...@finemaltcoding.com>
Re: [PATCH]: Alternative type mappings for primitive types.
Posted by Ryan Hoegg <rh...@isisnetworks.net>.
Daniel Rall wrote:
>Ryan Hoegg <rh...@isisnetworks.net> writes:
>
>>Daniel Rall wrote:
>>
>>>"Andrew Evers" <ae...@redwood.nl> 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
Re: [PATCH]: Alternative type mappings for primitive types.
Posted by Ryan Hoegg <rh...@isisnetworks.net>.
Daniel Rall wrote:
>Ryan Hoegg <rh...@isisnetworks.net> writes:
>
>>Daniel Rall wrote:
>>
>>>"Andrew Evers" <ae...@redwood.nl> 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
Re: [PATCH]: Alternative type mappings for primitive types.
Posted by Daniel Rall <dl...@finemaltcoding.com>.
Ryan Hoegg <rh...@isisnetworks.net> writes:
> Daniel Rall wrote:
>
> >"Andrew Evers" <ae...@redwood.nl> 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?
--
Daniel Rall <dl...@finemaltcoding.com>
Re: [PATCH]: Alternative type mappings for primitive types.
Posted by Daniel Rall <dl...@finemaltcoding.com>.
Ryan Hoegg <rh...@isisnetworks.net> writes:
> Daniel Rall wrote:
>
> >"Andrew Evers" <ae...@redwood.nl> 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?
--
Daniel Rall <dl...@finemaltcoding.com>
Re: [PATCH]: Alternative type mappings for primitive types.
Posted by Ryan Hoegg <rh...@isisnetworks.net>.
Daniel Rall wrote:
>"Andrew Evers" <ae...@redwood.nl> 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
--
Ryan Hoegg
ISIS Networks
http://www.isisnetworks.net
Re: [PATCH]: Alternative type mappings for primitive types.
Posted by Ryan Hoegg <rh...@isisnetworks.net>.
Daniel Rall wrote:
>"Andrew Evers" <ae...@redwood.nl> 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
--
Ryan Hoegg
ISIS Networks
http://www.isisnetworks.net