On the extensibility of the core

[Esteban Franqueiro <es...@bea.com>]

Hi.
I was wondering why there seems to be a problem with allowing the core to be extended in some ways. 
In my particular case, I need the database data store, and the current implementation doen't quite 
fit my needs. So I wanted to change some details of it. My plan was to extend DbDataStore and make 
my changes there. But then I find out there are some utility methods/classes that don't have the 
visibility required to be used in derived clases. For example, DbDataStore.moveToTempFile() is 
private and TempFileInputStream's constructor is package-private.
So my question is: do we wan't people not being able to extend Jackrabbit in this way?
Regards,

Esteban Franqueiro
esteban.franqueiro@bea.com 


Notice:  This email message, together with any attachments, may contain information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated entities,  that may be confidential,  proprietary,  copyrighted  and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.

Re: On the extensibility of the core

[Esteban Franqueiro <es...@bea.com>]

Hi.

> That should already work (using the pool). Does it not? We probably should
> have a test case for this feature.

I have one. In which issue should I post it?
The catch is that, currently, in order to support concurrent reads, you have to use 
copyWhenReading=true. I'm working on a fix for this right now.

> The current garbage collector is quite basic. Extending is would be great -
> I just think the garbage collection should work the same way for all data
> store implementations (file system and database).

Mine does. It's the same I presented the other time around, but I have yet to move it to 1.4 and 
hopefully use the node iterator you created.

>> and the fact that I use a pooled data source for connections, so I need
>> a different way to create them.
>
> This feature may be interesting for others as well.

This, and all the other things I mentioned were present in the code I uploaded in JCR-1954.
Regards,

Esteban Franqueiro
esteban.franqueiro@bea.com 


Notice:  This email message, together with any attachments, may contain information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated entities,  that may be confidential,  proprietary,  copyrighted  and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.

Re: On the extensibility of the core

[Thomas Mueller <th...@gmail.com>]

Hi,

The most important is to be able to read concurrently from the data store.


That should already work (using the pool). Does it not? We probably should
have a test case for this feature.


> The rest of the changes
> are in the garbage collector


The current garbage collector is quite basic. Extending is would be great -
I just think the garbage collection should work the same way for all data
store implementations (file system and database).


> and the fact that I use a pooled data source for connections, so I need
> a different way to create them.


This feature may be interesting for others as well.

>> do we wan't people not being able to extend Jackrabbit in this way?
> >
> > I think yes.
>

Sorry, I didn't read the 'not'. I think extending Jackrabbit should be
possible.

Regards,
Thomas

Re: On the extensibility of the core

[Esteban Franqueiro <es...@bea.com>]

> Maybe your changes would helpful for others as well. What are those changes?

The most important is to be able to read concurrently from the data store. The rest of the changes 
are in the garbage collector and the fact that I use a pooled data source for connections, so I need 
a different way to create them.

> Could you post a patch?

Sure, when I have it working.

> It's not a big problem to make things protected. Only, if your code depends
> on specific behavior of Jackrabbit, and Jackrabbit changes, your code may
> break. Or, Jackrabbit may not be changed because it may break source code
> that depends on it.

I know it's a risk. In fact, the last few weeks I've been dealing with exactly what you say. But 
that doesn't mean extending Jackrabbit should not be possible. If that's not the case, then all 
classes should be made final, as a way to convey the idea that extending is not the way to go.
On the other hand, I think that if people messes with the internals of Jackrabbit, they should do 
that knowing the risks involved (what you mentioned). Jackrabbit must preserve compatibility at the 
JCR level and all published interfaces. The rest goes as-is.

>> do we wan't people not being able to extend Jackrabbit in this way?
>
> I think yes.

I don't :)
Regards,

Esteban Franqueiro
esteban.franqueiro@bea.com 


Notice:  This email message, together with any attachments, may contain information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated entities,  that may be confidential,  proprietary,  copyrighted  and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.

Re: On the extensibility of the core

[Thomas Mueller <th...@gmail.com>]

Hi,

> the current implementation doen't quite fit my needs.
> So I wanted to change some details of it.

Maybe your changes would helpful for others as well. What are those changes?
Could you post a patch?

> don't have the visibility required to be used in derived clases.
> For example, DbDataStore.moveToTempFile()

It's not a big problem to make things protected. Only, if your code depends
on specific behavior of Jackrabbit, and Jackrabbit changes, your code may
break. Or, Jackrabbit may not be changed because it may break source code
that depends on it.

> do we wan't people not being able to extend Jackrabbit in this way?

I think yes.

Regards,
Thomas