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]>
