Re: Tight coupling to XML configurations

One thing that would be useful is if I wanted to add "container"  
generated properties.  For example, Jackrabbit automatically  
generates the properties such as uuid.  It would be pretty handy if I  
could write an interceptor that would pre-populate nodes of a  
particular type with a particular set of properties.   This  
generation of said properties is a cross-cutting concern and so is  
best handled by an interceptor.

Regards,
Alan

On Sep 1, 2007, at 10:10 AM, Felix Meschberger wrote:

> Hi,
>
> Consider the PersistenceManager a low level storage mechanism for  
> data.
> Thus, if you want to do special things, you have to use a different
> PersistenceManager.
>
> The major misconception is, that JCR is a CMP container. It is a
> repository more comparable to a database. As such, JCR may be used as
> the persistent store for a CMP container. Therefore, there is no such
> things as interceptors at the moment. And most probably, there will  
> not
> be such things on the PersistenceManager level unless you implement it
> yourself. But I am not sure, whether this would be a good idea.
>
> Regards
> Felix
>
> Am Freitag, den 31.08.2007, 10:57 -0700 schrieb Alan D. Cabrera:
>> Thoughts?
>>
>> On Aug 28, 2007, at 9:16 AM, Alan D. Cabrera wrote:
>>
>>>
>>> On Aug 27, 2007, at 11:16 PM, Thomas Mueller wrote:
>>>
>>>> Hi,
>>>>
>>>> Yes, in my view, repository.xml and workspace.xml should go away
>>>> or at
>>>> least be less visible for a user. Or do you mean something else  
>>>> with
>>>> XML configuration?
>>>
>>> I don't see why we would want to make configuration files less
>>> visible to the users but that's for a different thread.
>>>
>>> Currently, the way the JCR server is booted up is tightly
>>> integrated w/ XML.  For example, the repository configuration
>>> object holds an XML snippet that it uses as a template to generate
>>> new workspaces.  This is what I mean by tight coupling.
>>>
>>> Ideally, we would have factories.  This gives me more control.
>>>
>>>>> interceptor stacks
>>>>
>>>> Could you provide an example?
>>>
>>> The current architecture of Jackrabbit seems to be tightly coupled
>>> with extensions being implemented via inheritance and overriding
>>> certain methods.  ATM, when I want to provide virtual properties to
>>> a node, I have to inherit from an existing persistent manager (PM)
>>> and override methods such as load(PropertyId).
>>>
>>> I was thinking that a JCR is really like a CMP container.  Having
>>> worked on OpenEJB the use of interceptors immediately springs to
>>> mind.  We can provide all sorts of cross cutting behavior, e.g.
>>> security, remoting, tx, by just inserting new interceptors.
>>>
>>> Take my comments with a grain of salt; I don't fully grok the
>>> architecture.
>>>
>>>
>>> Regards,
>>> Alan
>>>
>>>
>>
>
>