axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Doug Davis" <...@us.ibm.com>
Subject Re: RE: [GUMP] Function Test Failure - Axis
Date Mon, 15 Oct 2001 14:49:17 GMT
>> Mainly because I see the "name" field on the service as just
>> a dummy placeholder - kind of like the names of handlers.
>The names of handlers are critical because they're what gets used to look
>them up.  The names of services are similar.
>> They're something that Axis uses to find the object.  If people
>> want to change the URL of their service it shouldn't require an
>> undeploy/deploy of the service object - a simple option
>> change would be better.

That's my point - they're used by Axis and we don't know for sure
what things will reference each other in the future.  For example,
there's no reason why a Service couldn't be placed in chain.  If
people need to change an external property (like the URL) then
we don't want to make them go through ALL other objects that might
reference it and change those too.  Internal names should be kept
separate from external names.

>At present, redeploying is the only way to do an "option change".

This will change.  8-)

>> Also, URLMapper is just an optional thing in Axis - so if someone
>> deploys a service named "foo", then comes along and adds
>> URLMapping but they really don't like "foo" on the URL, why
>> should they have to rename (and of course redeploy) their
>> service.
>You keep framing URLMapper as "just an optional thing", when we're making
a
>real effort to push URL dispatch as the default.  Yes, you can reconfigure
>it, but out of the box URL dispatch is the way Axis works.

No, URL dispatching is not "the default" - it is "the default for HTTP".
Remember we support multiple transports which will eventually include
more than just 2 service finding mechanisms(URLMapper and namespace).

>Also this argument seems specious to me in that they're going to have to
>make a change either way (adding an option or renaming the service), and
>right now that means the same thing (redeploy).

Not at all - in fact we don't necessarily do an undeploy/redeploy right now
to just do an option change - I believe we search for an existing service
with that name and just change it.  In the future "undeploy" and "redeploy"
could have some very serious(heavy) side-effects, so like I said before,
we'll need make sure we will support changing a service/handler... w/o
undeploy/deploy.

>> And finally, it would be nice if at some point we allowed multiple
>> URLs to map to a single service.
>Why?  I mean it's not that I think it's an actively bad idea, but what's
the
>use-case?

Same use-case as servlets supporting multiple URLs.

-Dug


Mime
View raw message