Add me to the list of people who think *most* configuration still belongs somewhere in FEDORA_HOME.
For one, I think it's easier to communicate to people where the configuration is when the expectation is that it's always relative to $FEDORA_HOME. Otherwise, it's something like "Go to the place where your webapp container chose to unpack fedora.war. Under that directory, go to WEB-INF/something, and among all the other junk in there, find these key configuration files". For two, (and this is probably the stronger point...), in many cases, deploying a bugfix release just becomes a matter of replacing the war in your webapp container and restarting. Since it's deployed-as-distributed, there are no customizations you could possibly overwrite in doing so. - Chris On Wed, Jul 20, 2011 at 9:52 AM, <[email protected]> wrote: > I have never realized that different people see the purpose of FEDORA_HOME so > differently-- thanks for opening my eyes. > > I have to disagree with the notion that it could be that "FEDORA_HOME is > really just disk storage for logs and managed datastreams" because we, like > many institutions, have a complex storage structure underneath some of our > repositories and the actual filesystems that store objects and datastreams > aren't anywhere near FEDORA_HOME. Something similar holds for logs, for us. > So the contents of FEDORA_HOME is these cases are just the configuration > files. But that merely proves that you _can_ use FEDORA_HOME in this way, not > that you should or that most people do. > > I certainly agree in principle that "different Fedora installations in the > same JVM are distinguished ... better with Spring containers" but wouldn't > that depend on full "Springification"? Could we run two repositories in the > same web container by this means, today? As Eddie points out, there are > plenty of use-cases for exactly that affordance. > > I suppose part of my thinking here comes from experience with a pattern that > separates: 1) an application (or suite of services) which is essentially > unchanged from installation to installation, and 2) a resource or resources > that provide the differences between installations (e.g. config directories, > instance-specific databases, JNDI sections, etc.). It may be that this isn't > the right pattern at all for Fedora. > > --- > A. Soroka > Online Library Environment > the University of Virginia Library > > > > > On Jul 20, 2011, at 8:36 AM, Benjamin Armintor wrote: > >> We should have a separate thread in which we discuss what FEDORA_HOME >> is really necessary for- for example, it's interesting that you think >> configuration belongs there, while I would've said configuration >> belongs with the webapp, and FEDORA_HOME is really just disk storage >> for logs and managed datastreams... but even that might be >> configurable. Maybe the thing FEDORA_HOME is really for is just >> serving as the key by which different Fedora installations in the same >> JVM are distinguished, but I'd argue that even that is done better >> with Spring containers. >> >> >> On Wed, Jul 20, 2011 at 8:03 AM, <[email protected]> wrote: >>>> From option 3: "Cons: the configs are in a jar and harder to manipulate". >>> >>> I suspect that this is an extremely big con and that if we're interested in >>> option 3, we won't want to pack the configs into any JARs. Much of the >>> Fedora configuration is loosely expected to go over into Spring and away >>> from specialized formats like that found in fedora.fcfg. Making the Spring >>> configs that control (e.g) Akubra implementation or ActiveMQ (or eventually >>> FESL or the RI or dissemination resolution, etc.) difficult to handle by >>> putting them in JARs would be unfortunate. >>> >>> Instead, we might just have them available in WEB-INF/classes, but I must >>> admit, the whole option doesn't appeal to me because it runs against the >>> very intention of separating off FEDORA_HOME, which is to have all >>> installation-specific stuff found there. >>> >>> --- >>> A. Soroka >>> Online Library Environment >>> the University of Virginia Library >>> >>> >>> >>> >>> On Jul 20, 2011, at 4:40 AM, Asseg, Frank wrote: >>> >>>> Hola Guys, >>>> >>>> After reading up a bit and looking through the fcrepo-webapp-fedora >>>> web.xml, here are the three different fixes for loading spring configs >>>> from outside of the WEB-INF directory i could come up with: >>>> >>>> 1.) import the server's context using >>>> <import resource="file:${FEDORA_HOME}/server/config/spring"> >>>> in src/main/webapp/WEB-INF/applicationContext.xml >>>> Pro: quick, no new implementation, easy to configure >>>> Con: ugly, and not really a relative path. >>>> >>>> >>>> 2.) implement ConfigurableWebApplicationContext from Spring and use >>>> <context-param> >>>> <param-name>contextClass</param-name> >>>> <param-value>MyWebapplicationContext</param-value> >>>> <context-param> >>>> in src/main/webapp/WEB-INF/web.xml. This will have Spring's >>>> ContextLoader use the set contextClass as an ApplicationContext. >>>> This is basically the ResourceLoader idea from the commiter's meeting. >>>> Pro: only relative paths for configuration files, since the >>>> implementation could know where to look for the files (i.e. FEDORA_HOME). >>>> Con: work. >>>> >>>> >>>> 3.) pack the spring configuration files into the server jar by adding >>>> the xml files as resources in the maven pom.xml, so they will be >>>> automatically put into the resulting jar file when build. Then spring >>>> will be able to locate server spring configuration files in the classpath. >>>> Pro: quick, no new implementation, no paradigms would be broken >>>> Cons: the configs are in a jar and harder to manipulate >>>> >>>> >>>> imho and in light of https://jira.duraspace.org/browse/FCREPO-504 i'd >>>> say the third approach seems most atractive to me, since it also >>>> complies with the best practice of having all the configuration of a >>>> webapp in WEB-INF. >>>> >>>> regards, >>>> >>>> frank >>>> >>>> >>>> -- >>>> Frank Asseg >>>> ePublishing & eScience >>>> Development & Applied Research >>>> Phone +49 7247-808-515 >>>> Fax +49 7247 808-133 >>>> [email protected] >>>> >>>> >>>> FIZ Karlsruhe – Leibniz Institute for Information Infrastructure >>>> Hermann-von-Helmholtz-Platz 1 >>>> 76344 Eggenstein-Leopoldshafen, Germany >>>> >>>> http://www.fiz-karlsruhe.de/ >>>> >>>> >>>> ------------------------------------------------------- >>>> >>>> Fachinformationszentrum Karlsruhe, Gesellschaft für >>>> wissenschaftlich-technische Information mbH. >>>> Sitz der Gesellschaft: Eggenstein-Leopoldshafen, Amtsgericht Mannheim HRB >>>> 101892. >>>> Geschäftsführerin: Sabine Brünger-Weilandt. >>>> Vorsitzender des Aufsichtsrats: MinDirig Dr. Thomas Greiner. >>>> >>>> ------------------------------------------------------------------------------ >>>> 10 Tips for Better Web Security >>>> Learn 10 ways to better secure your business today. Topics covered include: >>>> Web security, SSL, hacker attacks & Denial of Service (DoS), private keys, >>>> security Microsoft Exchange, secure Instant Messaging, and much more. >>>> http://www.accelacomm.com/jaw/sfnl/114/51426210/ >>>> _______________________________________________ >>>> Fedora-commons-developers mailing list >>>> [email protected] >>>> https://lists.sourceforge.net/lists/listinfo/fedora-commons-developers >>> >>> >>> ------------------------------------------------------------------------------ >>> 10 Tips for Better Web Security >>> Learn 10 ways to better secure your business today. Topics covered include: >>> Web security, SSL, hacker attacks & Denial of Service (DoS), private keys, >>> security Microsoft Exchange, secure Instant Messaging, and much more. >>> http://www.accelacomm.com/jaw/sfnl/114/51426210/ >>> _______________________________________________ >>> Fedora-commons-developers mailing list >>> [email protected] >>> https://lists.sourceforge.net/lists/listinfo/fedora-commons-developers >>> >> >> ------------------------------------------------------------------------------ >> 10 Tips for Better Web Security >> Learn 10 ways to better secure your business today. Topics covered include: >> Web security, SSL, hacker attacks & Denial of Service (DoS), private keys, >> security Microsoft Exchange, secure Instant Messaging, and much more. >> http://www.accelacomm.com/jaw/sfnl/114/51426210/ >> _______________________________________________ >> Fedora-commons-developers mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/fedora-commons-developers > > > ------------------------------------------------------------------------------ > 10 Tips for Better Web Security > Learn 10 ways to better secure your business today. Topics covered include: > Web security, SSL, hacker attacks & Denial of Service (DoS), private keys, > security Microsoft Exchange, secure Instant Messaging, and much more. > http://www.accelacomm.com/jaw/sfnl/114/51426210/ > _______________________________________________ > Fedora-commons-developers mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/fedora-commons-developers > ------------------------------------------------------------------------------ 10 Tips for Better Web Security Learn 10 ways to better secure your business today. Topics covered include: Web security, SSL, hacker attacks & Denial of Service (DoS), private keys, security Microsoft Exchange, secure Instant Messaging, and much more. http://www.accelacomm.com/jaw/sfnl/114/51426210/ _______________________________________________ Fedora-commons-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/fedora-commons-developers
