[RFC] OJB in-a-jar

[Thomas Dudziak <to...@first.gmd.de>]

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

Re: [RFC] OJB in-a-jar

[Joerg Heinicke <jo...@gmx.de>]

On 26.05.2004 23:02, Thomas Dudziak wrote:

> - 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

Separating the default settings from the users settings is a very 
important point. We suffer from the same problem in Cocoon and its conf 
files. We have a xpatch task merging user's conf into Cocoon's conf 
there, but that's by far not the optimum. For OJB that's not possible as 
there is for example the OJB.properties text file. Now in my project 
with different settings for dev and live server I have to provide two 
different extension mechanism for Cocoon's and OJB's config.

The OJB_HL_SEQ table added by Robert is another problem I had too.

Joerg

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

Re: [RFC] OJB in-a-jar

[Robert Sfeir <ro...@codepuccino.com>]

On May 27, 2004, at 2:48 AM, Thomas Mahler wrote:

> 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?

hehe, well that all depends when 1.0 will be released :-)

We've been adding so much, including the secondary caching, if there's 
enough time why not?  I would have build froze a while ago, but it 
seems things work differently here :-)

R

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

Re: [RFC] OJB in-a-jar

[Thomas Mahler <th...@web.de>]

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

Re: [RFC] OJB in-a-jar

[Robert Sfeir <ro...@codepuccino.com>]

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.

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

Re: [RFC] OJB in-a-jar

[Thomas Dudziak <to...@first.gmd.de>]

On Thu, 27 May 2004, Thomas Mahler wrote:

> It would be nice to have it in 1.0, agreed. It does not involve any API 
> changes, so there is no reason against this change.
> 
> But I'm not so optimistic about the time frame.
> Currently most OJB.properties are only read once. There is no concept of
> updating those settings at runtime.
> Of course it's easy to update a key/value map at runtime. But it's quite 
> a different thing to change all the depenend components that use this 
> configuration to be reconfigurable.
> Of course it's possible to do this change to, but it needs careful 
> analysis of existing code.

Actually that's not what I intended. IMO there are few properties for 
which runtime changeability is useful. My idea was to change OJB so that
it does lazy initialization (evaluation of the properties), e.g. as late
as possible (i.e. prior to creating a broker). This would enable the user
to set properties programatically rather than having to supply a file. As
soon as the broker has been created, an attempted change to a property
would result in an exception.

Tom


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

Re: [RFC] OJB in-a-jar

[Thomas Mahler <th...@web.de>]

Hi Tom,

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
> 

+1
I agree that this will be a very useful change!

> 
> 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.

It would be nice to have it in 1.0, agreed. It does not involve any API 
changes, so there is no reason against this change.

But I'm not so optimistic about the time frame.
Currently most OJB.properties are only read once. There is no concept of
updating those settings at runtime.
Of course it's easy to update a key/value map at runtime. But it's quite 
a different thing to change all the depenend components that use this 
configuration to be reconfigurable.
Of course it's possible to do this change to, but it needs careful 
analysis of existing code.

So if it is to be shipped in 1.0 you have to hurry!

cheers,
thomas

> 
> 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
> 
> 

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