axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Doug Davis" <>
Subject Re: Registries and Admin and XML
Date Thu, 21 Jun 2001 14:01:23 GMT
Good golly - you've never know I actually
do speak English  8-(
Just my $.02.
- Being able to do local Admin function is a good thing,
not everyone will want to be able to configure their
SOAP server thru a service (for security reasons).
- If the engine is responsible for doing the load/save
stuff then how can we plug in other registries that might
have a totally different notion of load/save - kind of loses
the pluggability of things.
- I think what  you've proposed makes it harder (not impossible
just harder) to share deployment across engines.

"Glen Daniels" <> on 06/21/2001 09:43:25 AM

Please respond to

To:   <>
Subject:  Re: Registries and Admin and XML

Hi Doug:

> >I'd like to restructure things along the following lines:
> >1) Registries are just registries.  They don't know how to load() or
> ()
> >themselves, or anything about how things are serialized.
> So, who's going to do it? Are we going to expect each caller
> to the registries to also make a call to some other save() method?

The main difference here is that the engine is the thing that understands
the registries, since they are really just an artifact of the engine in the
first place.  So no external piece of code ever says "hr.add(name,
handler)" - rather, everyone else calls engine.deployHandler(name,
Now the sense of what's really going on (deploying a Handler into an
AxisEngine) is captured in the code.

So to answer your question, the engine's deploy/undeploy routines take care
of saving the registries.

> >2) The XML parsing code in Admin gets factored out into routines like
> >"deployHandler()", which looks at an XML <handler> element and deploys
> to
> >an AxisEngine (not directly to a registry).
> Does Admin (take the case of just running admin from outside of
> AxisEngine - assuming we want to keep this) now need to know about
> AxisEngine?  And which AxisEngine?  There could be a variety of them?

Right - Admin needs to know about AxisEngine, since it uses those APIs.
It's up to the user of the Admin class to decide which AxisEngine to deploy
into.  Typically the AdminService is going to be the active party, and that
service is deployed into an engine, so we're all set there.  You lose the
use-case of being able to use Admin "locally" to just write files, but I
think that's a good thing.

> >3) When an AxisEngine starts up, it uses the registry filenames passed
> it
> >(or the defaults) to initialize its registries by using the Admin code.
> Which Admin code?  Not sure what this is doing.

Admin is now a bunch of static utility functions like
Engine), deployService(Element, Engine), etc.  They just take care of
parsing the XML and calling the AxisEngine admin apis.

> >4) The AxisServer and AxisClient classes become the keepers of the
> >appropriate default Handler/Service configuration - if the registry XML
> >files aren't present, they take care of deploying the defaults at
> >time.
> Keep in mind that registries are probably going to want to be shared
> across different AxisEngines (sometimes - configurable).

No problem - this is all dependent on how you set the registry filenames
when the engine starts up.  I'm assuming we'll have some way to specify
in the (or axis.xml) file.  Of course, if different engines
are sharing the registry files, we'll need to handle file locking and
sure each engine polls the file for changes from other engines - to tell
the truth I'd prefer not to go this route.

> >Are people OK with this direction?
> >--Glen
> In general I think some restructuring of this probably a good thing
> but I'm worried about forcing other areas of the code to know too
> much about registries (ie. load/save).  Seems like making the
> registries themselves deal with how they load/save is a good level
> of isolation.  Who else but them should care how or even *when* it
> happens.

See above - I find this way of doing it much easier + cleaner.


View raw message