Jeff Turner wrote on 8/22/01 6:39 pm:
>On Wed, Aug 22, 2001 at
>05:59:05PM -0500, Morgan
>Delagrange wrote: Hi all,
>>
>> I doubt many people out
>there are really aware of
>Latka right now :). However,
>in case anyone out there is
>experimenting with it right
>now, I'm working on
>improving the methods for
>configuring Latka, and I want
>to give the oppportunity for
>feedback.
>>
>> Today I removed Latka's
>ability to configure its
>variables from System
>properties. I've replaced it
>with a ThreadLocal
>reference to a Properties
>object, which should make
>configuration of Latka more
>threadsafe while still making
>it easy to get at Properties
>anywhere in the application.
>Now I'm pondering how best
>to set those properties from
>the command-line interface.
>Perhaps something like:
>>
>> java -
>Dlatka.userProps=<path to
>prop file>
>org.apache.commons.latka.L
>atka
>> <path to Latka XML file>
>[<latka property> <latka
>property> ...]
>
>Perhaps adopting log4j's
>strategy would work, where
>if a config file is not
>specified, a default
>latka.properties is searched
>for in the classpath. This is
>overridable from the
>command-line of course. The
>relevant code is in
>o.a.log4j.Category. I'd do a
>straight cut'n'paste ;)
Funny you should mention that. There is a latka.properties file packaged inside the
Latka jar that works just that way. That's where the list of pluggable validators is
read. Theoretically putting another latka.properties file before it in the classpath
would override it.
I'm not sure that's quite what we want here though. The Log4J properties file
basically assumes the same configuration for all threads, but I'm anticipating a Latka
webapp that will have different properties pe thread. So I'm a little hesitant
reading user-specific properties from the classpath. That why right now I incline
towards specifying the path to a prop file in the command-line interface. But maybe
we could read from the classpath under certain circumstances, as long as there is
still a potential for thread safety.
>Also, how are custom
>Validators to be configured,
>if System.getProperties(..) is
>no longer the mechanism?
>Perhaps there should be a
>method added to
>o.a.c.latka.Validator, to
>define the option-passing
>contract? Or perhaps simply
>stealing ideas, if not code,
>from log4j's configuration
>mechanism would be best
>(PropertyConfigurator,
>DOMConfigurator).
Currently you can do it by declaring your validation handler in the latka.properties
file inside latka.jar. I'm thinking that the "latka.*" configuration properties will
also be assignable from user prop files and the command line, but it's a bit early to
say.
>--Jeff
>
>(who would like to add a
>validate-returned-XML-
>against-a-DTD Validator if
>he ever gets time)
>
>[snip]
Sounds good!
- Morgan
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
