[rules-dev] externalize solver configuration - which technology?

[Geoffrey De Smet]

Michael told me on irc that XStream might also be a good idea.

Since I 'd like the configuration as a separate domain object model,
I tryed it that way and it looks ok:


<LocalSearchSolver>
   <randomSeed>5</randomSeed>
   <finish class="StepCountFinish">
     <maximumStepCount>50</maximumStepCount>
   </finish>
</LocalSearchSolver>

What do you think of such kind of local search solver configuration?



Here are the classes that do it, they follow the builder pattern:

@XStreamAlias("LocalSearchSolver")
public class LocalSearchSolverConfig {

     private long randomSeed = 0;

     @XStreamAlias("finish")
     private FinishConfig finishConfig;

     public LocalSearchSolver build() ...

}

@XStreamAlias("StepCountFinish")
public class StepCountFinishConfig implements FinishConfig {

     private int maximumStepCount = 100;

     public Finish build() ...

}


which looks a lot easier than fiddling around with sax or DOM?
Xsd might be a problem - but maybe some day XStream can use the javadocs 
to generate an xsd? If not, it shouldn't be to hard to replace the 
config package with a sax or dom based configuration - or just manually 
write an xsd.

With kind regards,
Geoffrey De Smet


Mark Proctor wrote:
> Look at our xml reader.Its xerces based and pluggeable and should easily 
> be able to adapt to anything.
> 
> Mark
> Geoffrey De Smet wrote:
>> For the solver I 'd like to externalize the configuration into an 
>> xml(?)  file.
>> something like
>>
>> <localsearch decisionMode="OPTIMAL">
>>    <finish steps="500"/>
>>    <ruleBase location="/org/foo/bar/drools.drl"/>
>> </localsearch>
>>
>> This is a bit inspired by how ehcache is configured, clean and easy,
>> without any class implementation details: the way users like it.
>>
>>
>> I 've been thinking on doing this with XStream, but that's not 
>> versatile enough to make user friendly configuration files. Although 
>> Xstream works out great to serialize solutions to and from xml files.
>>
>> Next I was thinking about is JDom or Xom, but that's yet another 
>> dependency. What would you guys recommend?
>>
>>
> 
> _______________________________________________
> rules-dev mailing list
> rules-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
>