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]
