3:17 a.m.
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/j...
>
>
http://anonsvn.labs.jboss.com/labs/jbossrules/trunk/drools-api/src/main/j...
>
>
>
http://anonsvn.labs.jboss.com/labs/jbossrules/trunk/drools-api/src/main/j...
>
>
http://anonsvn.labs.jboss.com/labs/jbossrules/trunk/drools-api/src/main/j...
>
>
> 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 list
>> rules-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/rules-dev
>>
>>
>
>
> _______________________________________________
> rules-dev mailing list
> rules-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
>
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev