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]
