Hi,
Our product is database indepedent, some of our clients use DB2, Oracle or Sybase, and even sometimes our product needs to be plugged on two deferent db at the same time (e.g. our legacy product runs on Sybase only but now some clients are turning to Oracle and want the components of our new product to run on Oracle).
Thus we needed our consultants to be able to configure on which database each component is running.
Currently the engine is specified in the database.xml file and most of the time you would not want any on-site consultant to have to change it for at least two reasons: if they break something it will be hell, and in most of the cases this file is bundled into a JAR.
Ergo, we added the opportunity to override the db engines in the castor.properties
Claude
-----Original Message-----
From: Werner Guttmann [mailto:[EMAIL PROTECTED]]
Sent: 23 June 2004 10:10
To: [EMAIL PROTECTED]
Subject: Re: [castor-dev] Easier way to configure castor...
Claude,
thanks for creating the enhancement request. Re: the db-engine-feature, can you briefly explain to me the added value of this extension ? What would you gain by being able to specify the db engine to be used in castor.properties over the current solution ?
Werner
--Original Message Text---
From: Claude Vedovini
Date: Wed, 23 Jun 2004 09:44:56 +0200
RE: [castor-dev] Easier way to configure castor...
Hi Werner,
I just posted bug 1673 pointing to this thread's archives.
Additionaly, I wonder if you had any comment about the "ability to specify the db engine in the castor.properties" feature I mentionned in my previous post?
Regards,
Claude
> -----Original Message-----
> From: Werner Guttmann [mailto:[EMAIL PROTECTED]]
> Sent: 22 June 2004 19:07
> To: [EMAIL PROTECTED]
> Subject: Re: [castor-dev] Easier way to configure castor...
>
>
> 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.
>
>
__________________________________________________________________________
� 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.
__________________________________________________________________________
· 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
