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
