You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Carsten Ziegeler <cz...@apache.org> on 2006/02/24 08:46:00 UTC
[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/
Re: [2.2] Simplifying configuration
Posted by Reinhard Poetz <re...@apache.org>.
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
Posted by Antonio Fiol Bonnín <an...@gmail.com>.
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 <Environment ... /> 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
Posted by Vadim Gritsenko <va...@reverycodes.com>.
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
Posted by Stefano Mazzocchi <st...@apache.org>.
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
Posted by Carsten Ziegeler <cz...@apache.org>.
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
Posted by Ralph Goers <Ra...@dslextreme.com>.
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
Posted by Carsten Ziegeler <cz...@apache.org>.
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
Posted by Ralph Goers <Ra...@dslextreme.com>.
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);
> }
> }
>
>