I understand your point, but we are not developing framework, but a concrete business platform. Usage of JCR API and then implementation of this is on a order more effort consuming task. We can implement the Data Layer on top of JPA.
... Business Objects Layer | (1) Data Layer: JCR or JPA | (2) Implementation: JackRabbit or Hibernate (we use other JPA impl) ... When we choose JCR on (1) layer, then in future we can build (1) on top of e.g. JPA or JDBC, but :))) we are not going implementing custom CMS. We need now to design and start implementing (1) and it is a very big risk to depend on JCR, as we currently do not see the real enterprise solution for this direction. When you can suggest here something it will be very helpful: e.g. some other JCR implementation like Oracle when it exists etc.. Otherwise we have to build our stack on top of JPA. Currently we are looking experts, but unfortunately nobody gives an appropriate response. Thank you very much for your answers! Regards, Andrei 2008/8/22 Michael Wechner <[EMAIL PROTECTED]> > > I think you should focus less on Jackrabbit itself, but rather on the API > and think of what does it mean effort/development wise > to replace the JCR implementation (for example Jackrabbit) by something > else (either third-party or a custom Jackrabbit or your own implementation > of JCR). > > For example Jackrabbit seems to have a performance/scalability problem > retrieving the most recent version of a node if a node has many versions > (e.g. 50K). So the question is, is this "just" an implementation problem or > an API problem itself. And if it is an implemetation problem how can it > fixed. If it is an API problem, then I think it's more troublesome. > > HTH > > Michael >
