I guess for Ants specific requirement, service context is the best option IMHO.
However he can also choose to directly store the thing in the storage mechanism we have provided. (engine.put(), engine.get() methods that actually calls an underlying storage)
On 4/28/05, Chathura Herath <[EMAIL PROTECTED]> wrote:
> -----Original Message-----
> From: Sanjiva Weerawarana [mailto: [EMAIL PROTECTED]]
> Sent: Thursday, April 28, 2005 10:21 AM
> To: [email protected]
> Subject: Re: [Axis2]Article on E4X
>
> Chathura Herath wrote:
>
> >Hi Anthony,
> >
> >FYI there is a general bag of properties in both AxisService and
> >AxisOperation inherited from the org.apache.wsdl.ComponentImpl
> >
> > public void setComponentProperty(Object key, Object obj);
> > public Object getComponentProperty(Object key);
> >
> >Think this might serve your purpose??
> >
> >
> This isn't enough .. these are not instanced per service "session"; which
> I
> believe is what Ant wants.
Depends on the how the hooked in property should be treated, whether to
treat it as a "runtime service wide thing"(Context) or a "deployment time
configuration".
You are right about this because it's not graceful to let a provider change
(add stuff into) the configuration of the service. Rather the provider can
add stuff into the context of the service.
> He really wants what we called SessionContext
> in the F2F discussions.
Shouldn't it be the ServiceContext??? (Quote Antony: I needed somewhere to
stash away the Rhino compiled script object so the compile only happens on
the first request to a service.)
Regards,
Chathura
--
Ajith Ranabahu
