directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lécharny <>
Subject Re: svn commit: r1300690 - in /directory/apacheds/branches/apacheds-txns: core-api/src/main/java/org/apache/directory/server/core/api/log/ core-api/src/main/java/org/apache/directory/server/core/api/txn/ core-api/src/main/java/org/apache/directory/se
Date Wed, 14 Mar 2012 22:23:57 GMT
Le 3/14/12 10:52 PM, Selcuk AYA a écrit :
> HI All,
> Sorry for the earlier email. I think I owe some explaination on my
> part. The reason for my request is purely technical, does not aim at
> oss spirit or any other spirit for that matter:
> * There are quite a number of files the txn branch is touching.
> * There is no file ownership or review process.
> combined with the timing limitation, it becomes hard for me to track
> all changes and cleanup if necessary. When I am doing my changes and
> need to change some existing stuff, I usually try to find the guy who
> wrote the code and get an ack from him and this usually helps a lot
> because even things that look stupid might have some reason to be
> there. Please do the same while changing the txn branch.If this
> process is followed, we wont have to discuss spirit hurting through
> reverting code.
np. We can consider that the branch is your sandbox, and i'll keep it 
alone, just let me know.

Look, I'm not trying to collide with what you are doing, Selcuk. Just 
trying to add the necessary doco and clarification (ie, logs, formating) 
to get people used with the code. If the code is not finished yet, and 
can keep away from it atm, just say so.

I'm pretty sure we need to communicate more here to avoid such issues :
- telling what's going on through the exposure of a roadmap
- being more reactive (like just ack mails even if one does not have 
time to give a clear answer)

Regarding the changed code, let me give you some clue about the reason I 
did those changes :
when you log some LogEdit, the records are stored in a file and will 
have to be read at some point. The externalizable classes have 
readExternal() methods which expect the byte[] to contain the expected 
content. Currently, we can do that if :
- we have stored only one type of object (like Entry)
- we have stored mixed data in a specific order, which allows the code 
to deserialize the classes without adding a type.

I guess that the intention was to deserialize data expecting the 
serialized structure will always be :

Here, I see one issues : in one case, we won't have any DATA_CONTAINER 
(specifically when doing a BIND). We won't then be able to distinguish 
don't have an extra information, the type.

Unless there is something that can be used to make this distinction...

Can you enlight me here, in cas I'm doing something wrong ?

Thanks !

Emmanuel Lécharny

View raw message