using jcr-mapping layer to access repsitory over RMI

[Ruchi Goel]

Hi,
   If I tweak the jcr-mapping layer to access a remote jcr repository, I
should be still able to use jcr-mapping layer. Please confirm.
I guess it should not be a problem , except for that custom node type
registration should be  done at the server end.


Thanks,
Ruchi

[Jukka Zitting]

Hi,

On 2/14/07, ruchi goel <Ruchi.Goel@...> wrote:
> If I tweak the jcr-mapping layer to access a remote jcr repository, I
> should be still able to use jcr-mapping layer. Please confirm.
> I guess it should not be a problem , except for that custom node type
> registration should be  done at the server end.

Yes, I think this should work. Please file a bug report if it doesn't. :-)

BR,

Jukka Zitting

[Christophe Lombart]

You are welcome to contribute your test result to us (even it works
like a charm) :-)
This kind of info could be added in the website.

Thanks
Christophe

On 2/14/07, Jukka Zitting <jukka.zitting@...> wrote:

> Hi,
>
> On 2/14/07, ruchi goel <Ruchi.Goel@...> wrote:
> > If I tweak the jcr-mapping layer to access a remote jcr repository, I
> > should be still able to use jcr-mapping layer. Please confirm.
> > I guess it should not be a problem , except for that custom node type
> > registration should be  done at the server end.
>
> Yes, I think this should work. Please file a bug report if it doesn't. :-)
>
> BR,
>
> Jukka Zitting
>

[Ruchi Goel]

Sure , I will do so.

BTW , I checked out the report posted at
http://mail-archives.apache.org/mod_mbox/incubator-graffito-dev/200702.mbox/%3c3b728ee90702140445i5d21bd22j95fb5b67c58abc70@...%3e


I have a question :

Here is extract from the report:

/The Content Model :
------------------------------
* Our content model has to be extensible without imposing specific
content types./


Why do you say so ?  Isn't it already extensible with a flexibility of
adding more content types ? In fact I was thinking of dropping the idea
of having my document inherited from nt:file . Instead use , something
which can be mapped to nt:unstructured , so that I can have root cms
object, completely extensible ,  with all services acting at the this
object and available to all child content types.


Another question is are there any timelines decided for this refactoring
work ?

Thanks,
Ruchi

Christophe Lombart wrote:

> You are welcome to contribute your test result to us (even it works he
> like a charm) :-)
> This kind of info could be added in the website.
>
> Thanks
> Christophe
>
> On 2/14/07, Jukka Zitting <jukka.zitting@...> wrote:
>> Hi,
>>
>> On 2/14/07, ruchi goel <Ruchi.Goel@...> wrote:
>> > If I tweak the jcr-mapping layer to access a remote jcr repository, I
>> > should be still able to use jcr-mapping layer. Please confirm.
>> > I guess it should not be a problem , except for that custom node type
>> > registration should be  done at the server end.
>>
>> Yes, I think this should work. Please file a bug report if it
>> doesn't. :-)
>>
>> BR,
>>
>> Jukka Zitting
>>

[Christophe Lombart]

On 2/15/07, ruchi goel <Ruchi.Goel@...> wrote:

> I have a question :
>
> Here is extract from the report:
>
> /The Content Model :
> ------------------------------
> * Our content model has to be extensible without imposing specific
> content types./
>
>
> Why do you say so ?  Isn't it already extensible with a flexibility of
> adding more content types ? In fact I was thinking of dropping the idea
> of having my document inherited from nt:file . Instead use , something
> which can be mapped to nt:unstructured , so that I can have root cms
> object, completely extensible ,  with all services acting at the this
> object and available to all child content types.
>
>

Yes, the JCR is extensible, of course.
But if our persistence service stores business objects (pojo) into a
JCR repo, this persistence's service should not impose the usage of a
specific object model.
Right now, it is not possible to extends the Graffito Object model easily
To be more flexible, the current CmsObject class has to be deleted in
the Graffito framework.

> Another question is are there any timelines decided for this refactoring
> work ?
>

It will depend on the contribution. Personally, I'm working on the
first release of the OCM tools but if someone wants to work on OCM
issues, I can start the refactoring.

[Ruchi Goel]

Christophe Lombart wrote:

> On 2/15/07, ruchi goel <Ruchi.Goel@...> wrote:
>
>> I have a question :
>>
>> Here is extract from the report:
>>
>> /The Content Model :
>> ------------------------------
>> * Our content model has to be extensible without imposing specific
>> content types./
>>
>>
>> Why do you say so ?  Isn't it already extensible with a flexibility of
>> adding more content types ? In fact I was thinking of dropping the idea
>> of having my document inherited from nt:file . Instead use , something
>> which can be mapped to nt:unstructured , so that I can have root cms
>> object, completely extensible ,  with all services acting at the this
>> object and available to all child content types.
>>
>>
>
> Yes, the JCR is extensible, of course.
> But if our persistence service stores business objects (pojo) into a
> JCR repo, this persistence's service should not impose the usage of a
> specific object model.
> Right now, it is not possible to extends the Graffito Object model easily

Yes, to create a new content type , one has to inherit from existing
CmsObject class . But I thought that is the strength of  graffito
framework since all the services are associated with base class and if
someone adds a new contenttype , e.g. article, he gets those services
already implemented.
> To be more flexible, the current CmsObject class has to be deleted in
> the Graffito framework.
Don't understand why ?

-Ruchi





>
>> Another question is are there any timelines decided for this refactoring
>> work ?
>>
>
> It will depend on the contribution. Personally, I'm working on the
> first release of the OCM tools but if someone wants to work on OCM
> issues, I can start the refactoring.