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
