gmane.comp.java.drools.devel

Re: [rules-dev] Re: [rules-users] Drools5M3 Issues

Michael Neale — 2008-11-30T07:04:30

No that won't help as it still is the same classname from the IDE content assistance point of view. No quick fix I can see, the only 3 options are to tweak the IDE to ignore the "old" or internal ones, or use differnt classnames for the new ones ;) - probably not practical. Sent from my iPhone On 29/11/2008, at 7:38, Mark Proctor codehaus.org> wrote: _______________________________________________ rules-dev mailing list rules-dev< at >lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-dev

Re: [rules-dev] Unable to Check-In

Michael Neale — 2008-11-30T07:02:00

_______________________________________________ rules-dev mailing list rules-dev< at >lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-dev

[rules-dev] Re: [rules-users] Drools5M3 Issues

Mark Proctor — 2008-11-28T20:38:43

one option is to put drools api under a totaly new namespace - org.drools5 instead of org.drools. But I'm not keen to do this, although I know hibernate did it moving to hibernate 3. I'm trying to get a CR out in a week or so, so what ever we decide, we are rapidly running out of time. Mark Mark Proctor wrote: _______________________________________________ rules-dev mailing list rules-dev< at >lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-dev

Re: [rules-dev] Unable to Check-In

Mark Proctor — 2008-11-28T14:57:36

_______________________________________________ rules-dev mailing list rules-dev< at >lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-dev

[rules-dev] Unable to Check-In

Ashish Redkar — 2008-11-28T13:29:36

_______________________________________________ rules-dev mailing list rules-dev< at >lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-dev

[rules-dev] Knowledge Compositions

Mark Proctor — 2008-11-28T07:10:12

Compioitions now work and the new Resource framework is committed. You can see the api in action here: http://anonsvn.labs.jboss.com/labs/jbossrules/trunk/drools-decisiontables/src/test/java/org/drools/decisiontable/CompositionTest.java Along with the xml knowledge composition file it is loading: http://anonsvn.labs.jboss.com/labs/jbossrules/trunk/drools-decisiontables/src/test/resources/org/drools/decisiontable/composition1Test.xml The summarised version is:

KnowledgeBuilder kbuilder = KnowledgeBuilderFactory.newKnowledgeBuilder(); kbuilder.add( ResourceFactory.newClassPathResource( "composition1Test.xml", getClass()), KnowledgeType.COMPOSITION ); assertFalse( kbuilder.hasErrors() ); KnowledgeBase kbase = KnowledgeBaseFactory.newKnowledgeBase(); XML Compisition files support all knowledge types, including other xml knowledge compositions. So one composition can reference and load other compositions. I'm not just updating the agent to take advantage of this. Mark _______________________________________________ rules-dev mailing list rules-dev< at >lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-dev

Re: [rules-dev] Knowledge Composition and Parts

Mark Proctor — 2008-11-27T13:12:42

_______________________________________________ rules-dev mailing list rules-dev< at >lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-dev

RE: [rules-dev] Knowledge Composition and Parts

Nimesh Muley — 2008-11-27T09:47:18

Hi, What might be possible in 5.1? Ability to plug-in custom Resource implementation or a resource implementation that will look into repository. I hope the former is available in 5.0 :-). I understood the resource configuration part. Would it make sense to have Knowledge Builder configuration on lines of resource being part and Knowledge Builder being whole? Typically for executing any business functionality we have more than one resources involved. This may happen due to splitting of rules based on different sub features but wanting to execute the top level feature (basically easy maintainability). Or it could be pure dynamism needed during execution. With this typical usage in mind I feel that having a Knowledge Builder level configuration may help in maintenance of executable rules. Regards, - Nimesh -----Original Message----- From: rules-dev-bounces< at >lists.jboss.org [mailto:rules-dev-bounces< at >lists.jboss.org] On Behalf Of Mark Proctor Sent: Thursday, November 27, 2008 2:05 PM To: Rules Dev List Subject: Re: [rules-dev] Knowledge Composition and Parts Nimesh Muley wrote: This might be possible, I'll bear it in mind as an enhancements for 5.1. If you look at the javadocs for drools-api ResourceConfiguration is specific to what you are loading, for instance with decision tables (the only place where it is currently used) it provides the binary type, XLS or CSV, and optionally the worksheet name. Mark is e-mail in error, kindly delete this e-mail from desktop and server. _______________________________________________ rules-dev mailing list rules-dev< at >lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-dev MASTEK LTD. Mastek is in NASSCOM's 'India Top 20' Software Service Exporters List. In the US, we're called MAJESCOMASTEK ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Opinions expressed in this e-mail are those of the individual and not that of Mastek Limited, unless specifically indicated to that effect. Mastek Limited does not accept any responsibility or liability for it. This e-mail and attachments (if any) transmitted with it are confidential and/or privileged and solely for the use of the intended person or entity to which it is addressed. Any review, re-transmission, dissemination or other use of or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. This e-mail and its attachments have been scanned for the presence of computer viruses. It is the responsibility of the recipient to run the virus check on e-mails and attachments before opening them. If you have received this e-mail in error, kindly delete this e-mail from desktop and server. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ _______________________________________________ rules-dev mailing list rules-dev< at >lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-dev

Re: [rules-dev] Knowledge Composition and Parts

Mark Proctor — 2008-11-27T08:34:53

This might be possible, I'll bear it in mind as an enhancements for 5.1. If you look at the javadocs for drools-api ResourceConfiguration is specific to what you are loading, for instance with decision tables (the only place where it is currently used) it provides the binary type, XLS or CSV, and optionally the worksheet name. Mark is e-mail in error, kindly delete this e-mail from desktop and server. _______________________________________________ rules-dev mailing list rules-dev< at >lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-dev

RE: [rules-dev] Knowledge Composition and Parts

Nimesh Muley — 2008-11-27T07:23:31

Hi, To load a resource from DB would someone need to provide a custom implementation of Resource (meant for DB lookup) and then use it in the KnowledgeBuilder? Can this definition be later extended to load a resource from a repository once repository concept is there during execution time (similar / same as what is available at definition time)? Should resource configuration at Resource level (part) or at KnowledgeBuilder? As per my understanding of the definition below, it seems more apt at KnowledgeBuilder level. Regards, - Nimesh -----Original Message----- From: rules-dev-bounces< at >lists.jboss.org [mailto:rules-dev-bounces< at >lists.jboss.org] On Behalf Of Mark Proctor Sent: Thursday, November 27, 2008 12:01 PM To: Rules Dev List Subject: [rules-dev] Knowledge Composition and Parts I'm in the process of doing the final changes to drools-api. Having done the spring work, not yet committed, I liked their resource framework, so decided to copy this for Drools. So we now have: KnowledgeBuilder.add( Resource, KnowledgeType, ResourceConfiguration ); Where we support the following Resource sources: FileSystemResource, ClassPathResource, UrlResource ByteArrayResource, ReaderResource, EncodedResource and InputStreamResource In use it'll look like: kbuilder.add( ResourceFactory.newClassPathResource( "somefile.drl", classLoader ), KnowledgeType.DRL ) I do not yet do knowledge type inference from the .ext - I think I'll leave that till after 5.0, if I do it at all. So kbuilder.addResource( URL, ...) and kbuilder.addResource( Reader, ... ) from M3 no longer exist and are as above. What I'm adding now is the ability to provide an xml file that is a configuration of resources to load. The term Configuration is overloaded, and we use this more to provide the directives for knowledgebuilder and knowledgebase. So I was thinking Composition and Part - for Knowledge Composition and Knowledge Part, from dictionary.com on "composition": "the act of combining parts or elements to form a whole." "the composition of "aircraft" from "air" and "craft." My reasoning for this is a composition will contain rules, processes, decision tables, dsls etc. "The KnowlegeBase is a composition of Knowlege Parts". The XML would look like:

I have not added a resource type attribute, as we will assume it must start with protocol. classpath will use ClassPathResource, file will use FileSystemResource and anything will be a UrlResource. This would be a special KnowlegeType. I may later make the type optional, once we can infer the type from the .ext. kbuilder.addResource( ResourceFactory.newFileResource( "/data/my-knowledge.xml" ), KnowledgeType.COMPOSITION ); What do people think? Mark _______________________________________________ rules-dev mailing list rules-dev< at >lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-dev MASTEK LTD. Mastek is in NASSCOM's 'India Top 20' Software Service Exporters List. In the US, we're called MAJESCOMASTEK ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Opinions expressed in this e-mail are those of the individual and not that of Mastek Limited, unless specifically indicated to that effect. Mastek Limited does not accept any responsibility or liability for it. This e-mail and attachments (if any) transmitted with it are confidential and/or privileged and solely for the use of the intended person or entity to which it is addressed. Any review, re-transmission, dissemination or other use of or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. This e-mail and its attachments have been scanned for the presence of computer viruses. It is the responsibility of the recipient to run the virus check on e-mails and attachments before opening them. If you have received this e-mail in error, kindly delete this e-mail from desktop and server. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ _______________________________________________ rules-dev mailing list rules-dev< at >lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-dev

[rules-dev] Knowledge Composition and Parts

Mark Proctor — 2008-11-27T06:30:52

I'm in the process of doing the final changes to drools-api. Having done the spring work, not yet committed, I liked their resource framework, so decided to copy this for Drools. So we now have: KnowledgeBuilder.add( Resource, KnowledgeType, ResourceConfiguration ); Where we support the following Resource sources: FileSystemResource, ClassPathResource, UrlResource ByteArrayResource, ReaderResource, EncodedResource and InputStreamResource In use it'll look like: kbuilder.add( ResourceFactory.newClassPathResource( "somefile.drl", classLoader ), KnowledgeType.DRL ) I do not yet do knowledge type inference from the .ext - I think I'll leave that till after 5.0, if I do it at all. So kbuilder.addResource( URL, ...) and kbuilder.addResource( Reader, ... ) from M3 no longer exist and are as above. What I'm adding now is the ability to provide an xml file that is a configuration of resources to load. The term Configuration is overloaded, and we use this more to provide the directives for knowledgebuilder and knowledgebase. So I was thinking Composition and Part - for Knowledge Composition and Knowledge Part, from dictionary.com on "composition": "the act of combining parts or elements to form a whole." "the composition of “aircraft” from “air” and “craft.” My reasoning for this is a composition will contain rules, processes, decision tables, dsls etc. "The KnowlegeBase is a composition of Knowlege Parts". The XML would look like:

Re: [rules-dev] Spring support for drools-api

Michal Bali — 2008-11-26T01:10:57

_______________________________________________ rules-dev mailing list rules-dev< at >lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-dev

Re: [rules-dev] Spring support for drools-api

Mark Proctor — 2008-11-25T16:02:01

_______________________________________________ rules-dev mailing list rules-dev< at >lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-dev

Re: [rules-dev] Spring support for drools-api

Michal Bali — 2008-11-25T11:51:06

_______________________________________________ rules-dev mailing list rules-dev< at >lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-dev

Re: [rules-dev] Spring support for drools-api

Mark Proctor — 2008-11-25T06:07:09

_______________________________________________ rules-dev mailing list rules-dev< at >lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-dev

[rules-dev] live docs

Mark Proctor — 2008-11-25T04:08:30

Documentation and Javadocs are now published continiously (we'll about 1 hour apar) as they change, as part of the hudson build server. https://hudson.jboss.org/hudson/job/drools/lastSuccessfulBuild/artifact/trunk/target/docs/index.html https://hudson.jboss.org/hudson/job/drools/lastSuccessfulBuild/artifact/trunk/target/javadocs/index.html So now people should be able to review our doc changes as they happen. Mark _______________________________________________ rules-dev mailing list rules-dev< at >lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-dev

Re: [rules-dev] Spring support for drools-api

Mark Proctor — 2008-11-24T05:42:23

_______________________________________________ rules-dev mailing list rules-dev< at >lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-dev

Re: [rules-dev] Spring support for drools-api

Greg Barton — 2008-11-24T05:13:39

Well, if you look at String.getBytes() it uses the default encoding, then ISO-8859-1 if that fails. (Default is UTF-8 unless otherwise specified in the "file.encoding" property.) As long as that's documented I guess it's not a problem, unless someone wants to specify their own charset for a particular file. Java 1.6 has String.getBytes(Charset) and that could allow someone to use an alternate charset. I figure for the vast majority of cases it won't be a problem. --- On Sun, 11/23/08, Mark Proctor codehaus.org> wrote: _______________________________________________ rules-dev mailing list rules-dev< at >lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-dev

Re: [rules-dev] Spring support for drools-api

Mark Proctor — 2008-11-24T03:09:08

I'm thinking of adopting the Spring approach to Resources for drools-api, obviously not tieing drools-api to spring - just copying the concept. Resource however doesn't seem to work with Readers. Readers in general are only needed for in memory generation , using StringReader, otherwise file/url/classpath resources suffice. So it seems to do the Spring way you would do a ByteArrayResource( "this is my drl file".getBytes() ). I'm wondering what people think of that, and what about encoding issues? Compared to the way at the moment that we just take a Reader, and that's it. Mark Mark Proctor wrote: _______________________________________________ rules-dev mailing list rules-dev< at >lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-dev

Re: [rules-dev] Spring support for drools-api

Mark Proctor — 2008-11-24T02:17:29

now my spring skills are improving, I'm looking to improve the xml and leverage spring Resource framework - so that we can get complete scripting of the entire KnowlegeBuilder api. I've come up with the two xmls so far: file:src/main/java/org/drools/ioc/spring/testSpring.drl This one has a property per knowledge type, the advantage is on knowledge types which are just string, we can use a simple . Although knowlege tyep that require additional information, like the DT input type, will need a bean. This approach more closely resembles the kbuilder api. We have simple resources list. Everything is a bean, so it's very flexible, but we lose the shortcut approach of the first one where we can just give a list of strings. As each one must be a bean, so that it can contain atleast the knowledge type, as well as the resource string. My preference currently is for the second one, as I don't tink it's too verbose, and it provides better consistency than the first. Mark Geoffrey De Smet wrote: _______________________________________________ rules-dev mailing list rules-dev< at >lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-dev

Re: [rules-dev] Spring support for drools-api

Geoffrey De Smet — 2008-11-23T20:15:59

It doesn't indeed sound overkill to me to create a FactoryBean for the Builder. Though I would probably reuse the Builder inside the KnowlegdeBaseFactory to build the Knowlegde base. The real issue is concurrency. Spring promotes the idea of stateless beans which do have global variables, but those global variables are either synchronised thread-safe or also follow the stateless bean pattern. This in fact makes the stateless beans thread safe, without any need for synchronization/locking. So the question is: is your KnowlegdeBase thread-safe? Thread safe objects are usually put into global variables, while not thread unsafe objects are always put into local variables. class A { private B b; // thread-safe by synchronization (JDBCConnection, ...) private C c; // thread-safe by the stateless pattern: // both b and c are set during initialization (constr. or setter), before A is exposed to other threads public void metho(D d) { // d is not thread-safe E e = ...; // e is not thread-safe } } In drools 4. B is the RuleBase, while E is the working memory instance. With kind regards, Geoffrey De Smet Mark Proctor schreef: _______________________________________________ rules-dev mailing list rules-dev< at >lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-dev