You are viewing a plain text version of this content. The canonical link for it is here.
Posted to soap-dev@xml.apache.org by Michael Jennings <mi...@southgatesoftware.com> on 2002/06/17 17:13:13 UTC
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)
mike@southgatesoftware.com
Re: TODO list item
Posted by Scott Nichol <sn...@scottnichol.com>.
Not there yet, but it *will* be.
Scott
----- Original Message -----
From: "Michael Jennings" <mi...@southgatesoftware.com>
To: <so...@xml.apache.org>
Sent: Monday, June 24, 2002 5:01 PM
Subject: Re: TODO list item
> So it's there? Cool!
> -Mike
>
> ----- Original Message -----
> From: "Scott Nichol" <sn...@scottnichol.com>
> To: <so...@xml.apache.org>
> 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" <mi...@southgatesoftware.com>
> > To: <so...@xml.apache.org>
> > 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" <sn...@scottnichol.com>
> > > To: <so...@xml.apache.org>
> > > 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" <mi...@southgatesoftware.com>
> > > > To: <so...@xml.apache.org>
> > > > 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: <ma...@xml.apache.org>
> > > For additional commands, e-mail: <ma...@xml.apache.org>
> > >
> > >
> >
> >
> > --
> > To unsubscribe, e-mail: <ma...@xml.apache.org>
> > For additional commands, e-mail: <ma...@xml.apache.org>
> >
> >
>
>
> --
> To unsubscribe, e-mail: <ma...@xml.apache.org>
> For additional commands, e-mail: <ma...@xml.apache.org>
>
>
Re: TODO list item
Posted by Scott Nichol <sn...@scottnichol.com>.
Not there yet, but it *will* be.
Scott
----- Original Message -----
From: "Michael Jennings" <mi...@southgatesoftware.com>
To: <so...@xml.apache.org>
Sent: Monday, June 24, 2002 5:01 PM
Subject: Re: TODO list item
> So it's there? Cool!
> -Mike
>
> ----- Original Message -----
> From: "Scott Nichol" <sn...@scottnichol.com>
> To: <so...@xml.apache.org>
> 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" <mi...@southgatesoftware.com>
> > To: <so...@xml.apache.org>
> > 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" <sn...@scottnichol.com>
> > > To: <so...@xml.apache.org>
> > > 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" <mi...@southgatesoftware.com>
> > > > To: <so...@xml.apache.org>
> > > > 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: <ma...@xml.apache.org>
> > > For additional commands, e-mail: <ma...@xml.apache.org>
> > >
> > >
> >
> >
> > --
> > To unsubscribe, e-mail: <ma...@xml.apache.org>
> > For additional commands, e-mail: <ma...@xml.apache.org>
> >
> >
>
>
> --
> To unsubscribe, e-mail: <ma...@xml.apache.org>
> For additional commands, e-mail: <ma...@xml.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@xml.apache.org>
For additional commands, e-mail: <ma...@xml.apache.org>
Re: TODO list item
Posted by Michael Jennings <mi...@southgatesoftware.com>.
So it's there? Cool!
-Mike
----- Original Message -----
From: "Scott Nichol" <sn...@scottnichol.com>
To: <so...@xml.apache.org>
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" <mi...@southgatesoftware.com>
> To: <so...@xml.apache.org>
> 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" <sn...@scottnichol.com>
> > To: <so...@xml.apache.org>
> > 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" <mi...@southgatesoftware.com>
> > > To: <so...@xml.apache.org>
> > > 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: <ma...@xml.apache.org>
> > For additional commands, e-mail: <ma...@xml.apache.org>
> >
> >
>
>
> --
> To unsubscribe, e-mail: <ma...@xml.apache.org>
> For additional commands, e-mail: <ma...@xml.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@xml.apache.org>
For additional commands, e-mail: <ma...@xml.apache.org>
Re: TODO list item
Posted by Michael Jennings <mi...@southgatesoftware.com>.
So it's there? Cool!
-Mike
----- Original Message -----
From: "Scott Nichol" <sn...@scottnichol.com>
To: <so...@xml.apache.org>
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" <mi...@southgatesoftware.com>
> To: <so...@xml.apache.org>
> 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" <sn...@scottnichol.com>
> > To: <so...@xml.apache.org>
> > 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" <mi...@southgatesoftware.com>
> > > To: <so...@xml.apache.org>
> > > 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: <ma...@xml.apache.org>
> > For additional commands, e-mail: <ma...@xml.apache.org>
> >
> >
>
>
> --
> To unsubscribe, e-mail: <ma...@xml.apache.org>
> For additional commands, e-mail: <ma...@xml.apache.org>
>
>
Re: TODO list item
Posted by Scott Nichol <sn...@scottnichol.com>.
Yes, in modified form with the additional properties sources (e.g.
deployment descriptor).
Scott
----- Original Message -----
From: "Michael Jennings" <mi...@southgatesoftware.com>
To: <so...@xml.apache.org>
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" <sn...@scottnichol.com>
> To: <so...@xml.apache.org>
> 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" <mi...@southgatesoftware.com>
> > To: <so...@xml.apache.org>
> > 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: <ma...@xml.apache.org>
> For additional commands, e-mail: <ma...@xml.apache.org>
>
>
Re: TODO list item
Posted by Scott Nichol <sn...@scottnichol.com>.
Yes, in modified form with the additional properties sources (e.g.
deployment descriptor).
Scott
----- Original Message -----
From: "Michael Jennings" <mi...@southgatesoftware.com>
To: <so...@xml.apache.org>
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" <sn...@scottnichol.com>
> To: <so...@xml.apache.org>
> 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" <mi...@southgatesoftware.com>
> > To: <so...@xml.apache.org>
> > 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: <ma...@xml.apache.org>
> For additional commands, e-mail: <ma...@xml.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@xml.apache.org>
For additional commands, e-mail: <ma...@xml.apache.org>
Re: TODO list item
Posted by Michael Jennings <mi...@southgatesoftware.com>.
Hi Scott,
Any chance of that diff making it into the codebase?
(in whatever form)
-Mike
----- Original Message -----
From: "Scott Nichol" <sn...@scottnichol.com>
To: <so...@xml.apache.org>
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" <mi...@southgatesoftware.com>
> To: <so...@xml.apache.org>
> 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: <ma...@xml.apache.org>
For additional commands, e-mail: <ma...@xml.apache.org>
Re: TODO list item
Posted by Michael Jennings <mi...@southgatesoftware.com>.
Hi Scott,
Any chance of that diff making it into the codebase?
(in whatever form)
-Mike
----- Original Message -----
From: "Scott Nichol" <sn...@scottnichol.com>
To: <so...@xml.apache.org>
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" <mi...@southgatesoftware.com>
> To: <so...@xml.apache.org>
> 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
>
>
>
Re: TODO list item
Posted by Scott Nichol <sn...@scottnichol.com>.
See my comments below. If any other committers would like to comment,
please do so soon. Thanks.
Scott Nichol
----- Original Message -----
From: "Michael Jennings" <mi...@southgatesoftware.com>
To: <so...@xml.apache.org>
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
Re: TODO list item
Posted by Scott Nichol <sn...@scottnichol.com>.
See my comments below. If any other committers would like to comment,
please do so soon. Thanks.
Scott Nichol
----- Original Message -----
From: "Michael Jennings" <mi...@southgatesoftware.com>
To: <so...@xml.apache.org>
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
Re: TODO list item
Posted by Michael Jennings <mi...@southgatesoftware.com>.
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" <sn...@scottnichol.com>
To: <so...@xml.apache.org>
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" <mi...@southgatesoftware.com>
> To: <so...@xml.apache.org>
> 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" <sn...@scottnichol.com>
> > To: <so...@xml.apache.org>
> > 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" <mi...@southgatesoftware.com>
> > > To: <so...@xml.apache.org>
> > > Sent: Monday, June 17, 2002 12:54
> > > Subject: Re: TODO list item
> > >
> > >
> > > > Thanks!
> > > > -Mike
> > > >
> > > > ----- Original Message -----
> > > > From: "Scott Nichol" <sn...@scottnichol.com>
> > > > To: <so...@xml.apache.org>
> > > > 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" <mi...@southgatesoftware.com>
> > > > > To: <so...@xml.apache.org>
> > > > > 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)
> > > > > > mike@southgatesoftware.com
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>
Re: TODO list item
Posted by Michael Jennings <mi...@southgatesoftware.com>.
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" <sn...@scottnichol.com>
To: <so...@xml.apache.org>
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" <mi...@southgatesoftware.com>
> To: <so...@xml.apache.org>
> 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" <sn...@scottnichol.com>
> > To: <so...@xml.apache.org>
> > 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" <mi...@southgatesoftware.com>
> > > To: <so...@xml.apache.org>
> > > Sent: Monday, June 17, 2002 12:54
> > > Subject: Re: TODO list item
> > >
> > >
> > > > Thanks!
> > > > -Mike
> > > >
> > > > ----- Original Message -----
> > > > From: "Scott Nichol" <sn...@scottnichol.com>
> > > > To: <so...@xml.apache.org>
> > > > 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" <mi...@southgatesoftware.com>
> > > > > To: <so...@xml.apache.org>
> > > > > 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)
> > > > > > mike@southgatesoftware.com
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>
Re: TODO list item
Posted by Scott Nichol <sn...@scottnichol.com>.
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" <mi...@southgatesoftware.com>
To: <so...@xml.apache.org>
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" <sn...@scottnichol.com>
> To: <so...@xml.apache.org>
> 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" <mi...@southgatesoftware.com>
> > To: <so...@xml.apache.org>
> > Sent: Monday, June 17, 2002 12:54
> > Subject: Re: TODO list item
> >
> >
> > > Thanks!
> > > -Mike
> > >
> > > ----- Original Message -----
> > > From: "Scott Nichol" <sn...@scottnichol.com>
> > > To: <so...@xml.apache.org>
> > > 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" <mi...@southgatesoftware.com>
> > > > To: <so...@xml.apache.org>
> > > > 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)
> > > > > mike@southgatesoftware.com
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>
Re: TODO list item
Posted by Scott Nichol <sn...@scottnichol.com>.
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" <mi...@southgatesoftware.com>
To: <so...@xml.apache.org>
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" <sn...@scottnichol.com>
> To: <so...@xml.apache.org>
> 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" <mi...@southgatesoftware.com>
> > To: <so...@xml.apache.org>
> > Sent: Monday, June 17, 2002 12:54
> > Subject: Re: TODO list item
> >
> >
> > > Thanks!
> > > -Mike
> > >
> > > ----- Original Message -----
> > > From: "Scott Nichol" <sn...@scottnichol.com>
> > > To: <so...@xml.apache.org>
> > > 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" <mi...@southgatesoftware.com>
> > > > To: <so...@xml.apache.org>
> > > > 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)
> > > > > mike@southgatesoftware.com
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>
Re: TODO list item
Posted by Michael Jennings <mi...@southgatesoftware.com>.
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" <sn...@scottnichol.com>
To: <so...@xml.apache.org>
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" <mi...@southgatesoftware.com>
> To: <so...@xml.apache.org>
> Sent: Monday, June 17, 2002 12:54
> Subject: Re: TODO list item
>
>
> > Thanks!
> > -Mike
> >
> > ----- Original Message -----
> > From: "Scott Nichol" <sn...@scottnichol.com>
> > To: <so...@xml.apache.org>
> > 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" <mi...@southgatesoftware.com>
> > > To: <so...@xml.apache.org>
> > > 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)
> > > > mike@southgatesoftware.com
> > > >
> > > >
> > >
> > >
> >
> >
>
>
Re: TODO list item
Posted by Michael Jennings <mi...@southgatesoftware.com>.
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" <sn...@scottnichol.com>
To: <so...@xml.apache.org>
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" <mi...@southgatesoftware.com>
> To: <so...@xml.apache.org>
> Sent: Monday, June 17, 2002 12:54
> Subject: Re: TODO list item
>
>
> > Thanks!
> > -Mike
> >
> > ----- Original Message -----
> > From: "Scott Nichol" <sn...@scottnichol.com>
> > To: <so...@xml.apache.org>
> > 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" <mi...@southgatesoftware.com>
> > > To: <so...@xml.apache.org>
> > > 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)
> > > > mike@southgatesoftware.com
> > > >
> > > >
> > >
> > >
> >
> >
>
>
Re: TODO list item
Posted by Scott Nichol <sn...@scottnichol.com>.
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" <mi...@southgatesoftware.com>
To: <so...@xml.apache.org>
Sent: Monday, June 17, 2002 12:54
Subject: Re: TODO list item
> Thanks!
> -Mike
>
> ----- Original Message -----
> From: "Scott Nichol" <sn...@scottnichol.com>
> To: <so...@xml.apache.org>
> 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" <mi...@southgatesoftware.com>
> > To: <so...@xml.apache.org>
> > 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)
> > > mike@southgatesoftware.com
> > >
> > >
> >
> >
>
>
Re: TODO list item
Posted by Scott Nichol <sn...@scottnichol.com>.
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" <mi...@southgatesoftware.com>
To: <so...@xml.apache.org>
Sent: Monday, June 17, 2002 12:54
Subject: Re: TODO list item
> Thanks!
> -Mike
>
> ----- Original Message -----
> From: "Scott Nichol" <sn...@scottnichol.com>
> To: <so...@xml.apache.org>
> 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" <mi...@southgatesoftware.com>
> > To: <so...@xml.apache.org>
> > 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)
> > > mike@southgatesoftware.com
> > >
> > >
> >
> >
>
>
Re: TODO list item
Posted by Michael Jennings <mi...@southgatesoftware.com>.
Thanks!
-Mike
----- Original Message -----
From: "Scott Nichol" <sn...@scottnichol.com>
To: <so...@xml.apache.org>
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" <mi...@southgatesoftware.com>
> To: <so...@xml.apache.org>
> 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)
> > mike@southgatesoftware.com
> >
> >
>
>
Re: TODO list item
Posted by Michael Jennings <mi...@southgatesoftware.com>.
Thanks!
-Mike
----- Original Message -----
From: "Scott Nichol" <sn...@scottnichol.com>
To: <so...@xml.apache.org>
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" <mi...@southgatesoftware.com>
> To: <so...@xml.apache.org>
> 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)
> > mike@southgatesoftware.com
> >
> >
>
>
Re: TODO list item
Posted by Scott Nichol <sn...@scottnichol.com>.
I'll have a look now.
Scott Nichol
----- Original Message -----
From: "Michael Jennings" <mi...@southgatesoftware.com>
To: <so...@xml.apache.org>
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)
> mike@southgatesoftware.com
>
>
Re: TODO list item
Posted by Scott Nichol <sn...@scottnichol.com>.
I'll have a look now.
Scott Nichol
----- Original Message -----
From: "Michael Jennings" <mi...@southgatesoftware.com>
To: <so...@xml.apache.org>
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)
> mike@southgatesoftware.com
>
>