incubator-graffito-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dan Connelly <dsconne...@adelphia.net>
Subject Re: use of jcr mapping for JSR170, in graffito
Date Wed, 30 Aug 2006 11:49:18 GMT
Ruchi:

The jcr mapping download includes certain Eclipse-specific files, which 
tells me that it should run "out of the box" in Eclipse.

And it did run "out of the box" on Eclipse for me except for 1) 
replacing the classpath references to the Maven (remote?) repository, 2) 
re-ordering elements custom_nodetypes.xml, needing to supply my own 
JUnit "runner" classes.

I did not have the IDE navigational problems you describe except for a 
very minor issue that the DTD path in the jcrmapping_xxxx.xml files is a 
relative path.     Validating the xml files during a JUnit run works 
fine.   But, when I try to get Eclipse to validate the xml directly in 
the IDE, then the DTD file cannot be found.  

I am not sure why I needed to supply JUnit runners this since Eclipse is 
supposed to support the AllTests.suite( ) static method in its own JUnit 
runner.    (Maybe there is some JUnit config I am missing.)

If using Eclipse is not an option for you, then you might try running 
Maven from the command line.   I did not try this, but it should also 
work "out of the box."   Or use the MevenIDE plugin for NetBeans to 
drive Maven from the IDE.

MevenIDE is also available for Eclipse, but I did not try this.

    -- Dan



ruchi goel wrote:

> 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