Claude,
in the light of all these arguments, can I please ask you to visit
http://bugzilla.exolab.org and open an enhancement request (a bug report categorized
as enhancement request) so that you and we can trace progress and discuss required
features in a more structured manner.
Nick, and I do not know how much progress you have made to patch Claude's 'patch', but
please use the bug report as opened by Claude to attach
any stream-lined patch.
Regards
Werner
--Original Message Text---
From: Claude Vedovini
Date: Mon, 21 Jun 2004 13:09:01 +0200
RE: [castor-dev] Easier way to configure castor...
Hi Werner,
> PS Please no HTML email to this mailing list as per
> http://castor.exolab.org/lists.html#A-note-about-HTML-formatte
> d-e-mail.
Unfortunately this does not come from me, original mails were actually in plain/text.
I suspect ou corporate disclaimer and still need to notice that to our
IT dept.
Really consider that I apologise for the disturbance, I do hate receiving HTML mail
nearly at the same level as I hate receiving "out-of-office" auto-
replies on a mailing-list ;-)
> We went through this problem and were not satisfied with
> "classpath" solution, first because it a bit more tricky for
> a on site consultant to change a
> classpath in Websphere ...
>
> werner --> Hmm, that is a difficult statement per se .. ;-).
> First off, I didn't mean to imply that the CLASSPATH should
> be changed for this to work. In
> general, it is a very bad idea to have to change the
> CLASSPATH of a Websphere instance at all ... Assuming that
> you are deploying a web application,
> by definition the web app should be self-contained, i.e.
> everything required to run the web app should be part of it.
> Having said that, this could and
> should include any castor.properties file to override the
> system defaults. By nature, such a file (when placved eg. in
> WEB-INF/classes of a web
> appllication will 'override' the castor.properties file
> stored in castor-0.9.5.3.jar stored in WEB-INF/lib of your web app.
Well, either having to add an entry to the classpath or changing a file in the
classpath, I call that changing the classpath, but that's arguing :-)
However, the web-app is not a solution when you deploy EJBs, and then, if you want to
override the default properties you need to do something with
the classpath.
Either copy the properties file to the server installation or add an entry to the
server's bootstrap classpath will impact any running instance. The other
solutions beeing:
- changing an instance classpath (and 2 times out of 3 this lead to a severe
headache)
- or setting a system property (which has nearly no impact if done wrong, and believe
me it happens more often that you may think, despite a crystal
clear documentation)
Additionally, there are some cases where you need to change the castor configuration
on-site, for example:
- Enabling XML indentation for easier debugging of XML interchange (using vi to read
a 1-line XML message may lead to despair)
- Disabling XML validation once in production in order to have better performances
(well that's what THEY think, I am personally not really sure about
that statement :-)
- Changing the kind of database you are using (did I mentioned that we added the
Castor JDO codebase the ability to specify the engine in the
castor.properties?)
> .. than a system property and because the property file
> override all the properties defined in this of the jar file.
> werner --> Afaik, you do not have to specify all properties
> in this file, just the ones you actually want to override.
You are right, apologies, seems it was an old endeavour that existed when we put the
castor.configuration property in place and it changed since then
:-)
Nick has all of its requests fullfiled!
Regards,
Claude
__________________________________________________________________________
� This email and any files transmitted with it are CONFIDENTIAL and intended
solely for the use of the individual or entity to which they are addressed.
� Any unauthorized copying, disclosure, or distribution of the material within
this email is strictly forbidden.
� Any views or opinions presented within this e-mail are solely those of the
author and do not necessarily represent those of Odyssey Asset Management
Systems SA unless otherwise specifically stated.
� An electronic message is not binding on its sender. Any message referring to
a binding engagement must be confirmed in writing and duly signed.
� If you have received this email in error, please notify the sender immediately
and delete the original.
-----------------------------------------------------------
If you wish to unsubscribe from this mailing, send mail to
[EMAIL PROTECTED] with a subject of:
unsubscribe castor-dev
