[axis] Please help me review list of axis properties and how they are handled...

[rs...@us.ibm.com]

The question before me is how best to configure AXIS, given the following 
assumptions:

- keep developers GOING
- satisfy admin
- AXIS standalone
- AXIS in J2EE environs (multiple instances, multiple configs...)
--  AXIS in base app server (axis.jar shared by everyone)
--  AXIS in webapp (axis.jar packaged in each webapp)

I've gone back to look at how the properties are actually used, and I 
wanted to present the results of my analysis, and my thoughts.  I'd 
appreciate votes for/against each point.

First, a summary list of all properties that I found accessed by 
System.getProperty (now AxisProperties.getProperty).  I figure we can work 
through OTHER properties later.  The list:
     axis.attachments.Directory
     axis.EngineConfigFactory
     axis.ClientConfigFile
     axis.ServerConfigFile
     axis.Compiler
     axis.engineConfigClass
     axis.Extractor
     axis.socketFactory
     axis.socketSecureFactory
     axis.ServerFactory
     axis.attachments.implementation
     axis.enableListQuery
     axis.jws.servletClassDir
     axis.production-system
     use-servlet-security
     transport.name
     java.protocol.handler.pkgs
     sun.boot.class.path
     user.home
     http.proxyHost
     http.proxyPort
     http.proxyUser
     http.proxyPassword
     http.nonProxyHosts
     https.proxyHost
     https.proxyPort
     https.proxyUser
     https.proxyPassword
     https.nonProxyHosts


Following is how I think these could/should be used & configured.

In a webapplication, some of these make sense as system-wide 
(cross-application) properties, I THINK.  I'm breaking that (SHORT) list 
out here (it is inappropriate to override these with AXIS configuration, 
these shouldn't be 'set' by AXIS or have much broader scope).  These will 
be wired BACK to System.getProperty():

     sun.boot.class.path
     java.protocol.handler.pkgs
     user.home   ? It might make sense to allow this to be overridden by 
config...
                   do we want to do that?


The following are used by AxisServlet.  Their values can be obtained from 
System.getProperty (via AxisProperties), HttpServlet.getInitParameter(), 
and ServletContext.getInitParameter().  I believe that these are best left 
alone:
     axis.enableListQuery
     axis.jws.servletClassDir
     use-servlet-security
     transport.name

The following is also used by AxisServlet:

     axis.production-system

          I'm not a fan of this one :-(   It's used ONLY in AdminServlet,
          and I'd like to move it's visibility UP to there if we keep it.
          That would satisfy my sensibilities, because we are not using
          AdminServlet.
          However, I would propose a pluggable command processor, default
          as-is for development, provide a no-op.

I propose to handle the remaining as follows:

     http.proxyHost
     http.proxyPort
     http.proxyUser
     http.proxyPassword
     http.nonProxyHosts
     https.proxyHost
     https.proxyPort
     https.proxyUser
     https.proxyPassword
     https.nonProxyHosts

          These are used by the CommonsHTTPSender and 
DefaultSocketFactory.
          Replace with pluggable component (TBD) that can obtain these 
values.
          [does it make sense 
          Default: use EngineConfiguration (if I cannot get that easily 
from
                   CommonsHTTPSender or DefaultSocketFactory then will 
have
                   to do some re-wiring.



These remainder I see as 'tricky' ones... they are in the AXIS core, and 
so do NOT have visibility to the runtime environment the way AxisServlet 
does (rather, AxisServlet can make assumptions that AxisEngine can't).  On 
the other hand, we really need a way to set them per webapp/instance.  I'm 
going to break that list into two parts:

Properties we need to set per instance (i.e. by webapp), cannot be set by 
EngineConfiguration

     axis.EngineConfigFactory
     axis.engineConfigClass

          Proposed resolution: introduce a plugpoint into AxisProperties
          that allows us to plug a config source in, such as
          HttpServlet.getInitParameter, ServletContext.getInitParameter(),
          Property files, others.   Noting that AxisProperties MAY be
          installed in the app servers library, and loaded by a 
classloader
          common to all webapps, AxisProperties will cache these
          property sources by thread-context-class-loader.
          (that is the quick-fix - the REAL fix is to link everything back
          to AxisEngine where this type of thing can be stored locally...)

Properties we can (and should) obtain from EngineConfiguration instead of, 
or in addition to, AxisProperties:

     axis.ClientConfigFile
     axis.ServerConfigFile

     axis.Compiler
     axis.Extractor
     axis.socketFactory
     axis.socketSecureFactory
     axis.ServerFactory

     axis.attachments.Directory
     axis.attachments.implementation

          Using the plug-point introduced above, plug EngineConfiguration
          properties in with everything else...


*******************************************
Richard A. Sitze
IBM WebSphere WebServices Development

Re: [axis] Please help me review list of axis properties and how they are handled...

[Steve Loughran <st...@iseran.com>]

+1 for a plug point for new config systems; I dont like web.xml config as it
means generating a new war for every system, and rebuilding the war for
every change.

I've used dynamic config based on hostname in the past with a separate xml
file for each supported host, but like things like LDAP/JNDI for a cluster
(replicating the LDAP server to every cluster node for robustness). It would
be good if *all* settings could be driven from a single place. Of course,
that is its own config/boot problem.

+1 to documenting this all in one place. Putting all the property
declarations in one standalone class and javadocing that would be a start.

----- Original Message -----


> The following are used by AxisServlet.  Their values can be obtained from
> System.getProperty (via AxisProperties), HttpServlet.getInitParameter(),
> and ServletContext.getInitParameter().  I believe that these are best left
> alone:
>      axis.enableListQuery

email to me this week implies this switch does not work; we need to test it

>      axis.jws.servletClassDir
>      use-servlet-security
>      transport.name
>
> The following is also used by AxisServlet:
>
>      axis.production-system
>
>           I'm not a fan of this one :-(   It's used ONLY in AdminServlet,
>           and I'd like to move it's visibility UP to there if we keep it.
>           That would satisfy my sensibilities, because we are not using
>           AdminServlet.

see previous comments. What I really want is a single insecure-dev;
secure-production switch that flips the entire system into paranoid mode,
not twenty different options as with IIS config.


we also have an implicit configuration of the log4j stuff, with known issues
about configuration of that -it should go from axis,jar and be left to
individual developers.
>           However, I would propose a pluggable command processor, default
>           as-is for development, provide a no-op.

+1;

>           Proposed resolution: introduce a plugpoint into AxisProperties
>           that allows us to plug a config source in, such as
>           HttpServlet.getInitParameter, ServletContext.getInitParameter(),
>           Property files, others.   Noting that AxisProperties MAY be
>           installed in the app servers library, and loaded by a
> classloader
>           common to all webapps, AxisProperties will cache these
>           property sources by thread-context-class-loader.
>           (that is the quick-fix - the REAL fix is to link everything back
>           to AxisEngine where this type of thing can be stored locally...)
>


There was good stuart holloway article on config on develop.com recently;
one thing we may want to do is a jakarta version of the java1.4 properties
API for earlier java versions, one of those if-only-I-had-free time things
I'd like to do but wont as I havent.

NB; any way to do live property changes? You can do this with log4j polling
a file system, which is something we will implicitly enable once we rip out
log4j.properties,.