incubator-graffito-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From ruchi goel <Ruchi.G...@Sun.COM>
Subject Re: use of jcr mapping for JSR170, in graffito
Date Tue, 29 Aug 2006 11:29:00 GMT
Hi Dan,
   I followed the steps as mentioned by  you. I created this project in 
Netbeans. Could build it successfully. But when I try to run test, all 
the test files cannot access the path for xml mappings in test-config.

These test files hard code the path of  config files as follows :
"./src/test-config/<mapping file>"

Netbeans  is not able to resolve the current directory . If I  
substitute with exact path, it works.

Did you face the same problem in Eclipse ?

Another issue is the test files do not exist in the exact package names 
where the source files exist. e.g
DefaultCollectionConverterImpl is under package 
org.apache.portals.graffito.jcr.persistence.collectionconverterimpl

but
DefaultCollectionConverterImplTest  is under package 
org.apache.portals.graffito.jcr.persistence.collectionconverter


Netbeans cannot map the test file to source file until they are in the 
same package .

Thanks,
Ruchi


Dan Connelly wrote:

>  Hi Ruchi:
>
> I am also a newcomer to Graffito (and a refugee from Eclipse Apogee).
>
> What I did  to get started with jcr mapping is to Check Out the 
> jcr-mapping code (under jcr folder) as a project in Eclipse.   With 
> Eclispe SVN Repository perspective, the project creation is automatic 
> on the Check Out..   A no-brainer.    (Note:  mapping itself does not 
> require anything else from Graffito.)
>
> Then you will try to run the JUnit tests (in Eclipse) from your jcr 
> mapping project.    The tests are in the download.
>
> You will need to fetch a bunch of libraries to get rid of the initial 
> errors in this testing.   An easy way to get these libraries (most of 
> them anyway) is to import the Jackrabbit server war (as an Eclipse 
> Dynamic Web project) and ref its jars from your mapping project.
>
> You do NOT need the graffito api at all.    The Graffito jcr mapping 
> uses Jackrabbit directly (as far as I can tell).
>
> ---------------------------
> 2 hints:
>
> 1) A small change is needed in custom_nodetypes.xml in the test 
> config.  Move  graffito:documentstream ahead of  graffito:documentimpl 
> in this file.
>
> 2)  Get the Jackrabbit core source and put this in a third Eclipse 
> project.    Reference this project from your jcr mapping project.   
> This is not a requirement but it will make Eclipse's debug traces a 
> lot easier to follow.
>
> -----------------------------
> 3 observations:
>
> 1)  The object mapping itself is a pretty simple affair, maybe too 
> simple. (Jury is still out on this.)  You must create the mapping by 
> hand, but this is much easier than for Hibernate or JPOX mappings.   
> However, the Graffito documentation is somewhat behind its code.    
> For instance, you need to read the comments in the mapping DTD and 
> look at the code to figure out inheritance mapping.   Also, it appears 
> that for non-containment references, you need to program these 
> references as JCR Paths.   Simple object constraints (like no dangling 
> references), may be missing from Graffito.    JCR versioning may 
> mitigate (or exacerbate?) the dangling ref problem.   This is still a 
> mystery for me.
>
> 2)  Jackrabbit transaction locking is still new territory for me 
> too.   However, with or without transactions, any object updates are 
> "very" slow.   Concurrency, too, may be limited if big chunks of 
> content get locked during a transaction.    If you want frequent, 
> transactional updates on objects and you want high concurrency (like 
> optimistic locking), it may be that you need to stick with Hibernate 
> over a RDBMS.  On the other hand, if your applications are mainly 
> read-only (like a business reporting tool) then jcr mapping may 
> provide much better access control than you would get using 
> Hibernate.   (Jury is still out here, too.)
>
> 3.  Multiple inheritance is a valid association of objects in a model 
> (though Java does not support it well).      Ideally jcr mapping 
> should deal with such a model.    It does not appear to so at this 
> time.    With mixin types available in JCR, I had hoped for more.    
> ("Mixin" being C++ slang for multiple inheritance.)
>
>    -- Dan Connelly
>
>
>
> ruchi goel wrote:
>
>> Hi,
>>   I am a  newcommer  to graffito area and  am in process of 
>> evaluating graffito for integration with our portal server.
>>
>> I am mainly interested in knowing the navigation  as to how graffito 
>> stores its java objects in JSR170 compliant repository. I understand 
>> that graffito uses Jackrabbit. I have gone through the documentation 
>> on graffito's web site and my understanding is that graffito is 
>> mapping a java object to a jcr node (via mapping's file) , and then 
>> use JSR170 on the node to talk to Jackrabbbit repository.
>>
>> I have downloaded the latest bits  , build, installed and deployed on 
>> jetspeed. I use debugger to check the flow , but I am finding  that  
>> it uses GraffitoOJBStore .
>>
>> *Is the jcr mapping layer not being used in the current code to talk 
>> to JSR170 repository. ?*
>>
>> Though I see the code in place in the source tree : packages 
>> org.apache.portals.graffito.jcr
>>
>>
>> Help appreciated.
>>
>> Thanks,
>> Ruchi
>>
>


Mime
View raw message