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