Jochen Wiedmann wrote:
>
> On 9/6/06, Joshua Levy <[EMAIL PROTECTED]> wrote:
>
>> I'm wondering what the best approach is, when using v3.0
>> server-side, to dynamically select the receiving instance that
>> implements remote methods. An example is creating a
>> user-dependent handling instance of a class that implements
>> a remote API.
>
> I'd consider this to be the task of the handler mapping. But I'd have
> had the same thoughts in 2.0. :-) You don't seem to think so, so
> please explain why.
>
I want to use HTTP basic auth to identify a user. This is used to
authenticate the user but also to allow the server to create (or reuse)
a per-session instance that handles all requests for that user's
session. And it seems cleaner if this per-session class implements
the remote API (that is reflected upon by the XMLRPC libs) rather
than having a single instance handle all requests for all users,
as in the typical configuration.
In particular the latter approach means
- one needs to write (and maintain) wrapping code for each
method that does nothing but delegate to the per-session
instances -- and then one is losing the benefit of not having
to code by hand the mapping between XMLRPC method
names and Java methods
- the details of the request, such as auth headers, aren't
available (implementing
AbstractReflectiveHandlerMapping.AuthenticationHandler.isAuthorized()
doesn't seem to help here; it just returns a boolean)
I got the impression from the docs and APIs that
PropertyHandlerMapping only provides a way to map method
calls to a class, i.e. a shared instance, hence there isn't an easy
way to map to separate, existing session instances. In effect, one
needs mappings that depend on additional features of the
request. This is why I extened AuthenticatedXmlRpcHandler before,
inserted a small bit of custom logic, and was happy I
could still take advantage of the XMLRPC reflection features
using Invoker.
But perhaps I am missing something? I'm happy to use the
"right" and encouraged approach, but don't yet see how...
I might mention, it seems this is a general issue, not specific
to basic auth or even session management. For instance,
one could use the outermost handling routine to perform
some transformation on the incoming method call (say,
removing the first arg, which might be a token of some sort),
or to do some final, outermost catching or cleansing of the
exceptions for remote consumption... Then the "inner"
API could be simpler to code, and more easily reused.
Thanks again for your help, and for maintainng a
really useful library.
Joshua
--
View this message in context:
http://www.nabble.com/Re%3A-Selecting-method-call-receiver-dynamically-in-v3.0-tf2229446.html#a6181429
Sent from the Apache Xml-RPC - Dev forum at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
