We use our own API which currently only has a jackrabbit impl - although
note that jackrabbit can have several backend types from disk, to memory
to database, where is even a hibernate persistence store. Creating a JCR
like implementation is a lot of work, we chose jackrabbit as it is
opensource and a standard and provides much of what we need out of the
box - why spend a month or three creating something that is like JCR but
is implemented with hibernate instead of just just using JCR? So in
reality our choice for JackRabbit is about time and leveraging what is
available, as there are no clear alternatives out there. That does not
mean we are against an alternative backend store, indeed Mic is mucking
around with a Scala implementation, we wrote against our own API exactly
so that we could replace JCR if we ever deemed it necessary. If someone
was to make a better backend for us, we would consider using it.
Mark
Michael Rhoden wrote:
Couple questions about the JBRMS persistence layer. I have been
trying to figure out how to upgrade and incorporate the new 4.03 code into my current app
using 2.x and 3.x drools. After many months of off and on playing with 4.x I want to see
if I have some things straight.
1) JBRMS is built atop Jackrabbit. It appears this is the only option for
persistence. Is this correct?
2) It seems Jack Rabbit and the whole JCR standard, while nice I guess for coders,
seems difficult to integrate with. All objects are stored as binaries, even in the db
persistence manager and there is no way to access the rules except programmatically.
Correct?
3) Assuming I'm on the right track with the above two items, and please
don't take this the wrong way, I love you guys and what you are doing, why use
Jackrabbit?
It seems like a real bad idea to have an open system to store rules and then
lock it away. I'm sure you guys have some good reasons but I'm having a real tough
time and quite frankly am disappointed. From my perspective rules are one of the major
assets of my company. I can't allow them to be locked up in a system. I must be able
to access them from a jdbc source for backups, conversion, referencing, reporting, etc.
The data however complex in structure must be transparent. Say I want to convert off
Drools for another engine, or build around the JBRMS data structure to extend the app for
proprietary purposes, or just want to access the rules in an indexed way to present them
to power users to see the guts of a rule inside our application. Maybe you can do this
now, I just haven't seen the light.
Again I understand JBRMS is still quite new, and my hope Jackrabbit was just the quick
and dirty way to get this deployed.
4) Are there any plans to have a straight jdbc persistence atop a hibernate (plug
the ole JBoss way) backend?
Not to leave you with just negative bits. Drools 4.x rocks and regardless of using the
JBRMS we are looking at porting up to the latest version. The new frontend UI (coming
soon) to the JBRMS looks nice too. Thanks for all the hard work.
-Michael
------------------------------------------------------------------------
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users