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