[rules-dev] Spring support for drools-api
Michal Bali
michalbali at gmail.com
Tue Nov 25 06:51:06 EST 2008
Hi,
I think the xml looks good.
Spring's PropertyEditors -
http://static.springframework.org/spring/docs/2.5.x/reference/validation.html#beans-beans-conversion
could
be used to even further simplify it. Using convention over configuration to
guess the resource type from file's extension. The configuration will then
become:
<bean id="rb1"
class="org.drools.ioc.spring.KnowledgeBaseFactoryBean">
<property name="resources">
<list>
<value>
file:src/main/java/org/drools/ioc/spring/testSpring.drl</value>
<value>
file:src/main/java/org/drools/ioc/spring/IntegrationExampleTest.xls</value>
</list>
</property>
</bean>
I am not that familiar with PropertyEditors to know if this is possible to
do or not. I am just throwing it out here, maybe somebody else will know
better. It is not that important just nice to have..
Best Regards,
Michal
On Tue, Nov 25, 2008 at 6:07 AM, Mark Proctor <mproctor at codehaus.org> wrote:
> This is now what the spring XML looks like:
> <bean id="rb1"
> class="org.drools.ioc.spring.KnowledgeBaseFactoryBean">
> <property name="resources">
> <list>
> <bean
> class="org.drools.ioc.spring.KnowledgeResourceFactoryBean">
> <property name="knowledgeType" value="DRL" />
> <property name="source" value=
> "file:src/main/java/org/drools/ioc/spring/testSpring.drl"/>
> </bean>
>
> <bean
> class="org.drools.ioc.spring.KnowledgeResourceFactoryBean">
> <property name="knowledgeType" value="DTABLE" />
> <property name="source" value=
> "file:src/main/java/org/drools/ioc/spring/IntegrationExampleTest.xls"/>
> <property name="knowledgeResourceConfiguration">
> <bean
> class="org.drools.ioc.spring.DTableResourceConfigurationFactoryBean">
> <property name="inputType" value="XLS" />
> </bean>
> </property>
> </bean>
> </list>
> </property>
> </bean>
>
> How is that looking? Most people happy with that, it's very generic. I've
> dropped the agent side for the moment, just focusing on scripting of a
> KnowledgeBase via spring. It now more closely follows the KnowedgeBuilder
> api. The above spring configuration will return a rulebase of two
> resources, on is a simple DRL, the other is a decisiontable of type XLS.
>
> I'll extend this further to make sure that ALL knowledge types can be built
> for a knowledge base via the spring api. I'll also make sure it can take a
> KnowledgeBaseConfiguration and KnowledgeBuilderConfiguration. Then I'll also
> make sure there is a spring configuration to return a stateful or stateless
> session given a knowlebasefactorybean ref. Finally I might add some basic
> agent facilities.
>
> I think this should give spring users everything they need, i.e. the
> capability to build knowledge bases and wire sessions and knowledge bases to
> other beans - all via xml.
>
> Mark
>
> Mark Proctor wrote:
>
> I'm updating drools-api as we speak, based on the spring Resource idea. the
> following Factory will provide a set of ready to go Resources, that should
> satisfy most people's needs. So drools-api will be spimplied to
> kbuilder.addResource( Resource, KnowledgeType )
> kbuilder.addResource( Resource, KnowledgeType, ResourceConfiguration )
>
> And the Resources available, and ofcourse people can implement the
> interface themselves is:
>
> public class ResourceFactory {
>
> public static Resource newURLResource(URL url) {
> return null;
> }
>
> public static Resource newURLResource(URI uri) {
> return null;
> }
>
> public static Resource newURLResource(String url) {
> return null;
> }
>
> public static Resource newFileResource(File file) {
> return null;
> }
>
> public static Resource newFileResource(String file) {
> return null;
> }
>
>
> public static Resource newByteArrayResource(byte[] bytes) {
> return null;
> }
>
> public static Resource newInputStreamResource(InputStream stream) {
> return null;
> }
>
> public static Resource newReaderResource(Reader reader) {
> return null;
> }
>
> public static Resource newReaderResource(Reader reader, String encoding) {
> return null;
> }
>
> public static Resource newClassPathResource(String path) {
> return null;
> }
>
> public static Resource newClassPathResource(String path, ClassLoader classLoader) {
> return null;
> }
>
> }
>
> It can take a Reader, which underneath will open an InputStream, it'll use default encoding unless the encoding is
> specified as otherwise in the alternative param.
>
> So typically it'll be
> kbuilder.addResource( ResourceFactory.newClassPathResource( "some path" ), KnowledgeType.DRL );
>
> don't forget you can import static methods, so it can actually be:
> kbuilder.addResource( newClassPathResource( "some path" ), KnowledgeType.DRL );
>
>
> Mark
>
>
>
>
>
> Greg Barton wrote:
>
> 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 <mproctor at codehaus.org> <mproctor at codehaus.org> wrote:
>
>
>
> From: Mark Proctor <mproctor at codehaus.org> <mproctor at codehaus.org>
> Subject: Re: [rules-dev] Spring support for drools-api
> To: "Rules Dev List" <rules-dev at lists.jboss.org> <rules-dev at lists.jboss.org>
> Date: Sunday, November 23, 2008, 9:09 PM
> 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:
>
>
> 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:
> <property name="drls">
> <list>
>
>
>
>
> <value>file:src/main/java/org/drools/ioc/spring/testSpring.drl</value>
>
>
> </list> </property>
> <property name="dtables">
> <list>
> <bean
>
>
>
> class="org.drools.ioc.spring.DtableResourceFactoryBean">
>
>
> <property
>
>
> name="resource"
>
>
> value="file:src/main/java/org/drools/ioc/spring/dt.xls"
> />
>
>
> <property
>
>
> name="inputType" value="XLS" />
>
>
>
> </bean>
>
>
>
> </list> </property>
> This one has a property per knowledge type, the
>
>
> advantage is on
>
>
> knowledge types which are just string, we can use a
>
>
> simple <value>.
>
>
> Although knowlege tyep that require additional
>
>
> information, like the
>
>
> DT input type, will need a bean.
>
> <property name="resources">
> <list>
> <bean
>
>
>
> class="org.drools.ioc.spring.KnowledgeResourceBeanFactory">
>
>
> <property
>
>
> name="knowledgeType" value="DRL" />
>
>
> <property
>
>
> name="resource"
>
>
> value="file:src/main/java/org/drools/ioc/spring/testSpring.drl"
>
> /> </bean>
>
> <bean
>
>
>
> class="org.drools.ioc.spring.KnowledgeResourceBeanFactory">
>
>
> <property
>
>
> name="knowledgeType" value="DTABLE"
> />
>
>
> <property
>
>
> name="resource"
>
>
> value="file:src/main/java/org/drools/ioc/spring/dt.xls"
> />
>
>
> <property
>
>
> name="resourceConfiguration">
>
>
> <bean
>
>
>
> class="org.drools.ioc.spring.DtableResourceFactoryBean">
>
>
> <property
>
>
> name="inputType" value="XLS" />
>
>
> </bean>
>
>
> </property>
>
>
> </bean>
>
>
> </list>
>
>
> </property>
> 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:
>
>
> 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:
>
>
> Geoffrey De Smet wrote:
>
>
> With kind regards,
> Geoffrey De Smet
>
>
> Mark Proctor schreef:
>
>
>
> I'd also maybe consider
>
>
> dropping the Spring prefix, as it's in a
>
>
> package called spring?
> =>
>
>
> org.drools.spring.KnowledgeAgentFactoryBean
>
>
> My worry here is it might be a
>
>
> duplicate of the same name used in
>
>
> the future - although it'll be in
>
>
> a different package namespace,
>
>
> it's still not good practice.
>
>
> Anyone else have any opinions on this?
>
>
> Good point, prefixing it with Spring
>
>
> can't hurt :)
>
>
> I'm just wondering about
>
>
> KnowledgeBuilderFactory and
>
>
> KnowledgeBaseFactory. While it makes sense to
>
>
> put the
>
>
> KnowledgeAgentFactory into spring, does it
>
>
> make sense for those
>
>
> other factories? What are they gonna do other
>
>
> than return
>
>
> KnowledgeBuilder or a KnowledgeBase, only
>
>
> possible advantage is that
>
>
> it would allow spring to inject the
>
>
> KnowledgeBuilderConfiguration
>
>
> and KnowledgeBaseConfiguration. And ideas?
>
>
>
> http://anonsvn.labs.jboss.com/labs/jbossrules/trunk/drools-api/src/main/java/org/drools/builder/KnowledgeBuilderFactory.java
>
> http://anonsvn.labs.jboss.com/labs/jbossrules/trunk/drools-api/src/main/java/org/drools/builder/KnowledgeBuilder.java
>
> http://anonsvn.labs.jboss.com/labs/jbossrules/trunk/drools-api/src/main/java/org/drools/KnowledgeBaseFactory.java
>
> http://anonsvn.labs.jboss.com/labs/jbossrules/trunk/drools-api/src/main/java/org/drools/KnowledgeBase.java
>
> This is typically how those two factories are
>
>
> used:
>
>
> KnowledgeBuilder kbuilder =
> KnowledgeBuilderFactory.newKnowledgeBuilder();
> kbuilder.addResource( new URL(
>
>
> "file://myrules.drl" ),
>
>
>
> KnowledgeType.DRL);
>
>
> KnowledgeBase kbase =
>
>
> KnowledgeBaseFactory.newKnowledgeBase();
>
>
> If we use spring to automate the adding of
>
>
> resources, that's pretty
>
>
> much what the agent is doing anyway, so
>
>
> wouldn't that be pointless?
>
>
> Mark
>
>
>
>
> _______________________________________________
>
>
> rules-dev mailing listrules-dev at lists.jboss.org
>
> https://lists.jboss.org/mailman/listinfo/rules-dev
>
> _______________________________________________
>
>
> rules-dev mailing listrules-dev at lists.jboss.org
>
> https://lists.jboss.org/mailman/listinfo/rules-dev
>
> _______________________________________________
> rules-dev mailing listrules-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/rules-dev
>
>
> _______________________________________________
> rules-dev mailing listrules-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/rules-dev
>
>
> _______________________________________________
> rules-dev mailing listrules-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/rules-dev
>
>
> _______________________________________________
> rules-dev mailing listrules-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/rules-dev
>
>
>
> ------------------------------
> _______________________________________________
> rules-dev mailing listrules-dev at lists.jboss.orghttps://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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-dev/attachments/20081125/db794bd4/attachment.html
More information about the rules-dev
mailing list