jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrei Latyshau" <andrei.latys...@gmail.com>
Subject Re: Use JackRabbit CMS for storing Business Objects
Date Fri, 22 Aug 2008 07:48:07 GMT
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 <michael.wechner@wyona.com>

>
> 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
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message