Re: [2.2] Simplifying configuration
Antonio Fiol Bonnín wrote: Some thoughts (my opinion) about configuration. 1. Environment-related configuration should be banned inside the webapp directory (or WAR file). 2. Business-related configuration should be inside it. [...] Thanks for sharing your ideas! After having some working prototype of the OSGi based blocks-fw (expect this within the next 6-8 weeks), we will certainly discuss configuration management in detail. Your mail is certainly a good starting point, especially your idea of differentiating between environment related configuration and business-related configurations. -- Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach {Software Engineering, Open Source, Web Applications, Apache Cocoon} web(log): http://www.poetz.cc ___ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Re: [2.2] Simplifying configuration
Some thoughts (my opinion) about configuration. 1. Environment-related configuration should be banned inside the webapp directory (or WAR file). 2. Business-related configuration should be inside it. Developing it a little more you will see why I state that. a. The developer of an application (cocoon-based or any other) does not necessarily know about the production environment things like: - Host names and ports - Paths - Timeouts required (e.g by firewalls closing connections) or configured in other applications - Memory sizes - JVM parametrization b. The system administrator knows all of the above. c. Some of the above might have sensible defaults, which the developer knows. d. The developer usually knows the right values for business-related configuration. e. The system administrator does not know about business-related configuration, but... f. The system administrator could be asked to change some business-related configuration. For that, in our company we developed a simple component based on Commons Configuration and a policy for developers that solves all a-e points. There are basically two configuration sources: one of them supplied by the developer and one of them supplied by the administrator. The first one is, in our case, a XML file inside the WAR file, and the second one is the JNDI environment. We use Tomcat, so the JNDI environment is very easy to setup, i.e. you only have to add entries in the context XML file. It is probably quite difficult to achieve (a) to (e) for Cocoon, given the complexity of the configuration. But... wait! Most of it is "business" configuration. So... only non-business would need to be extracted to another configuration source. WDYT? -- Antonio
Re: [2.2] Simplifying configuration
Stefano Mazzocchi wrote: Carsten Ziegeler wrote: In the last days I simpliefied the configuration for 2.2 a little bit. Since you're at it, I would suggest considering removing a lot of the cocoon.xconf stuff and turn them into compile-time settings. It is already this way, for the most part. Current cocoon.xconf is mostly documentation of different component's optional features, and all configuration is mostly set to compiled-in defaults. I do not think it is hard to trim cocoon.xconf to the minimum - but please do not loose documentation in the process. Vadim
Re: [2.2] Simplifying configuration
Carsten Ziegeler wrote: In the last days I simpliefied the configuration for 2.2 a little bit. Since you're at it, I would suggest considering removing a lot of the cocoon.xconf stuff and turn them into compile-time settings. Two things should happen for cocoon 2.2, IMO: 1) if you *do not* have a cocoon.xconf file (or other xconf files), cocoon should behave normally. [this avoids the 'programming by configuration' problem that we 2) if a configuration change can break cocoon, it should not be a configuration but a compile-time switch. so #1 is for "out of the box" behavior, #2 is for "solidity in your hands" behavior. -- Stefano.
Re: [2.2] Simplifying configuration
Ralph Goers wrote: > Darn. Looking through the archives I see you did this in 2.2. What code > do I need to bring back to 2.1 to get this working? > The code is a little bit tied to the refactoring of the core I did for 2.2; so one solution is to port the whole new (spring) based core to 2.1.x. If you just want to use properties in the cocoon.xconf you can replace the SAXConfigurationHandler from Excalibur (which is used to read the xconf) with an own version that supports replacing properties. In 2.2 we use the ConfigurationBuilder. Carsten -- Carsten Ziegeler - Open Source Group, S&N AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: [2.2] Simplifying configuration
Ralph Goers wrote: > I'm confused by this post. One of the features my operations folks are > looking for is being able to configure pool and cache sizes from an > external properties file. I was under the impression that you had > implemented this in 2.1. Your message below only talks about web.xml > though. Is my recollection incorrect? > Hmm, no - properties have been added to 2.2. In 2.2 you can choose between the old way (for compatibility) in web.xml or using the new one with properties. Carsten -- Carsten Ziegeler - Open Source Group, S&N AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: [2.2] Simplifying configuration
Darn. Looking through the archives I see you did this in 2.2. What code do I need to bring back to 2.1 to get this working? Ralph Goers wrote: I'm confused by this post. One of the features my operations folks are looking for is being able to configure pool and cache sizes from an external properties file. I was under the impression that you had implemented this in 2.1. Your message below only talks about web.xml though. Is my recollection incorrect? Ralph Carsten Ziegeler wrote: In the last days I simpliefied the configuration for 2.2 a little bit. I hope this is ok with everyone - if not we can discuss/read stuff (no problem, and yes I know that it would be better to first ask and then do, but I needed some changes for the spring stuff anyway). In 2.1.x it's possible to configure properties in web.xml which are then set later on within Cocoon as system properties. Now I think this should not be a task for Cocoon: it's better to define those properties when you startup your JVM - so I removed this feature completly. All files which are written (logs, uploads, temporary files) are no longer written by default into the webapp. They all go into the working directory - directly writing files to the webapp has never really been a good idea. Cocoon 2.1.x tries to set some system properties for Xalan (code below); I commented them out and didn't experience any problems. Does anyone know why we needed them the first place. I think we should just remove this code. If it's needed in some cases, again these are system properties which can be set for the JVM. Carsten protected void setSystemProperties() { try { // FIXME We shouldn't have to specify the SAXParser... // This is needed by Xalan2, it is used by org.xml.sax.helpers.XMLReaderFactory // to locate the SAX2 driver. if (getSystemProperty("org.xml.sax.driver", null) == null) { System.setProperty("org.xml.sax.driver", "org.apache.xerces.parsers.SAXParser"); } } catch (SecurityException e) { // Ignore security exceptions System.out.println("Caught a SecurityException writing the system property: " + e); } try { // FIXME We shouldn't have to specify these. Needed to override jaxp implementation of weblogic. if (getSystemProperty("javax.xml.parsers.DocumentBuilderFactory", "").startsWith("weblogic")) { System.setProperty("javax.xml.parsers.DocumentBuilderFactory", "org.apache.xerces.jaxp.DocumentBuilderFactoryImpl"); System.setProperty("javax.xml.parsers.SAXParserFactory","org.apache.xerces.jaxp.SAXParserFactoryImpl"); } } catch (SecurityException e) { // Ignore security exceptions System.out.println("Caught a SecurityException writing the system property: " + e); } }
Re: [2.2] Simplifying configuration
I'm confused by this post. One of the features my operations folks are looking for is being able to configure pool and cache sizes from an external properties file. I was under the impression that you had implemented this in 2.1. Your message below only talks about web.xml though. Is my recollection incorrect? Ralph Carsten Ziegeler wrote: In the last days I simpliefied the configuration for 2.2 a little bit. I hope this is ok with everyone - if not we can discuss/read stuff (no problem, and yes I know that it would be better to first ask and then do, but I needed some changes for the spring stuff anyway). In 2.1.x it's possible to configure properties in web.xml which are then set later on within Cocoon as system properties. Now I think this should not be a task for Cocoon: it's better to define those properties when you startup your JVM - so I removed this feature completly. All files which are written (logs, uploads, temporary files) are no longer written by default into the webapp. They all go into the working directory - directly writing files to the webapp has never really been a good idea. Cocoon 2.1.x tries to set some system properties for Xalan (code below); I commented them out and didn't experience any problems. Does anyone know why we needed them the first place. I think we should just remove this code. If it's needed in some cases, again these are system properties which can be set for the JVM. Carsten protected void setSystemProperties() { try { // FIXME We shouldn't have to specify the SAXParser... // This is needed by Xalan2, it is used by org.xml.sax.helpers.XMLReaderFactory // to locate the SAX2 driver. if (getSystemProperty("org.xml.sax.driver", null) == null) { System.setProperty("org.xml.sax.driver", "org.apache.xerces.parsers.SAXParser"); } } catch (SecurityException e) { // Ignore security exceptions System.out.println("Caught a SecurityException writing the system property: " + e); } try { // FIXME We shouldn't have to specify these. Needed to override jaxp implementation of weblogic. if (getSystemProperty("javax.xml.parsers.DocumentBuilderFactory", "").startsWith("weblogic")) { System.setProperty("javax.xml.parsers.DocumentBuilderFactory", "org.apache.xerces.jaxp.DocumentBuilderFactoryImpl"); System.setProperty("javax.xml.parsers.SAXParserFactory","org.apache.xerces.jaxp.SAXParserFactoryImpl"); } } catch (SecurityException e) { // Ignore security exceptions System.out.println("Caught a SecurityException writing the system property: " + e); } }
[2.2] Simplifying configuration
In the last days I simpliefied the configuration for 2.2 a little bit. I hope this is ok with everyone - if not we can discuss/read stuff (no problem, and yes I know that it would be better to first ask and then do, but I needed some changes for the spring stuff anyway). In 2.1.x it's possible to configure properties in web.xml which are then set later on within Cocoon as system properties. Now I think this should not be a task for Cocoon: it's better to define those properties when you startup your JVM - so I removed this feature completly. All files which are written (logs, uploads, temporary files) are no longer written by default into the webapp. They all go into the working directory - directly writing files to the webapp has never really been a good idea. Cocoon 2.1.x tries to set some system properties for Xalan (code below); I commented them out and didn't experience any problems. Does anyone know why we needed them the first place. I think we should just remove this code. If it's needed in some cases, again these are system properties which can be set for the JVM. Carsten protected void setSystemProperties() { try { // FIXME We shouldn't have to specify the SAXParser... // This is needed by Xalan2, it is used by org.xml.sax.helpers.XMLReaderFactory // to locate the SAX2 driver. if (getSystemProperty("org.xml.sax.driver", null) == null) { System.setProperty("org.xml.sax.driver", "org.apache.xerces.parsers.SAXParser"); } } catch (SecurityException e) { // Ignore security exceptions System.out.println("Caught a SecurityException writing the system property: " + e); } try { // FIXME We shouldn't have to specify these. Needed to override jaxp implementation of weblogic. if (getSystemProperty("javax.xml.parsers.DocumentBuilderFactory", "").startsWith("weblogic")) { System.setProperty("javax.xml.parsers.DocumentBuilderFactory", "org.apache.xerces.jaxp.DocumentBuilderFactoryImpl"); System.setProperty("javax.xml.parsers.SAXParserFactory","org.apache.xerces.jaxp.SAXParserFactoryImpl"); } } catch (SecurityException e) { // Ignore security exceptions System.out.println("Caught a SecurityException writing the system property: " + e); } } -- Carsten Ziegeler - Open Source Group, S&N AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/