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.
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.
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.
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.
What do you think?
-Mike
----- Original Message -----
From: "Scott Nichol" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, June 17, 2002 8:35 PM
Subject: Re: TODO list item
> Mike,
>
> I think your explanation is quite clear. You want a mechanism to
initialize
> service class instances in an efficient and thread-safe way that is as
> independent of the execution environment as possible. I agree that the
> existing SOAPContext-as-the-first-parameter hook does not fill this role
> especially well, and I like your proposed mechanism as it is pretty light
> weight, both from the Apache SOAP side and the service class side.
>
> Two things bother me, though. First, you still introduce an interface
> within Apache SOAP through which the initialization takes place, so
classes
> to be initialized and classes doing the initialization will have a
> dependancy on soap.jar. I really wish the J2SE API had an appropriate
> interface to use instead (some type of Listener), but none of the ones
that
> I can think of would make sense. Maybe someone else has a good idea.
> Second, I seem to recall that the properties are taken from the
> ServletContext. I am wondering whether that is the right place (and
whether
> it should be the only place). Isn't the deployment descriptor, which is
> specific to a service, a more logical place from which to initialize? The
> servlet is global to Apache SOAP, leaving initialization parameters for
one
> service subject to name clashes with parameters for another.
>
> I'm not saying these issues are "deal killers". They are just things I
want
> to consider before adding the feature to be sure it is as useful as
> possible.
>
> Scott Nichol
>
> ----- Original Message -----
> From: "Michael Jennings" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Monday, June 17, 2002 2:27 PM
> Subject: Re: TODO list item
>
>
> > Hi Scott,
> >
> > What I was thinking was more like in ServerHTTPUtils when targetObject
> > is first created
> > targetObject = c.newInstance ();
> > have some kind of mechanism whereby some initialization parameters could
> be
> > passed
> > (database connection info, file locations etc.)
> > in a non-servlet-specific way.
> > So I thought a "Configurable" interface could be checked for and if the
> > targetObject
> > implements that interface, then its configure method could be called and
> > some
> > configuration information could be sent to it.
> >
> > public interface Configurable
> > {
> > public void configure(Properties props);
> > }
> >
> > Something more complex than a Properties object might be better, but at
> > least a Properties object
> > is not transport-specific (ie. servlets).
> >
> > If instead I decide to prepend a SOAPContext object to the parameter
list
> of
> > every
> > function exposed by the targetObject that makes the code a little
messier
> > and also
> > more tightly bound to Apache SOAP classes and the servlet API.
> >
> > Here's an example that hopefully makes sense:
> >
> > public class MySoapServer
> > {
> > boolean isConfigured=false;
> >
> > private void configure(SOAPContext context)
> > {
> > ...
> > isConfigured=true;
> > }
> >
> > public void methodA(SOAPContext context,int param1,String param2) throws
> > Exception
> > {
> > if (!isConfigured)
> > configure(context);
> > ...
> > }
> >
> > public void methodB(SOAPContext context,int param1,String param2,double
> > param3) throws Exception
> > {
> > if (!isConfigured)
> > configure(context);
> > ...
> > }
> >
> > public void methodC(SOAPContext context,Map param1) throws Exception
> > {
> > if (!isConfigured)
> > configure(context);
> > ...
> > }
> > }
> >
> > versus...
> >
> > public class MySoapServer implements Configurable
> > {
> > private void configure(Properties props)
> > {
> > ...
> > }
> >
> > public void methodA(int param1,String param2) throws Exception
> > {
> > ...
> > }
> >
> > public void methodB(int param1,String param2,double param3) throws
> Exception
> > {
> > ...
> > }
> >
> > public void methodC(Map param1) throws Exception
> > {
> > ...
> > }
> > }
> >
> > I hope I have made some sense. In reading over this Email I'm not so
sure
> > that
> > I've been very clear.
> >
> > -Mike
> >
> >
> >
> >
> > ----- Original Message -----
> > From: "Scott Nichol" <[EMAIL PROTECTED]>
> > To: <[EMAIL PROTECTED]>
> > Sent: Monday, June 17, 2002 11:03 AM
> > Subject: Re: TODO list item
> >
> >
> > > Mike,
> > >
> > > I have reviewed your submission as well as existing code with similar
> > > purpose. It is my believe that functionality related to the TODO
> already
> > > exists. Namely, the code that determines what method to invoke for
the
> > > service first looks for a signature matching the parameter types in
the
> > SOAP
> > > request, and if there is no match, looks for a signature with an
initial
> > > SOAPContext parameter followed by the types in the request. If one is
> > > found, the SOAPContext for the request is passed to the service
method.
> > > This is quite powerful, as the SOAPContext includes methods to
> manipulate
> > > the content of the response, as well as a bag containing the current
> > > HttpServlet, HttpSession, HttpServletRequest, HttpServletResponse and
> > > DeploymentDescriptor. Enough access to cause just about all the
trouble
> > you
> > > could want. From what I can tell, the feature is not obviously
> > documented;
> > > I had a vague memory of it from the mail list and found a reference to
> it
> > in
> > > the changes document.
> > >
> > > If you believe that the feature as implemented could be improved, we
> would
> > > welcome your input. Also, if you are perusing around for some coding
> > task,
> > > let me know and we'll see if we can find something appropriate.
> > >
> > > Thanks for your participation, past and I hope future.
> > >
> > > Scott Nichol
> > >
> > > ----- Original Message -----
> > > From: "Michael Jennings" <[EMAIL PROTECTED]>
> > > To: <[EMAIL PROTECTED]>
> > > Sent: Monday, June 17, 2002 12:54
> > > Subject: Re: TODO list item
> > >
> > >
> > > > Thanks!
> > > > -Mike
> > > >
> > > > ----- Original Message -----
> > > > From: "Scott Nichol" <[EMAIL PROTECTED]>
> > > > To: <[EMAIL PROTECTED]>
> > > > Sent: Monday, June 17, 2002 9:25 AM
> > > > Subject: Re: TODO list item
> > > >
> > > >
> > > > > I'll have a look now.
> > > > >
> > > > > Scott Nichol
> > > > >
> > > > > ----- Original Message -----
> > > > > From: "Michael Jennings" <[EMAIL PROTECTED]>
> > > > > To: <[EMAIL PROTECTED]>
> > > > > Sent: Monday, June 17, 2002 11:13
> > > > > Subject: TODO list item
> > > > >
> > > > >
> > > > > > Hi,
> > > > > >
> > > > > > Has anyone had a chance to take a look at my diff that I
submitted
> > May
> > > > > 29th?
> > > > > > -Mike
> > > > > > ______________________
> > > > > > Mike Jennings
> > > > > > Southgate Software Ltd.
> > > > > > 250-382-6851 (tel)
> > > > > > 250-382-6800 (fax)
> > > > > > [EMAIL PROTECTED]
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>
