[rules-dev] Spring support for drools-api
Greg Barton
greg_barton at yahoo.com
Mon Nov 24 00:13:39 EST 2008
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> wrote:
> From: Mark Proctor <mproctor at codehaus.org>
> Subject: Re: [rules-dev] Spring support for drools-api
> To: "Rules Dev List" <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 list
> >>>> rules-dev at lists.jboss.org
> >>>>
> https://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
> >>>
> >>
> >> _______________________________________________
> >> rules-dev mailing list
> >> rules-dev at lists.jboss.org
> >> https://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
> >
> >
>
>
> _______________________________________________
> rules-dev mailing list
> rules-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
More information about the rules-dev
mailing list