How do you handle this in ant? Assuming of course that you're coming
from ant, and that you've previously solved this problem.
Wayne
On 6/2/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> Although I could do this for log4j - what about other 3rd party
> frameworks that use classpath resources for configuration. Log4j was
> just kind of a stand-in for a more general condition.
>
> Do you end up having to spool up and configure all of those resources
> programmatically in order to externalize configuration?
>
> -> I have a somewhat similar issue to what you have.
>
> Can you elaborate? This might help my small brain think outside of the
> ant shaped box it is current encased in.
>
> Carlos
>
> -----Original Message-----
> From: Kris Nuttycombe [mailto:[EMAIL PROTECTED]
> Sent: Friday, June 02, 2006 12:35 PM
> To: Maven Users List
> Subject: Re: REPOST: [M2] external config of artifact and dependencies
>
> I'm not talking about manually setting up the appenders, etc - I'm just
> talking about configuring log4j from a properties file that can vary by
> the deployment environment (i.e, be called something other than
> log4j.properties.)
>
> I have a somewhat similar issue to what you have, except that I use the
> log4j xml dialect for configuration and consequently have to run
> DOMConfigurator.configure(...) on application startup. It seems to me
> that you could do something similar - you still get to configure by a
> properties instance, but this instance is then selectable at runtime
> (and potentially pulled from JNDI.)
>
> Kris
>
> [EMAIL PROTECTED] wrote:
>
> >It is more work than writing a properties file.
> >
> >Also, I am lazy.
> >
> >Which is probably why I want to use maven on my projects.
> >
> >Carlos
> >
> >-----Original Message-----
> >From: Kris Nuttycombe [mailto:[EMAIL PROTECTED]
> >Sent: Friday, June 02, 2006 11:51 AM
> >To: Maven Users List
> >Subject: Re: REPOST: [M2] external config of artifact and dependencies
> >
> >Out of curiosity, why is programmatically configuring log4j (say in a
> >servlet context listener) not a great idea?
> >
> >Kris
> >
> >[EMAIL PROTECTED] wrote:
> >
> >
> >
> >>I don't think my team will react nicely if I tell them that in order
> to
> >>have all the maven niceties we have to buy and run oracle app server
> or
> >>have half a dozen instances of tomcat running on our servers.
> >>
> >>Is this what people commonly do with maven built wars?
> >>
> >>What I am trying to figure out is rote for a lot of people out there.
> >>
> >>
> >I
> >
> >
> >>just can't get my pea-sized brain to come up with a palatable
> solution.
> >>
> >>-----Original Message-----
> >>From: Wayne Fay [mailto:[EMAIL PROTECTED]
> >>Sent: Friday, June 02, 2006 10:49 AM
> >>To: Maven Users List
> >>Subject: Re: REPOST: [M2] external config of artifact and dependencies
> >>
> >>One suggestion would be to use an app server that allows instancing of
> >>webapps.
> >>
> >>We run Oracle App Server, and each webapp is deployed to its own OC4J
> >>instance. Each OC4J instance has its own full directory structure
> >>which allows us to copy things like log4j.properties files and other
> >>configuration files into specific webapp directories. So webapp1 has
> >>its own webapp1/shared/classes type directory and webapp2 has
> >>webapp2/shared/classes. They run in completely separated memory so
> >>there is no issue of one app accessing the other's log4 configuration
> >>file.
> >>
> >>In Tomcat, you could do this too, but you'd be to run individual
> >>Tomcat instances for each webapp.
> >>
> >>This would allow you to maintain a single "build" of your code with
> >>different configurations for each deployment.
> >>
> >>Wayne
> >>
> >>On 6/2/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]>
> >>wrote:
> >>
> >>
> >>
> >>
> >>>Sorry - about the repost, but my 10 month old daughter has taught me
> >>>that the crying wheel gets fed . . . or something like that.
> >>>
> >>>Let's say I am working on a web application.
> >>>
> >>>This application is a maven project configured as a war. During its
> >>>lifecycle this application will be deployed on:
> >>>
> >>>- developer workstations
> >>>- testing environment
> >>>- production environment
> >>>
> >>>This project has a dependency on log4j.
> >>>
> >>>At runtime, my application code is configured to pull properties
> files
> >>>with configuration information from a well-known JNDI location. The
> >>>prop file will include environment specific settings. At deployment
> >>>time, the engineer responsible for generating the war will, if
> >>>necessary, also update the prop file (or individual properties) in
> the
> >>>JNDI tree.
> >>>
> >>>log4j however, looks for its configuration file on the classpath at
> >>>application initialization. Although you can configure log4j
> >>>programmatically, that probably isn't a great idea. log4j is
> >>>
> >>>
> >>>
> >>>
> >>configured
> >>
> >>
> >>
> >>
> >>>differently for each target environment. E.g. Developers will change
> >>>settings based on what they are currently working on, the testing
> >>>environment is set to DEBUG while production is set to WARN.
> >>>
> >>>I don't want to filter the log4j configuration file when I package
> the
> >>>artifact. Doing so would place environment specific settings in the
> >>>archive, compromising its value. I can't use JNDI to configure
> log4j.
> >>>So that seems to leave "adding it to the classpath" as the only
> viable
> >>>option. Our app servers are tomcat 5.x. Although I have the option
> >>>
> >>>
> >>>
> >>>
> >>to
> >>
> >>
> >>
> >>
> >>>drop the log4 files in <TomcatRoot>/shared/classes, that is the
> >>>
> >>>
> >>>
> >>>
> >>nuclear
> >>
> >>
> >>
> >>
> >>>bomb of config. Doing so may impact other web applications, if they
> >>>don't have their own version of the resource locally. Moreover, it
> >>>
> >>>
> >>>
> >>>
> >>can
> >>
> >>
> >>
> >>
> >>>only be done for a single application - I can't have two different
> >>>log4j.properties files in the shared/classes dir.
> >>>
> >>>So now I have to alter the exploded web application directory after
> it
> >>>is installed and add the log4j.properties file.
> >>>
> >>>That seems like a great deal of work and a kludge . . . what am I
> >>>missing here?
> >>>
> >>>-----Original Message-----
> >>>From: Fernandez, Carlos
> >>>Sent: Thursday, June 01, 2006 10:49 AM
> >>>To: users@maven.apache.org
> >>>Subject: RE: [M2] questions about migrating to maven
> >>>
> >>>Carlos,
> >>>
> >>>EXTERNAL CONFIGURATION OF AN ARTIFACT AND DEPENDENCIES
> >>>
> >>>Sorry for belaboring this point - but I tend to think better in
> >>>
> >>>
> >>>
> >>>
> >>concrete
> >>
> >>
> >>
> >>
> >>>terms. Let me walk through a scenario just to make sure I understand
> >>>this.
> >>>
> >>>Let's say I am working on a web application.
> >>>
> >>>This application is a maven project configured as a war. During its
> >>>lifecycle this application will be deployed on:
> >>>
> >>>- developer workstations
> >>>- testing environment
> >>>- production environment
> >>>
> >>>This project has a dependency on log4j.
> >>>
> >>>At runtime, my application code is configured to pull properties
> files
> >>>with configuration information from a well-known JNDI location. The
> >>>prop file will include environment specific settings. At deployment
> >>>time, the engineer responsible for generating the war will, if
> >>>necessary, also update the prop file (or individual properties) in
> the
> >>>JNDI tree.
> >>>
> >>>log4j however, looks for its configuration file on the classpath at
> >>>application initialization. Although you can configure log4j
> >>>programmatically, that probably isn't a great idea. log4j is
> >>>
> >>>
> >>>
> >>>
> >>configured
> >>
> >>
> >>
> >>
> >>>differently for each target environment. E.g. Developers will change
> >>>settings based on what they are currently working on, the testing
> >>>environment is set to DEBUG while production is set to WARN.
> >>>
> >>>I don't want to filter the log4j configuration file when I package
> the
> >>>artifact. Doing so would place environment specific settings in the
> >>>archive, compromising its value. I can't use JNDI to configure
> log4j.
> >>>So that seems to leave "adding it to the classpath" as the only
> viable
> >>>option. Our app servers are tomcat 5.x. Although I have the option
> >>>
> >>>
> >>>
> >>>
> >>to
> >>
> >>
> >>
> >>
> >>>drop the log4 files in <TomcatRoot>/shared/classes, that is the
> >>>
> >>>
> >>>
> >>>
> >>nuclear
> >>
> >>
> >>
> >>
> >>>bomb of config. Doing so may impact other web applications, if they
> >>>don't have their own version of the resource locally. Moreover, it
> >>>
> >>>
> >>>
> >>>
> >>can
> >>
> >>
> >>
> >>
> >>>only be done for a single application - I can't have two different
> >>>log4j.properties files in the shared/classes dir.
> >>>
> >>>So now I have to alter the exploded web application directory after
> it
> >>>is installed and add the log4j.properties file.
> >>>
> >>>That seems like a great deal of work and a kludge . . . what am I
> >>>missing here?
> >>>
> >>>BTW - My father's family is from Galicia, with a lot of them living
> in
> >>>
> >>>
> >>>
> >>>
> >>a
> >>
> >>
> >>
> >>
> >>>coruna. My parents have been a few times and have loved each and
> >>>
> >>>
> >>>
> >>>
> >>every
> >>
> >>
> >>
> >>
> >>>trip. I hope to visit with my wife and daughter soon, and see a bit
> >>>
> >>>
> >>>
> >>>
> >>of
> >>
> >>
> >>
> >>
> >>>the "old country" ;)
> >>>
> >>>Carlos
> >>>
> >>>-----Original Message-----
> >>>From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
> >>>
> >>>
> >>>
> >>>
> >>Carlos
> >>
> >>
> >>
> >>
> >>>Sanchez
> >>>Sent: Tuesday, May 30, 2006 12:50 PM
> >>>To: Maven Users List
> >>>Subject: Re: [M2] questions about migrating to maven
> >>>
> >>>On 5/30/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]>
> >>>wrote:
> >>>
> >>>
> >>>
> >>>
> >>>>Carlos,
> >>>>
> >>>>--> re FILTERING PROPERTIES FILES FOR ENVIRONMENTS
> >>>>My suggestion is to externalie that configuration options in a way
> >>>>that your artifact is always the same, and only configuration
> >>>>
> >>>>
> >>>>
> >>>>
> >>changes.
> >>
> >>
> >>
> >>
> >>>>You can do reading your config files from the classpath or better
> >>>>using JNDI.
> >>>>
> >>>>++++++++++++++++++++
> >>>>
> >>>>Sorry to harp on this, but I think I am having trouble thinking
> >>>>
> >>>>
> >>>>
> >>>>
> >>beyond
> >>
> >>
> >>
> >>
> >>>>the way I have used ant the past few years.
> >>>>
> >>>>100% of the differences between the developer workstation,
> >>>>pre-production and production builds on my various projects are
> >>>>
> >>>>
> >>>>
> >>>>
> >>>isolated
> >>>
> >>>
> >>>
> >>>
> >>>>into properties files. These are then pulled into Spring as
> >>>>
> >>>>
> >>>>
> >>>>
> >>classpath
> >>
> >>
> >>
> >>
> >>>>resources.
> >>>>
> >>>>If I understand you correctly, you are suggesting that the project
> >>>>artifacts, wars and jars alike, should not include these properties
> >>>>files. These files should either:
> >>>>
> >>>>- be accessed as classpath resource. Presumably some other
> >>>>build/release process would deposit them on the classpath, or they
> >>>>
> >>>>
> >>>>
> >>>>
> >>>would
> >>>
> >>>
> >>>
> >>>
> >>>>be added to the container's classpath at startup.
> >>>>- accessed via JNDI. The JNDI entries would either be name/value
> >>>>
> >>>>
> >>>>
> >>>>
> >>>pairs,
> >>>
> >>>
> >>>
> >>>
> >>>>the properties files themselves or a combo. When the war is
> >>>>
> >>>>
> >>>>
> >>>>
> >>deployed,
> >>
> >>
> >>
> >>
> >>>>part of the deployment process would be to configure the JNDI tree.
> >>>>
> >>>>Is this correct?
> >>>>
> >>>>
> >>>>
> >>>>
> >>>Yes, that way you don't need different artifacts for each
> environment,
> >>>reducing the risks.
> >>>
> >>>If you still want to do that you can use profiles to include/exclude
> >>>properties files in the jar, chnging the finalName so they are named
> >>>differently. I encourage the other option, but still you can do it
> >>>this way.
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>>--> re INTER-PROJECT DEPENDENCIES
> >>>>
> >>>>--> With maven the best way is not to rebuild all your dependencies
> >>>>every
> >>>>time, but to depend on the binaries generated by the other projects
> >>>>
> >>>>
> >>>>
> >>>>
> >>as
> >>
> >>
> >>
> >>
> >>>>SNAPSHOTs.
> >>>>
> >>>>If I can get past the environment configuration step - then I
> >>>>
> >>>>
> >>>>
> >>>>
> >>suspect
> >>
> >>
> >>
> >>
> >>>>that this would no longer be an issue. Each artifact would be
> >>>>
> >>>>
> >>>>
> >>>>
> >>generic
> >>
> >>
> >>
> >>
> >>>>and just as relevant on a developers workstation as it will be in
> >>>>production.
> >>>>
> >>>>Carlos
> >>>>
> >>>>-----Original Message-----
> >>>>From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
> >>>>
> >>>>
> >>>>
> >>>>
> >>>Carlos
> >>>
> >>>
> >>>
> >>>
> >>>>Sanchez
> >>>>Sent: Sunday, May 28, 2006 2:09 PM
> >>>>To: Maven Users List
> >>>>Subject: Re: [M2] questions about migrating to maven
> >>>>
> >>>>Hi Carlos,
> >>>>
> >>>>re FILTERING PROPERTIES FILES FOR ENVIRONMENTS
> >>>>
> >>>>I usually don't like this approach for the inconvinients you
> >>>>
> >>>>
> >>>>
> >>>>
> >>mention,
> >>
> >>
> >>
> >>
> >>>>you need to rebuild your artifacts for each environments, which is
> >>>>usually prone to errors, you test x-dev in your machine, and then
> >>>>build x-prod for production, with no guarantees that it's the same
> >>>>stuff you tested.
> >>>>
> >>>>My suggestion is to externalie that configuration options in a way
> >>>>that your artifact is always the same, and only configuration
> >>>>
> >>>>
> >>>>
> >>>>
> >>changes.
> >>
> >>
> >>
> >>
> >>>>You can do reading your config files from the classpath or better
> >>>>using JNDI. You can also have dev config as default so your
> >>>>
> >>>>
> >>>>
> >>>>
> >>developers
> >>
> >>
> >>
> >>
> >>>>don't have to setup anything and you do it only in prod or preprod.
> >>>>
> >>>>
> >>>>re INTER-PROJECT DEPENDENCIES
> >>>>
> >>>>With maven the best way is not to rebuild all your dependencies
> >>>>
> >>>>
> >>>>
> >>>>
> >>every
> >>
> >>
> >>
> >>
> >>>>time, but to depend on the binaries generated by the other projects
> >>>>
> >>>>
> >>>>
> >>>>
> >>as
> >>
> >>
> >>
> >>
> >>>>SNAPSHOTs. You can ensure the repo has the latest snapshot by
> >>>>
> >>>>
> >>>>
> >>>>
> >>setting
> >>
> >>
> >>
> >>
> >>>>up continuum to deploy everytime somebody changes the project. That
> >>>>way developers don't have to go through the extra time consuming
> >>>>process of building the dependencies.
> >>>>
> >>>>Regards
> >>>>
> >>>>Carlos
> >>>>
> >>>>
> >>>>On 5/26/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]>
> >>>>wrote:
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>I am pretty sure that I am over thinking this ;) However, I am
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>having
> >>>
> >>>
> >>>
> >>>
> >>>>>trouble thinking how best to migrate our ant based build process
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>to
> >>
> >>
> >>
> >>
> >>>>>maven. Principally:
> >>>>>
> >>>>>- Filtering properties files for environments, and
> >>>>>- Inter-project dependencies
> >>>>>
> >>>>>FILTERING PROPERTIES FILES FOR ENVIRONMENTS
> >>>>>As with most projects, our apps use properties files for
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>configuring
> >>
> >>
> >>
> >>
> >>>a
> >>>
> >>>
> >>>
> >>>
> >>>>>host of settings. Many of these (e.g. db settings, log4j
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>settings,
> >>
> >>
> >>
> >>
> >>>>web
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>service host:port etc) are environment specific. Our projects
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>have
> >>
> >>
> >>
> >>
> >>>>>properties files for various target environments, such as
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>production,
> >>>
> >>>
> >>>
> >>>
> >>>>>pre-production, cruisecontrol. Each developer also has a local
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>props
> >>>
> >>>
> >>>
> >>>
> >>>>>file that they can tailor for their particular needs (e.g. for
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>debugging
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>you may want to log springframework as DEBUG and suppress all
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>others).
> >>>
> >>>
> >>>
> >>>
> >>>>>Ant uses these files to filter the application properties. The
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>result
> >>>
> >>>
> >>>
> >>>
> >>>>>is a build tailored for a particular environment. Since all
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>environment
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>specific properties, beside the local, are source controlled we
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>have
> >>
> >>
> >>
> >>
> >>>a
> >>>
> >>>
> >>>
> >>>
> >>>>>high degree of confidence in consistent and reproducible builds to
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>our
> >>>
> >>>
> >>>
> >>>
> >>>>>shared infrastructure.
> >>>>>
> >>>>>In maven I have been able to reproduce this behavior with
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>profiles.
> >>
> >>
> >>
> >>
> >>>>>However, I am not sure what to do with the resulting artifacts.
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>Each
> >>>
> >>>
> >>>
> >>>
> >>>>>artifact is "tainted" with environment specific properties.
> >>>>>
> >>>>>Should artifacts generated with "local" only be installed in each
> >>>>>developers local repository? What about the artifacts for the
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>testing
> >>>
> >>>
> >>>
> >>>
> >>>>>and production environments? Should the internal repository only
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>be
> >>
> >>
> >>
> >>
> >>>>>used to store "production" artifacts? Should there be multiple
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>shared
> >>>
> >>>
> >>>
> >>>
> >>>>>internal repositories, one for production and one for pre-prod?
> >>>>>
> >>>>>INTER-PROJECT DEPENDENCIES
> >>>>>Currently we have a web based application broken out into four
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>projects:
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>1 - user-presentation-layer
> >>>>>2 - admin-presentation-layer
> >>>>>3 - web-service-layer
> >>>>>4 - common-utils
> >>>>>
> >>>>>Each project generates a primary artifact, and the
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>web-service-layer
> >>
> >>
> >>
> >>
> >>>>>also generates a client jar.
> >>>>>
> >>>>>Currently in order to generate a fresh build of say the
> >>>>>user-presentation-layer, you must have the web-service-layer and
> >>>>>common-utils checked out in your workspace. The ant build file
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>for
> >>
> >>
> >>
> >>
> >>>>the
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>user-presentation-layer will end up calling the other two build
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>files.
> >>>
> >>>
> >>>
> >>>
> >>>>>These builds in turn, get an update from cvs and then generating
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>the
> >>
> >>
> >>
> >>
> >>>>>appropriate artifact. Granted it took some time to get this
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>process
> >>
> >>
> >>
> >>
> >>>>up
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>and running, but it currently works and works pretty well.
> >>>>>
> >>>>>
> >>>>>
> >>>>>From my readings, it seems that this process is frowned upon.
> >>>>
> >>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>With
> >>
> >>
> >>
> >>
> >>>>>maven, the appropriate process would be to "mvn scm:update
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>install"
> >>
> >>
> >>
> >>
> >>>on
> >>>
> >>>
> >>>
> >>>
> >>>>>the web-service-layer and common-utils projects. Then run the
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>build
> >>
> >>
> >>
> >>
> >>>>for
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>the user-presentation-layer.
> >>>>>
> >>>>>Or better yet, have each user pull the dependencies
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>(web-service-layer
> >>>
> >>>
> >>>
> >>>
> >>>>>and common-utils) from an internal repository that is updated by
> >>>>>developers checking in changes or by some source control
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>repository.
> >>
> >>
> >>
> >>
> >>>>>However, as noted above, because of environmental impacts, I am
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>not
> >>
> >>
> >>
> >>
> >>>>sure
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>a shared repository would work for artifacts used in development.
> >>>>>Currently, our environment profiles only effect configuration
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>settings.
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>They do not modify or impact the source code directly. While the
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>maven
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>dependencies are a result of class dependencies, which should not
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>be
> >>
> >>
> >>
> >>
> >>>>>impacted by using an artifact configured for "production" versus
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>one
> >>
> >>
> >>
> >>
> >>>>>configured for "preproduction".
> >>>>>
> >>>>>What is the best way to handle this problem?
> >>>>>
> >>>>>I am sure people much smarter than myself have already tackled
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>these
> >>
> >>
> >>
> >>
> >>>>>problems and come up with very simple solutions.
> >>>>>
> >>>>>Any and all help sorting myself out would be really appreciated!
> >>>>>
> >>>>>Carlos
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>---------------------------------------------------------------------
> >>>
> >>>
> >>>
> >>>
> >>>>>To unsubscribe, e-mail: [EMAIL PROTECTED]
> >>>>>For additional commands, e-mail: [EMAIL PROTECTED]
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>--
> >>>>I could give you my word as a Spaniard.
> >>>>No good. I've known too many Spaniards.
> >>>> -- The Princess Bride
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>---------------------------------------------------------------------
> >>
> >>
> >>
> >>
> >>>>To unsubscribe, e-mail: [EMAIL PROTECTED]
> >>>>For additional commands, e-mail: [EMAIL PROTECTED]
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>---------------------------------------------------------------------
> >>
> >>
> >>
> >>
> >>>>To unsubscribe, e-mail: [EMAIL PROTECTED]
> >>>>For additional commands, e-mail: [EMAIL PROTECTED]
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>--
> >>>I could give you my word as a Spaniard.
> >>>No good. I've known too many Spaniards.
> >>> -- The Princess Bride
> >>>
> >>>---------------------------------------------------------------------
> >>>To unsubscribe, e-mail: [EMAIL PROTECTED]
> >>>For additional commands, e-mail: [EMAIL PROTECTED]
> >>>
> >>>
> >>>---------------------------------------------------------------------
> >>>To unsubscribe, e-mail: [EMAIL PROTECTED]
> >>>For additional commands, e-mail: [EMAIL PROTECTED]
> >>>
> >>>
> >>>---------------------------------------------------------------------
> >>>To unsubscribe, e-mail: [EMAIL PROTECTED]
> >>>For additional commands, e-mail: [EMAIL PROTECTED]
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>---------------------------------------------------------------------
> >>To unsubscribe, e-mail: [EMAIL PROTECTED]
> >>For additional commands, e-mail: [EMAIL PROTECTED]
> >>
> >>
> >>---------------------------------------------------------------------
> >>To unsubscribe, e-mail: [EMAIL PROTECTED]
> >>For additional commands, e-mail: [EMAIL PROTECTED]
> >>
> >>
> >>
> >>
> >>
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: [EMAIL PROTECTED]
> >For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: [EMAIL PROTECTED]
> >For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
