db-ojb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas Mahler <thm...@web.de>
Subject Re: [RFC] OJB in-a-jar
Date Thu, 27 May 2004 06:48:51 GMT
Hi Robert,

Robert Sfeir wrote:
> I think you would solve the biggest thing I needed to deal with when I 
> first met OJB.
> 
> I think the one piece that would be good to add, is a way to 
> automatically add the tables needed for OJB to operate, specifically and 
> at a minimum the HiLoSequence table... or instead of adding, some 
> solution which would make it more transparent to the user.
> 

+1
I agree this is a very useful feature.
But we should take care to have a switch that allows to turn off 
automatic table generation. There are lots of companies that do not 
allow database schema changes on production environments.

I also hope you don't expect this feature for 1.0?

cheers,
thomas


> R
> 
> On May 26, 2004, at 5:02 PM, Thomas Dudziak wrote:
> 
>> I was thinking about making OJB able to run without any user supplied
>> configuration or descriptor files. The general idea is that OJB is used
>> in-a-jar and every relevant configuration and initialization can done at
>> runtime without having to supply files. This involves:
>>
>> - OJB properties
>>
>> Currently there has to be a file OJB.properties present which contains
>> default settings and settings changed by the user. IMO these should be
>> separated. The default settings should be a fixed part of OJB (either
>> coded in the source or as a default.properties file within the jar). The
>> user settings can still be located in a OJB.properties file (and checked
>> for + loaded at OJB initialization), but this file is no longer
>> required. Furthermore, it should also be possible to supply these user
>> settings via appropriate methods (before the OJB runtime has been
>> initialized) rather than via a file.
>>
>> - Connection descriptor / Repository descriptor
>>
>> It is already possible to define these at runtime. However it is still
>> required to supply a repository.xml, even if it is empty.
>>
>>
>> The benefits when these file dependencies are removed, are:
>>
>> - Integration into/usage in other environments is a lot easier if no
>> external files are required (e.g. webapps)
>>
>> - When the default settings are integrated into the dist (either in the
>> code or as a file in the jar), then it will be easier for users to 
>> migrate
>> to a new OJB version. Currently it happens every so often that the OJB
>> libraries are updated, but not the OJB.properties (or the DTD which also
>> could be checked per default) which leads to errors concerning missing or
>> wrong settings - these could be at least reduced
>>
>>
>> IMO the changes (which should be rather small) should be in the 1.0
>> because this version is bound to be around for a while, so if somebody is
>> likely to use OJB for something new (in particular I was thinking about
>> usage in scripting), then it will be with this version. So we should make
>> this integration as easy as possible.
>>
>> What do you think ?
>>
>> Tom
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
>> For additional commands, e-mail: ojb-dev-help@db.apache.org
>>
> Robert S. Sfeir
> Technical Lead
> HHS Portal
> robert_sfeir@sra.com
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-dev-help@db.apache.org
> 
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org


Mime
View raw message