Mailing-List: contact ojb-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "OJB Developers List" <ojb-dev@db.apache.org>
Message-ID: <4055D5C1.8010406@apache.org>
Date: Mon, 15 Mar 2004 17:11:45 +0100
From: Armin Waibel <arminw@apache.org>
User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207)
MIME-Version: 1.0
To: OJB Developers List <ojb-dev@db.apache.org>
Subject: Re: PersistentFields per class descriptors. was [RFC] Using
 java.lang.reflect.Proxy
References: <Pine.GSO.4.21.0403151528120.28302-100000@pille>
In-Reply-To: <Pine.GSO.4.21.0403151528120.28302-100000@pille>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Hi again Tom,

Thomas Dudziak wrote:
> On Mon, 15 Mar 2004, Armin Waibel wrote:
> 
> 
>>hmm, ok so we need both possibilities to define PersistentFieldClass 
>>attribute filed- and class-descriptor level
>>and I fear the worst you want this feature for 1.0 ;-)
> 
> 
> Nope, for 1.1 is enough, I think. The workaround using the field handler
> that Brian mentioned should do for the 1.0, though there should be some
> note of it in the docs.
>

puh! For 1.1 I will agree all proposals ;-)

> 
>>do we need this? One reason is that we do not separate metadata 
>>properties and functionality/service methods in metadata classes.
> 
> 
> I had one application where I simply wanted to manipulate the metadata
> without doing any database-related stuff. However, currently OJB requires
> me to provide OJB.properties

yep, in OJB.properties the path to the repository file was specified 
(maybe we should change this in 1.1) and many default/standard classes 
(e.g. PersistentFieldClass) are defined. I like this, because it 
prevents us to define default implementation classes in source code, 
respectively allow us to change these classes.

>, and a connection descriptor (I may be
> mistaken about that one) when using the metadata even though they are not
> actually needed by the metadata stuff.

I must confess that I'm not sure about connection-descriptor too (it was 
possible in the past). But I think if you access metadata via 
MetadataManager it should be possible. If not, you found a bug.

http://db.apache.org/ojb/faq.html#Start OJB without a repository file?

> I strongly believe that metadata handling and database stuff should be as
> decoupled as possible, in extreme with using interfaces (facade) which are
> backed by XML i/o (as we have it now) or other stuff, e.g. database (->
> MOF ?), Language-supported metadata (JSR 175) etc.
> 

I think it's decoupled. At least I assert this behaviour in these 
uncomplete doc ;-)
http://db.apache.org/ojb/metadata.html

You can load connection metadata different from persistent object 
metadata and vice versa. In object metadata no connection specific stuff 
is used.

> 
>>I think this is really important for 1.0.
>>All these known issues should be noted in the release-notes.
>>Can you list the (most important) properties of class-/field-descriptor 
>>who don't support runtime changes?
> 
> 
> I believe there were some mails on the lists. I can have a look and
> summarize them.
>  

This will be great!

> 
>>I agree. But what are the alternatives and who will be willing to do 
>>this changeover?
> 
> 
> I'd be willing to rework the XML parsing part (using dom4j or the like
> ?) but not before April (too much regular work and deadlines too near).
> 

Great! April is ok, at that time 1.0 should be released ;-)
(dom4j licence?)

regards,
Armin

> 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