Not there yet, but it *will* be.
Scott
----- Original Message -----
From: "Michael Jennings" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, June 24, 2002 5:01 PM
Subject: Re: TODO list item
> So it's there? Cool!
> -Mike
>
> ----- Original Message -----
> From: "Scott Nichol" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Monday, June 24, 2002 1:53 PM
> Subject: Re: TODO list item
>
>
> > Yes, in modified form with the additional properties sources (e.g.
> > deployment descriptor).
> >
> > Scott
> >
> > ----- Original Message -----
> > From: "Michael Jennings" <[EMAIL PROTECTED]>
> > To: <[EMAIL PROTECTED]>
> > Sent: Saturday, June 22, 2002 1:11 PM
> > Subject: Re: TODO list item
> >
> >
> > > Hi Scott,
> > >
> > > Any chance of that diff making it into the codebase?
> > > (in whatever form)
> > >
> > > -Mike
> > >
> > > ----- Original Message -----
> > > From: "Scott Nichol" <[EMAIL PROTECTED]>
> > > To: <[EMAIL PROTECTED]>
> > > Sent: Tuesday, June 18, 2002 10:25 AM
> > > Subject: Re: TODO list item
> > >
> > >
> > > > See my comments below. If any other committers would like to
comment,
> > > > please do so soon. Thanks.
> > > >
> > > > Scott Nichol
> > > >
> > > > ----- Original Message -----
> > > > From: "Michael Jennings" <[EMAIL PROTECTED]>
> > > > To: <[EMAIL PROTECTED]>
> > > > Sent: Tuesday, June 18, 2002 11:20 AM
> > > > Subject: Re: TODO list item
> > > >
> > > >
> > > > > Hi Scott,
> > > > >
> > > > > I would prefer to use a J2SE class as well if there was one that
fit
> > the
> > > > > bill.
> > > > > At least the dependence is on one class only (Configurable) so in
> > > > > the worst-case scenario another project that used the service
class
> > > > > would have to include that one extra class.
> > > >
> > > > It's just that then soap.jar has to follow the class around
> everywhere.
> > > One
> > > > of the things I always liked about Apache SOAP is that the classes
> > > > implementing services are just plain old Java classes that I could
> > harvest
> > > > from elsewhere in a project and continue to use as services and in
> other
> > > > environments as well.
> > > >
> > > > I really wish J2SE had a VanillaEventListener interface like
> > > >
> > > > interface VanillaEventListener implements EventListener {
> > > > void handle(VanillaEvent ve);
> > > > }
> > > >
> > > > to let us do generic event handling with J2SE classes. Without
that,
> it
> > > > becomes tempting to bastardize Observer into a generic event
listener
> > > > interface. The observer never registers with an observable, and the
> > > > observable paramter to the update method is always null.
> > > >
> > > > >
> > > > > I kind of think of it as an equivalent to the
> > > > > javax.servlet.http.HttpSessionBindingListener
> > > > > interface in the servlet API, whereby any object can be placed
> inside
> > of
> > > > an
> > > > > HttpSession
> > > > > but if it implements HttpSessionBindingListener it will get
notified
> > > when
> > > > it
> > > > > is bound or
> > > > > unbound from the session. The minor servlet api coupling is the
> price
> > > you
> > > > > pay for
> > > > > gaining the ability to be notified of (un)binding.
> > > >
> > > > Agreed. It's a nice, clean, specific piece of functionality.
> > > >
> > > > >
> > > > > If there is a place in the deployment descriptor where
> initialization
> > > > > properties
> > > > > can be placed that would be much better than grabbing them from
the
> > > > > ServletContext.
> > > >
> > > > DeploymentDescriptor has a hashtable called props that is populated
> with
> > > > data from <isd:option> tags within the <isd:provider> tag. The EJB
> > > provider
> > > > uses these, such as in the EJB sample:
> > > >
> > > > <isd:provider
type="org.apache.soap.providers.StatelessEJBProvider"
> > > > scope="Application"
> > > > methods="create">
> > > > <isd:java class="samples/HelloService"/>
> > > > <isd:option key="FullHomeInterfaceName"
> > > value="samples.HelloServiceHome"
> > > > />
> > > > <isd:option key="ContextProviderURL"
value="iiop://localhost:900"
> />
> > > > <isd:option key="FullContextFactoryName"
> > > > value="com.ibm.ejs.ns.jndi.CNInitialContextFactory" />
> > > > </isd:provider>
> > > >
> > > > While the options are XML descendants of the provider, there is no
> > reason
> > > > they cannot be supplied to the service class through the mechanism
we
> > are
> > > > discussing.
> > > >
> > > > > Perhaps if the properties were grabbed from the ServletContext
> first,
> > > then
> > > > > stuff from the
> > > > > deployment descriptor could be slammed overtop. That way if there
> are
> > > some
> > > > > properties
> > > > > that all services in a web-app need access to, you could put them
in
> > one
> > > > > place
> > > > > instead of in multiple deployment descriptors.
> > > > > However it's done, I don't really care so long as I can pass some
> kind
> > > of
> > > > > init params to
> > > > > a service class instance.
> > > >
> > > > My only concern about ServletConfig (and ServletContext) is a fairly
> > minor
> > > > one, namely that the servlet in question is the SOAP router servlet
> and
> > > that
> > > > an environment with multiple services from multiple vendors could
have
> > > name
> > > > clashes. Of course, if everyone would somehow mangle their
> > initialization
> > > > parameters names to make them unique, there is no problem. Anyway,
> the
> > > > scenario is pretty unlikely to arise, so I am not against using
> > > > context/config. I understand that these are nice to use when you
have
> > the
> > > > same parameter(s) used by a number of services, such as a JDBC
> > connection
> > > > string.
> > > >
> > > > I think it would be better to simply provide the initialization
> > > information
> > > > from different sources separately. The service should have the
right
> to
> > > > prefer a servlet or context parameter over a deployment descriptor
> one,
> > > > rather than a parameter hierarchy being imposed unilaterally across
> all
> > > > services.
> > > >
> > > > >
> > > > > What do you think?
> > > > > -Mike
> > > > >
> > > >
> > > > The mechanism you propose is very clean and, I think, desireable.
> While
> > > the
> > > > same result can be achieved with the existing SOAPContext parameter
> > code,
> > > > there is no doubt in my mind that you have proposed a better way to
> > > > implement service initialization.
> > > >
> > > > I recommend we wait a day to see whether any other committers (for
> that
> > > > matter, anyone on the list) comment before you start writing the
> patch.
> > > >
> > > > Scott
> > > >
> > > >
> > > >
> > >
> > >
> > > --
> > > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
> > > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
> > >
> > >
> >
> >
> > --
> > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
> >
> >
>
>
> --
> To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
>
>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
