On 9/7/07, Kristian Rink <[EMAIL PROTECTED]> wrote: > > > Folks; > > > But: I don't have no clue how to get started implementing JCR against a > legacy system. So far, we do have rather clear ideas how the data (and, > thus, the repository) structure inside the DMS looks, how this will > have to look like in JCR, and we're also clear about most of the > infrastructure aspects (user authorization). I'd simply start over > implementing the interfaces provided by the JCR API package and hope > for the best... Is this a sane way to do things? Are there pitfalls > I've not yet taken into consideration? Is it a good idea at all? Or > could I do better by, say, slightly modifying parts of jackrabbit to > just, say, build a virtual repository rather than completely > implementing JCR for our environment?
Hello Kristian, I did wrote a number of custom JCR implementations for the company I work for. Like Jukka says the problem lies with the "write" access. Creating a read only JCR interface is not that difficult if you only want to have simple NodeIterator/PropertyIterator access. I used my own JDots framework (http://jdots.sourceforge.net) to build the in-memory JCR tree, with JDots it's also more easier to create a write repository. The other problems; - node/propertytype definitions, it is doable to create a write-JCR repository without the JCR nodetypes constrains especially if your legacy provides these constrains themselves. - searching, well I guess that is a real problem because it's quite hard map the JCR standard search mapping to your legacy system. I choose to just define my own search language, more or less adapting the legacy system search. The big advantage of having a JCR interface to you legacy system is to have a seamless transition to a full JCR repository. Greetings, Jacco -- > ------------------------------------- > Jacco van Weert -- [EMAIL PROTECTED] > JCR Controller -- http://www.xs4all.nl/~weertj/jcr
