Jason van Zyl wrote:
On Thu, 2002-07-25 at 09:27, Stephen McConnell wrote:
Jason van Zyl wrote:
Actually I was thinking about dragging this in via an Avalon configuration instance.On Wed, 2002-07-24 at 20:18, Stephen McConnell wrote:
Could anyone provide some thoughts about the configuration approach for Sevak - as things stand at the moment the implementation is basically setting up an embeded tomcat service, a host, connector, etc as part of the initialize method. It would seem to make more sense to suck in a configuration basically equivalent to the <service/> element in the Tomcat server.xml file and build up the hosts, connectors, ... from there.
Am I on the right track here ?
You could ask the tomcat crew to make easily available their configuration mechanism so you can use the same tool (Digester) to parse the catalina configuration files. For turbine this would be useful: people could easily flip from using servlet container stand-alone to using an avalon container as _the_ container.
For something as complicated as Catalina does that really make sense?
It's because Catalina is so complicated that the reason exists!
There will undoubtedly be mismatches and if the configuration options
change in Catalina then you are forced to update your configuration
mechanism.
That's the down-side.
I realize in a lot of cases that the Avalon configuration mechanism makes sense but in this case I think you would simplify things by using what's there.
That will enable management of default configurations
What about a default Catalina configuration file?
and generally a massive simplification of the deployment process for the end-user
What if the end user is accustomed to configuring Catalina in the standard fashion? Catalina is also JMX and it provides an interface for setting up contexts and connection/protocol handlers and all that jazz.
(via cascading configs and packaged profiles).
Sorry, not up on cascading configs and packaged profiles but I assume you are talking about running multiple instances of the embedded server with slightly different options in the configuration, yes? If so, I don't really see this being a highly utilized use case as opposed deploying multiple webapps inside a single Catalina instance. If not, then please explain further.
Ok, here's the explination. If the configuration used the CascadingConfiguration model, your can put in place a complext configuration as a default and allow another configuration to override it. For example - if I want to use out-of-the-box server.xml - but I need to check the port from 8080 to 80 and the host from localhost to home.osm.net (and that all) - then my deployment configuration includes just those two attributes in a set of basically empty elements. The advantage of this is that the user can completely override a default if they choose - but the more classic scenrio is that only a very samll number of changes are required - and the changes get isolated and beocme much easier to manager.
Second aspect is packaged profiles. A profile describes the instantiation criteria for a component. This includes a reference to a configuration, context directives and other stuff. Packaged profiles are basically a set of profiles associated and packaged with a particular component type (class) that meet a particular style of usage - e.g. a HTTP server on 80 and SSL on something else - etc. On deployment the user's setup can select a breconfigured profile and make mionor adjustments using the cascading configuration framework.
Impact at the end of the day is that user's changes are totally isolated (great for support), user's changes are captured in an easily understandable "small" unit - (user's make less errors), and finally, the pre-packaged profiles enable a much better approach to well prepared and complete real-deployment examples across multiple scenarios.
Or possibly allow both. I know that I'm looking for a way for users to move easily from using Catalina stand-alone to using Catalina within an Avalon container and I'm not going to make users learn another configuration or management mechanism.
I agree - I'm not suggesting anything different in the configuration schema - this is simply a case of providing management of the configurations in a manner that reduces the customer/support overhead.
Steve.
--
Stephen J. McConnell
OSM SARL digital products for a global economy mailto:[EMAIL PROTECTED] http://www.osm.net
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
--
Stephen J. McConnell
OSM SARL digital products for a global economy mailto:[EMAIL PROTECTED] http://www.osm.net
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
