|
[
Permlink
| « Hide
]
Costin Leau added a comment - 28/Feb/07 07:03 AM
unfortunately CND is not something included in the spec and it's Jackrabbit specific. I'll add a specifialized subclass for JR to deal with this case to make sure the module remains dependent only on the spec API.
Just added a JackrabbitSessionFactoryBean to deal with custom node registration in the CVS. I haven't tested yet - feel free to comment on it. The only problem is what happens if the registration occurs twice (between reruns) - does JR throws an exception or not?
Wolf, please take a look at the JackrabbitSessionFactory in the CVS. I'm not sure if the class is going to make it in 0.8 since the behavior of node registration is a undocumented (what happens if the types are reregistered, is unregistration supported) and from checking the list, automatic node registration might be supported in a future version.
Let me know if the class works for you and if you have any suggestions (I'm thinking of something similar to namespace registration here - unregistering the types (if possible) at shutdown). Hi Costin, sorry for the late reply, was a mad day again.
To go through yr remarks one at the time: 1/ I found this snippet on the JR list, as the preferred way to register Custom NodeTypes, perhaps it is helpful: JackrabbitNodeTypeManager.registerNodeTypes(InputStream, String) provides an easy and convenient way of registering your custom node types incl. any referenced namespaces, e.g. JackrabbitNodeTypeManager manager = (JackrabbitNodeTypeManager) session.getWorkspace().getNodeTypeManager(); manager.registerNodeTypes(new FileInputStream("mytypes.cnd"), JackrabbitNodeTypeManager.TEXT_X_JCR_CND); 2/ Registering a NS twice is no problem (same effect as adding an item with the same key to a HashMap; it is just overwritten) 3/ FYI (smth that was unclear to me before): it's apparently not the purpose to put CND files into /repository/nodetypes -- this directory is meant for the built-in node types (like nt:unstructured) I guess it's logic place would then be /workspaces/myWorkSpaceName/nodetyes 4/ Yr code looks OK. :-) 5/ W.r.t. Namespaces: the namespaces are declared in a CND files and I cannot imagine an app without custom nodes so I think NS should not be declared separately, but implicitely by pointing to the CND file. What I don't know is, whether loading the CND file makes a CR *automatically* register the NSes declared in this file. It should, but if it doesn't, then obviously the Spring bean should adopt these redundant properties. (as I'm a newby to CR too, I'm still struggling with all this too, as you can see :-) I think it's already awesomly cool Spring adopts support for it THIS fast. 6/ W.r. t. the previous, a suggestions: as Spring embraces the JSR170 spec on ist turn, why not asking David Nuescheler in person (the spec lead ) for a judgement in these matters? I've mailed him a few times and it's absolutely amazing how accessible he is and how he takes the time to reply mails. I really brings down the barrier to use CRs, he truly lives the evangelising aspect of being spec lead. (as is the case with Spring, as is being proved by the mere fact I am typing stuff here!) -> his @ is david.nuescheler@gmail.com Will save you a lot of time and e's Mr Reference himself his replies WILL be rock solid. Wolf long comment.
Thanks for the pointers and feedback. I'll update my code, commit it to the CVS, ask you again to give it a try (would be great if you have a sample CND to test against and commit it back so I can add some tests for it). The only thing holding me back from releasing the class, is having a test suite for it (which require a CND and some node manipulation) - feedback in this area would be nice. 5. when it comes down to namespaces, registration of a namespace under the same prefix fails so I assumed the same thing happens with node type definitions. The JCR module is about integration not embracement - the project has been in the works for quite a long time already. I've been looking also at JCR mappers (which I think are the next logical step) and even playing with an implementation of my own. However, as much as would like working on it, I put it down. Thanks for David's contact - we exchanged some emails through JR mailing list; I'll contact him in case I have to. commit done - Wolf can you please test it and report back? Thanks.
Hi Costin,
The code works fine again, thanks :-) I'm working on a complete test case myself, but I'm still struggling to make it work. I'll add it *as soon as* it's finished. (should you need one earlier, you should ask a more experienced JR user, perhaps on the JR list - for me all this is still new at the moment that why it takes me more time) The tests I am working on will also involve CRUD ops e.g. If you're looking at JR-mapping, perhaps have a look at the graffito project (http://incubator.apache.org/graffito/), that's the one I think looks the most promising. Wolf Heh - you should read the JCR module documentation carefully next time :).
I'll be waiting on your task - 0.8 will be out this week if everything goes according to the plan. Costin,
Meanwhile I had some feedback on the concerns about JR & Namespaces earlier: 1/ "nodetype administration is left out in the spec at all" (-> JR assumes no responsability in these matters) 2/ The spec also states: "An implementation may prevent the unregistering of any other namespace for implementation-specific reasons by throwing a NamespaceException." ... Wolf Hi Costin,
I see in the new SpringModules documentation it appeared already (10.2.1.3. NodeTypeDefinition registration), in the dedicated "jackrabbitSessionFactory" bean. Does it work, or is it postponed to v.0.9 because there are still issues with it? Best regards, Wolf You can d/l springmodules 0.8 and see for yourself :). the code is already included though, to my shame, I didn't manage to test is throughly.
In the referenced forum discussion, "bilobag" discusses why node type registration in the JackrabbitSessionFactory fails if a node type already exists (http://forum.springframework.org/showpost.php?p=126179&postcount=17). I ran into this problem using Maven whenever my unit tests ran more than once (e.g. "mvn clean package install").
I'm attaching a quick diff to JackrabbitSessionFactory#1.3 which introduces a new property to control whether node types are re-registered or not. This fixed my Maven issue. simple addition to JackrabbitSessionFactory which allows configuration of whether to re-register node types.
These are just the changes I need, please add this diff!
|
|||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Improvement
Open
Major
Allow the SessionFactory to register the CND file by pointing to it in the sessionFactory Spring bean
