Thanks for your reply!
Compile time is not an option, since the metamodel might change during
runtime.
One non functional requirement is also to keep the metamodel/model free from
technology dependent stuff, because the same metamodel/model is used in
different parts of the system, among them might be other rule engines
(partially plugged in by client, partially old legacy code).
Thanks,
ron.
Greg Barton wrote:
Have you considered using hibernate? You could generate the pojos
at
compile time, so they can be jarred up and sent to guvnor. You can
specify the interfaces the pojos must implement in the hibernate mapping
file, if you want to go that route. And of course all of the db access
interception via proxy is handled by hibernate as well.
--- On Mon, 2/9/09, Ronald Brindl <rbrindl(a)thegoldensource.com> wrote:
> From: Ronald Brindl <rbrindl(a)thegoldensource.com>
> Subject: [rules-users] Re: Defining facts declaratively with
> TypeDeclaration and assert facts from java To:
> rules-users(a)lists.jboss.org Date: Monday, February 9, 2009, 9:17 AM
> Thank you!
>
> I already saw that piece of documentation (i am looking at
> trunk), and that
> was what lead me into that direction.
> However, is there some possibility to get access to the
> generated classes? I
> mean, our application (and the domain model classes) is
> potentially
> distributed among several JVM's. So what i am looking
> for is that the DRL
> declarations are generated in our application during
> startup, then they are
> deployed to guvnor to allow business user use the facts,
> and then have the
> generated classes at the application side again, to feed
> the facts. Is this
> possible somehow, or am i going in the wrong direction?
>
> I also still have the problem, that there SHOULD be the
> possibility to
> intercept attribute access to the facts, to make lazy
> loading of attributes
> from the database possible.
> So maybe the better solution is to generate interfaces,
> give them to guvnor
> and implement the access logic to incoming messages and
> existing messages
> in the db with a proxy.
> I dont want to go via XML in any way if i can avoid it...
>
> However, i will have a look at the spots you pointed out
> and see, what i
> find there...
>
> Thank you,
> ron.
>
> Edson Tirelli wrote:
>
> > Ronald,
> >
> > Last week I wrote the docs for TypeDeclaration. So,
> you may try the
> > docs
> > first hand and provide me feedback! ;)
> >
> >
>
https://hudson.jboss.org/hudson/job/drools/lastSuccessfulBuild/artifact/t...
> >
> > The API was promoted from drools-core to drools-api
> after M5 was
> > released, so you need trunk to use it.
> >
> >
>
https://hudson.jboss.org/hudson/job/drools/lastSuccessfulBuild/artifact/t...
> >
> > Regarding your questions, I believe this is
> probably the easiest way of
> > doing it, but not the only one. Just to mention
> another way would be to
> > generate a JAXB domain model from your database and
> upload it as a jar to
> > Guvnor.
> >
> > If you want to dive into Drools internals and see
> how the classes are
> > generated, take a look at
> org.drools.factmodel.ClassDefinition in
> > drools-core as your starting point. From there you can
> navigate through
> > the code searching for the references. IMO though, you
> don't need to go
> > down this route.
> >
> > Regarding the pipeline, if you want to customize it
> for your needs, you
> > just need to create an intermediate step or use smooks
> to map from one
> > model into the other. I think mark did not added a
> step to map from an
> > external model into a type declared model yet.
> Contributions welcome.
> >
> > Hope this helps,
> > Edson
> >
> >
> >
> > 2009/2/6 Ronald Brindl
> <rbrindl(a)thegoldensource.com>
> >
> >> Referring to threads
> >>
>
http://thread.gmane.org/gmane.comp.java.drools.devel/2860
> >> Dynamic Facts: how to get jar wih Facts
> declared in drl
> >>
>
http://thread.gmane.org/gmane.comp.java.drools.devel/2595
> >> TypeDeclaration plugin heirarchy
> >>
> >> I am just in the process of evaluating the
> possibilities of using Drools.
> >>
> >> Our use case is the following:
> >> We have a dynamic metamodel, which gets generated
> from database during
> >> application initialisation phase. Then a runtime
> model gets
> >> instantiated, which is fed from incoming messages
> (files, jms, etc.)
> >> Both models are highly generic, basically maps of
> maps (lists of lists,
> >> for model instances)
> >>
> >> Now, i would like to publish the metamodel to
> Guvnor as fact model, so
> >> that business rules users can use it there and
> define
> >>
> >> In the last 2 days i dived into the sources, read
> the mailing list
> >> entries above, documentation and so on, but i
> still don't have a clear
> >> vision on how to accomplish that.
> >>
> >> Our first approach was to use TypeDeclaration,
> i.e. to dynamically create
> >> DRL that defines the fact types as defined in our
> metamodel, but i don't
> >> have a clue on how to assert data for those types,
> since i don't have the
> >> resulting java classes available in Java.
> >> (There was also some confusion: in the
> documentation (M5) it says,
> >> bytecode is generated for declaratively defined
> Facts, but i could not
> >> find anything in the code, where this byte code is
> generated)
> >>
> >> Our next approach was to generate interfaces as
> Fact types and create
> >> proxies to access the data. This would also allow
> us to implement another
> >> use case, that demands access to messages already
> stored in the database
> >> with the same id as the incoming messages, and
> compare what fields are
> >> new and to provide merging of new and old data.
> >>
> >> I also had a quick look at the new Pipeline
> concept, but as far as i
> >> understand that, it builds on a statically defined
> FactModel.
> >>
> >> Then i dived a little bit more into the code and
> saw code generation for
> >> accessing Java class facts, which also might be a
> reasonable solution for
> >> us.
> >>
> >> However, what i was asking myself was, if there is
> some entry point for
> >> functionality like that, some existing API.
> >>
> >> Thank you,
> >> ron.
> >>
> >>
> >> --
> >> Ronald Brindl
> >> Sr. Software Developer
> >> Member of Architecture Team
> >> The Goldensource Corporation
> >>
> >> _______________________________________________
> >> rules-users mailing list
> >> rules-users(a)lists.jboss.org
> >>
>
https://lists.jboss.org/mailman/listinfo/rules-users
> >>
> >
> >
> >
>
> --
> Ronald Brindl
> Sr. Software Developer
> Member of Architecture Team
> The Goldensource Corporation
>
> _______________________________________________
> rules-users mailing list
> rules-users(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/rules-users
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
--
Ronald Brindl
Sr. Software Developer
Member of Architecture Team
The Goldensource Corporation