Anne Thomas Manes wrote:
True. JAX-RPC servers are only required to support Servlet 2.3, and "Servlet containers that are not part of a J2EE technology compliant implementation are encouraged, but not required, to implement the application environment functionality described in the J2EE specification."One problem with this theory. The target platform for JAX-RPC (per JSR 101) is J2SE. It will be included in J2EE 1.4, but it doesn't require J2EE.Anne
However, the problems I described with putting environment-specific config in your webapp remain in a J2SE environment. J2SE doesnt try to tackle this problem, I guess the best you can do is use system properties to get your per-container bootstrap configuration, instead of JNDI. eg. -Dmy.axis.config.db=jdbc:blah:blah@blah/blah, or -Dmy.axis.config.file=C:\banana\monkey.properties , then do something app-specific from there on.
Cheers,
Baz
-----Original Message----- From: Brian Ewins [mailto:[EMAIL PROTECTED]] Sent: Wednesday, January 15, 2003 8:39 AM To: [EMAIL PROTECTED] Subject: Re: Web services configuration? From the J2EE standpoint: As JAXRPC is part of the J2EE stack, you're supposed to use JNDI for configuring a service to know about the environment it is running in; though there are other kinds of config. Envrironment-specific configuration is something you shouldn't put in a web.xml, or anywhere else in your .war[1]. If you do so, you will need to edit the contents of the .war after deployment, or create multiple builds. This means that either upgrades will overwrite your config, or that your test build is not the same as your live build - recipes for disaster. On the other hand, the web.xml and/or properties files are exactly the right place to describe how to assemble components into an application - all the config thats independent of the environment you are deploying into. In our apps, we use a mix of properties files and web.xml for things done in the J2EE 'Application Assembler' role. At deployment time (ie in the 'Deployer' role) we use JNDI to fetch a small amout of read-only info[2], usually just DB connection details, so the app can get up and running. Once running, we use our own database backed code to grab config (the stuff done in the J2EE 'System Administrator' role). Runtime config is supposed to be done by JMX, but JMX says nothing about persistence of configuration (other than 'use EJBs', I suppose), and tool support for JMX isnt great yet. I had kinda hoped the Preferences API would have helped here but it doesnt fit at all well with web apps. Anyway, I rambled a bit, but my point was that it helps to think which bits of your config would be done by each role in the J2EE spec; J2EE uses the deployment descriptor, JNDI, and JMX respectively for the three kinds of config, but JMX support isnt mature. Cheers, Baz [1] An example of a mistake like this is that the datasource config in Struts 1.0's struts-config.xml. This is a disaster waiting to happen, because it /demands/ that your struts-config files are different on each server you deploy your webapp. [2] Things may have changed here, but IIRC the most recent servlet spec still only allows you to rely on read-only JNDI. BTW, I centralise access to JNDI config in my app setup; most of classes are 'pushed' config, rather than pulling it from JNDI, for reasons similar to those described here: http://jakarta.apache.org/avalon/framework/guide-patterns-ioc.html and because it is easier to unit test classes if you work this way. Julia Tertyshnaya wrote:Hello everybody, is there some standard way to configure web services at startup (setting some params)? Does Axis provide some means for that? Thanks for help, Julia
