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.ruec...@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-boun...@lists.jboss.org [mailto: > rules-dev-boun...@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.ruec...@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-boun...@lists.jboss.org > > [mailto:rules-dev-boun...@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-boun...@lists.jboss.org > > [mailto:rules-dev-boun...@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.ruec...@camunda.com <mailto:bernd.ruec...@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> - i...@camunda.com > > <mailto:i...@camunda.com> > > > > --------------------------------------------- > > > > Bernd Rücker > > > > Geschäftsführer > > > > Telefon +49 30 664040 901 > > > > Mobil +49 171 1473461 > > > > bernd.ruec...@camunda.com <mailto:bernd.ruec...@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@lists.jboss.org <mailto:rules-dev@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@lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/rules-dev > > > > _______________________________________________ > rules-dev mailing list > rules-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/rules-dev > _______________________________________________ > rules-dev mailing list > rules-dev@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@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@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-dev
