[rules-dev] Accessing JCR repository directly

Thu Mar 4 17:11:54 EST 2010

yes that was exactly my point. at that time we weren't prepared or willing
to create app specific wars/sars. In a perfect world the war would work in
all containers (that isn't really possible it seems) but also be able to
work in non EE containers (that may be a JNDI issue? eg with jetty can be a
hassle).

On Fri, Mar 5, 2010 at 8:16 AM, Bernd Rücker <bernd.ruecker at camunda.com>wrote:

>  I think JNDI Deployment always require an application server (or not?).
> For JBoss the best way would be to provider a sar… But from a war you could
> register it manually as well I think, but this could get app server
> specific…
>
>
>
> *Von:* rules-dev-bounces at lists.jboss.org [mailto:
> rules-dev-bounces at lists.jboss.org] *Im Auftrag von *Michael Neale
> *Gesendet:* Donnerstag, 4. März 2010 04:35
>
> *An:* Rules Dev List
> *Betreff:* Re: [rules-dev] Accessing JCR repository directly
>
>
>
> right yes - the JNDI binding of JCR would make sense - but I wasn't sure
> how that could be delivered as a self contained war to "drop in" and not
> require significant container specific integration (correct me if wrong).
>
> On Wed, Mar 3, 2010 at 8:08 PM, Bernd Rücker <bernd.ruecker at camunda.com>
> wrote:
>
> Hmm, okay REST is one option. But I still would prefer to bind the JCR
> Repository in the JNDI (which is easily possible). This is an option we
> used already a couple of times for JackRabbit applications. By doing so,
> everybody in the app server can access it via JNDI, like any other
> datasource as well (and basically that's what a JCR Repository is).
>
> The only dependency is to have JCR on the classpath, ok.
>
> I think for the moment I will create a Servlet which reads it from Seam
> and binds the Repository to JNDI. What do you think?
>
> Having a REST or Webdav API INSIDE of the Appserver to talk from Java to
> Java just sounds technically unnecessary complicated to me...
>
> -----Ursprüngliche Nachricht-----
>
> Von: rules-dev-bounces at lists.jboss.org
>
> [mailto:rules-dev-bounces at lists.jboss.org] Im Auftrag von Jervis Liu
> Gesendet: Mittwoch, 3. März 2010 08:55
>
> An: Rules Dev List
> Betreff: Re: [rules-dev] Accessing JCR repository directly
>
> Bernd Rücker wrote:
> >
> > Hi Michael.
> >
> > Thanks for the quick answer!
> >
> > Our use case at the moment is, that we maintain the HEAD version of
> > the rules in an own table locally in the app, where we have a
> > specialized GUI for authoring. As soon as they get released we
> > leveraged the RuleTemplate to generate a DRL file, which we want to
> > check in Guvnor, from where the deployment snapshots are created,
> > versioned and so on. So we have to access Guvnor programmatically
> > (doesn’t have to be JCR).
> >
> > A second nice use case we face is to hang in the Drools Repository
> > into a bigger JCR-Content-Tree (in the area of ModeShape), so there
> > JCR would be nice. Then we could use the JCR Explorer, written from
> > one of my colleagues, to have a look at the repos as well. But okay,
> > this is why we want to use JCR.
> >
> > But the most important issue is to access the Repository
> > programmatically from an EJB3. Maybe we could get around classloading
> > isolation and just access some static stuff for that. Or making the
> > ServiceImplementation really more generic usable, that would be
> > wonderful as well. But as it sounds it will take some time and will
> > not be released pretty soon? Then we have to find another way for now,
> > since if avoidable I don’t want to patch drools. So you mean I should
> > use the internal Remote Interface the GWT GUI is using? Where can I
> > find that and how can I create a correct reference?
> >
> > Or I have to use Webdav, but this looks pretty cumberstone to use it
> > internally in one JBoss server instead of pure Java mechanisms?
> >
> > Thanks and cheers
> >
> > Bernd
> >
>
> Hi Bernd, this might be related:
> *http://lists.jboss.org/pipermail/rules-users/2009-December/011618.html
>
> *Basically the idea is that you expose ServiceImplementation as a remote
> service. As far as how the remote service is implemented, one way to go
> is to expose ServiceImplementation as RESTful service. Guvnor already
> has some Atom/Pub capabilities.It may not match your request yet, but if
> you have a concrete requirement on what methods in ServiceImplementation
> you want to expose remotely, we can look into it and get it addressed
> either by extending Atom/Pub capabilities that Guvnor already has (for
> this, take a look at
> http://anonsvn.jboss.org/repos/labs/labs/jbossrules/trunk/drools-guvnor/sr
> c/main/java/org/drools/guvnor/server/files/<http://anonsvn.jboss.org/repos/labs/labs/jbossrules/trunk/drools-guvnor/sr%0d%0ac/main/java/org/drools/guvnor/server/files/>
> )
> or by providing a truly RESTful service layer on top of Guvnor server.
>
> Cheers,
> Jervis
> >
> > *Von:* rules-dev-bounces at lists.jboss.org
> > [mailto:rules-dev-bounces at lists.jboss.org] *Im Auftrag von *Michael
> Neale
> > *Gesendet:* Montag, 1. März 2010 00:27
> > *An:* Rules Dev List
> > *Betreff:* Re: [rules-dev] Accessing JCR repository directly
> >
> > Hi Bernd. yes you have it correctly - seam starts things up.
> >
> > IN terms of accessing JCR directly, this came up before and one idea
> > was to use the "remote" JCR interface - that means some refactoring I
> > guess.
> >
> > So the basic design is that there is a JCR server that starts up, and
> > the "clients" connect remotely (a client in this case is also the
> > Guvnor server side).
> >
> > That way you can access it from multiple places. However, it may be a
> > bit too low level for this - the question is what do you want to
> > access JCR for from your external app?
> >
> > A better approach, is to make the ServiceImplementation a true remote
> > interface (at the moment it is, but for GWT clients only) - so ANY
> > sort of client can connect and access the guvnor services, without
> > messing with low level data structures - I am thinking the latter is
> > the superior approach (and someone else was looking at it).
> >
> > Michael.
> >
> > On Sun, Feb 28, 2010 at 4:53 AM, Bernd Rücker
> > <bernd.ruecker at camunda.com <mailto:bernd.ruecker at camunda.com>> wrote:
> >
> > Hey guys.
> >
> > I thought I better ask that question on the dev list, correct me if
> > that was a bad choice ;-)
> >
> > I want to programmatically access the JCR repository from another
> > application (basically to author rules). I understood the
> > RulesRepository (which is a nice interface by the way). I tried to
> > understand how the JCR Session is created and can be accessed. As far
> > as I found it, it seems that a Seam Bean just starts everything
> > (RulesRepositoryManager). Now the question is: How can I access this
> > from another application? Because the workspace is locked, I cannot
> > create another Session from there.
> >
> > Wouldn’t it be nice to bind the stuff in JNDI correctly or something
> > like that? Or if I do that, can I inject it into the Seam application?
> > Or maybe I can access the seam bean somehow from external?
> >
> > I think it would be the easiest and best to access the JCR repos
> > instead of using WebDav or whatever if I am in another EJB3 application…
> >
> > Thanks a lot for any hint
> >
> > Cheers
> >
> > Bernd
> >
> > --
> >
> > Blog: _www.bpm-guide.de <http://www.bpm-guide.de>_
> >
> > ---------------------------------------------
> >
> > camunda services GmbH - The Business Process Company
> >
> > Zossener Straße 55-58 - 10961 Berlin
> >
> > www.camunda.com <http://www.camunda.com> - info at camunda.com
> > <mailto:info at camunda.com>
> >
> > ---------------------------------------------
> >
> > Bernd Rücker
> >
> > Geschäftsführer
> >
> > Telefon +49 30 664040 901
> >
> > Mobil +49 171 1473461
> >
> > bernd.ruecker at camunda.com <mailto:bernd.ruecker at camunda.com>
> >
> > ---------------------------------------------
> >
> > Amtsgericht Charlottenburg: HRB 113230 B
> >
> > Geschäftsführer: Jakob Freund, Bernd Rücker
> >
> > ---------------------------------------------
> >
> > BPMN-Buch: http://www.hanser.de/buch.asp?isbn=978-3-446-41768-7
> >
> > EJB-3-Buch: http://www.ejbbuch.de/
> >
> >
> > _______________________________________________
> > rules-dev mailing list
> > rules-dev at lists.jboss.org <mailto:rules-dev at lists.jboss.org>
> > https://lists.jboss.org/mailman/listinfo/rules-dev
> >
> >
> >
> >
> > --
> > Michael D Neale
> > home: www.michaelneale.net <http://www.michaelneale.net>
> > blog: michaelneale.blogspot.com <http://michaelneale.blogspot.com>
> >
> > ------------------------------------------------------------------------
> >
> > _______________________________________________
> > rules-dev mailing list
> > rules-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/rules-dev
> >
>
> _______________________________________________
> rules-dev mailing list
> rules-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
> _______________________________________________
> rules-dev mailing list
> rules-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
>
>
>
>
> --
> Michael D Neale
> home: www.michaelneale.net
> blog: michaelneale.blogspot.com
>
> _______________________________________________
> rules-dev mailing list
> rules-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
>
>

-- 
Michael D Neale
home: www.michaelneale.net
blog: michaelneale.blogspot.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-dev/attachments/20100305/81045baa/attachment-0001.html 