BRMS - CannotResolveClassException when rebuilding snapshot - Trunk
by Paul Browne
Folks,
When trying to rebuild the Snapshot Binaries (to resolve a different
error) in the BRMS I'm getting the exception below. It's probably
because I'm using the latest from Trunk (Snapshot 4.1.0 , as of Wed).
I'll try again with the latest stable version.
For Info, I'm running Java 1.6.0_3 on JBoss App Server 4.2.1
Paul
An error occurred executing the action.
Details
com.thoughtworks.xstream.mapper.CannotResolveClassException:
org.drools.ruleflow.core.impl.RuleFlowProcessImpl :
org.drools.ruleflow.core.impl.RuleFlowProcessImpl at
com.thoughtworks.xstream.mapper.DefaultMapper.realClass(DefaultMapper.java:49)
at
com.thoughtworks.xstream.mapper.MapperWrapper.realClass(MapperWrapper.java:26)
at
com.thoughtworks.xstream.mapper.ClassAliasingMapper.realClass(ClassAliasingMapper.java:76)
at
com.thoughtworks.xstream.mapper.MapperWrapper.realClass(MapperWrapper.java:26)
at
com.thoughtworks.xstream.mapper.MapperWrapper.realClass(MapperWrapper.java:26)
at
com.thoughtworks.xstream.mapper.MapperWrapper.realClass(MapperWrapper.java:26)
at
com.thoughtworks.xstream.mapper.MapperWrapper.realClass(MapperWrapper.java:26)
at
com.thoughtworks.xstream.mapper.MapperWrapper.realClass(MapperWrapper.java:26)
at
com.thoughtworks.xstream.mapper.CGLIBMapper.realClass(CGLIBMapper.java:40)
at
com.thoughtworks.xstream.mapper.MapperWrapper.realClass(MapperWrapper.java:26)
at
com.thoughtworks.xstream.mapper.DynamicProxyMapper.realClass(DynamicProxyMapper.java:60)
at
com.thoughtworks.xstream.mapper.MapperWrapper.realClass(MapperWrapper.java:26)
at
com.thoughtworks.xstream.mapper.MapperWrapper.realClass(MapperWrapper.java:26)
at
com.thoughtworks.xstream.mapper.MapperWrapper.realClass(MapperWrapper.java:26)
at
com.thoughtworks.xstream.mapper.ArrayMapper.realClass(ArrayMapper.java:76)
at
com.thoughtworks.xstream.mapper.MapperWrapper.realClass(MapperWrapper.java:26)
at
com.thoughtworks.xstream.mapper.MapperWrapper.realClass(MapperWrapper.java:26)
at
com.thoughtworks.xstream.mapper.MapperWrapper.realClass(MapperWrapper.java:26)
at
com.thoughtworks.xstream.mapper.CachingMapper.realClass(CachingMapper.java:34)
at
com.thoughtworks.xstream.core.TreeUnmarshaller.start(TreeUnmarshaller.java:113)
at
com.thoughtworks.xstream.core.ReferenceByIdMarshallingStrategy.unmarshal(ReferenceByIdMarshallingStrategy.java:14)
at com.thoughtworks.xstream.XStream.unmarshal(XStream.java:846) at
com.thoughtworks.xstream.XStream.unmarshal(XStream.java:833) at
com.thoughtworks.xstream.XStream.fromXML(XStream.java:781) at
org.drools.compiler.ProcessBuilder.addProcessFromFile(ProcessBuilder.java:174)
at
org.drools.compiler.PackageBuilder.addRuleFlow(PackageBuilder.java:220)
at
org.drools.brms.server.contenthandler.RuleFlowHandler.compile(RuleFlowHandler.java:51)
at
org.drools.brms.server.builder.ContentPackageAssembler.buildAsset(ContentPackageAssembler.java:139)
at
org.drools.brms.server.builder.ContentPackageAssembler.buildPackage(ContentPackageAssembler.java:127)
at
org.drools.brms.server.builder.ContentPackageAssembler.<init>(ContentPackageAssembler.java:84)
at
org.drools.brms.server.builder.ContentPackageAssembler.<init>(ContentPackageAssembler.java:92)
at
org.drools.brms.server.ServiceImplementation.buildPackage(ServiceImplementation.java:849)
at
org.drools.brms.server.ServiceImplementation.buildPackage(ServiceImplementation.java:839)
at
org.drools.brms.server.ServiceImplementation.rebuildSnapshots(ServiceImplementation.java:1015)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597) at
org.jboss.seam.util.Reflections.invoke(Reflections.java:21) at
org.jboss.seam.intercept.RootInvocationContext.proceed(RootInvocationContext.java:31)
at
org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:56)
at
org.jboss.seam.transaction.RollbackInterceptor.aroundInvoke(RollbackInterceptor.java:31)
at
org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68)
at
org.jboss.seam.core.BijectionInterceptor.aroundInvoke(BijectionInterceptor.java:46)
at
org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68)
at
org.jboss.seam.core.MethodContextInterceptor.aroundInvoke(MethodContextInterceptor.java:42)
at
org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68)
at
org.jboss.seam.security.SecurityInterceptor.aroundInvoke(SecurityInterceptor.java:40)
at
org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68)
at
org.jboss.seam.intercept.RootInterceptor.invoke(RootInterceptor.java:106)
at
org.jboss.seam.intercept.JavaBeanInterceptor.interceptInvocation(JavaBeanInterceptor.java:155)
at
org.jboss.seam.intercept.JavaBeanInterceptor.invoke(JavaBeanInterceptor.java:91)
at
org.drools.brms.server.ServiceImplementation_$$_javassist_3.rebuildSnapshots(ServiceImplementation_$$_javassist_3.java)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597) at
org.jboss.seam.remoting.gwt.GWTToSeamAdapter.callWebRemoteMethod(GWTToSeamAdapter.java:74)
at
org.jboss.seam.remoting.gwt.GWTRemoteServiceServlet.processCall(GWTRemoteServiceServlet.java:290)
at
org.jboss.seam.remoting.gwt.GWTRemoteServiceServlet.doPost(GWTRemoteServiceServlet.java:172)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:710) at
javax.servlet.http.HttpServlet.service(HttpServlet.java:803) at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.jboss.seam.web.ContextFilter$1.process(ContextFilter.java:42) at
org.jboss.seam.servlet.ContextualHttpServletRequest.run(ContextualHttpServletRequest.java:46)
at org.jboss.seam.web.ContextFilter.doFilter(ContextFilter.java:37) at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at
org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:230)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
at
org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:179)
at
org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:84)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:104)
at
org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:157)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:241)
at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:580)
at
org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
at java.lang.Thread.run(Thread.java:619)
17 years, 12 months
BRMS version 4.0.4 problems
by Michael Neale
Something has gone awry, 4.0.4 BRMS seems to have been packaged badly
somehow. So please be patient while we sort it out.
Michael.
17 years, 12 months
Drools 4.0.4 Released
by Fernando Meyer
We just released Drools v4.0.4. This is a minor release with a few
improvements on existing features and some bug fixes.
Release Notes - JBoss Drools - Version 4.0.4
We would like to really thanks all the contributors that helped on getting
this release out. From those contributing patches and docs, to those testing
and reporting bugs and providing feedback. The list is a bit long to post
all names here and I may incur in a mistake forgetting someone, so our open
public thank you to you all!
Follows the release notes.
Happy Drooling
Drools Team
Release Notes - JBoss Drools - Version 4.0.4
Bug
* [JBRULES-1243] - Pattern matching does not allow spaces
* [JBRULES-1274] - NPE when using reserved word "action" as a bound
variable, or omitting rule title
* [JBRULES-1284] - ClassCastException when using "<" constraint on field
of type java.lang.Object containing data of type java.lang.Integer
* [JBRULES-1310] - java.lang.NullPointerException at
org.drools.rule.builder.dialect.java.JavaConsequenceBuilder.build(
JavaConsequenceBuilder.java:54)
* [JBRULES-1311] - NPE when compiling rule consequences
* [JBRULES-1313] - NullPointerException at JavaConsequenceBuilder.java:54
on RHS for simplest of consequences
* [JBRULES-1314] - Error parsing rule that is written in a single line
* [JBRULES-1316] - Serialising Both the RuleBase and WorkingMemory
throws null pointer
* [JBRULES-1317] - Rule Execution Very Slow on Subsequent Session Using
the Same Packages
* [JBRULES-1321] - org.drools.compiler.DroolsParserException: Unknown
error while parsing.
org.drools.compiler.DroolsParserException: Unknown error while
parsing.
* [JBRULES-1325] - OutOfMemory with the use of WorkingMemoryFileLogger
* [JBRULES-1336] - Typo in RuleBaseConfiguration(ClassLoader classLoder,
Properties properties) -- the ClassLoader specified in the constructor args
is not used
* [JBRULES-1337] - 'or' with predicate/return val/inline eval with
property issue
* [JBRULES-1339] - Debugging: Breakpoints are only considered for code
with variables
* [JBRULES-1340] - JBRMS - Admin - Manage Archived Assets - Open item
icon not opening item
* [JBRULES-1348] - Incorrect hash code calculation for character
attributes in alpha hashing optimization
* [JBRULES-1354] - Duplicate parameter error while trying to use pattern
bound variables or globals in accumulate function
* [JBRULES-1364] - Drl parser 'or'
* [JBRULES-1387] - Drools doesn't build with fresh maven2 installation
and no repository
* [JBRULES-1397] - org.mvel.CompileException: variable already defined
within scope
* [JBRULES-1410] - Rules with Collect / Accumulate CEs not working
correctly when dinamically added to a rulebase
* [JBRULES-1412] - ContextEntries should have cache nulled
* [JBRULES-1413] - KnowledgeHelper should have cache reset before use.
* [JBRULES-1416] - The use of HashKey is not thread safe in
CompositeObjectSinkAdapter
Feature Request
* [JBRULES-1308] - getFactHandle with equality-based assert behavior
* [JBRULES-1349] - NotNode and Exists Improvements
* [JBRULES-1375] - remove backported concurrency classes, now that we
are jdk1.5+
* [JBRULES-1395] - Add support to modify() block in java dialect
consequences
Patch
* [JBRULES-1323] - Add caching to the Objenesis instance and move
instance to the RuleBase level
Task
* [JBRULES-1421] - Update mvel version to 1.2.21 and update mvel
templates
--
Fernando Meyer http://fmeyer.org
JBoss Rules Core Developer
fernando(a)fmeyer.org
18 years
Brms no commit reminder
by Michael Neale
Merging gives me headaches so please let me know if you have any brms
changes.
Sent from my iPhone
18 years
[Fwd: Re: drools-spring and drools-guice]
by Mark Proctor
From Ales, a core JBoss Micro Container developer:
-------- Original Message --------
> I believe the JBoss MC people have done some work in this area, I have cc'd to see if they have
> any input or documentation pointers.
This is what we currently have:
- MC + Drools:
http://www.jboss.org/index.html?module=bb&op=viewtopic&t=117607
- MC + Guice: http://www.jboss.com/?module=bb&op=viewtopic&t=119144
MC + Spring: what we do here is very simple, we simply map MC's IoC
support on top of Spring beans schema. Meaning you can drop in Spring
beans XML, and the MC will be able to deploy your beans w/o any Spring
lib in classpath.
I did a fair amount of Spring back in the pre-MC days. And I still
follow what's going on with Guice, as I help with WebBeans.
So, if you have any question let me know.
Cheers,
Ales
18 years
Re: AlphaNodeCompiler
by Mark Proctor
Michael Neale wrote:
> Nice - will this be JIT like the extractors - or will it be part of
> the compiler step?
>
> I think the ASM bit is harder then you think though. If its in
> compiler MVEL templating plus compiling can be used, but obviously not
> if it is JIT in the core (in which case, yes, ASM is needed, but
> fiddly to do and get right - will take a while to flush out all the
> invalid class errors).
Yes the idea is to JIT it - and ASM is never easy :) but the end result
here would be worth while. I'm just showing the algorithm itself isn't
hard, including keeping alpha node hashing.
So the original AlphaNode network exists but we compile each
ObjectType's network into a class and attach that to the ObjectTypeNode
and propagate into that instead. If the ObjectTypeNode or any of it's
alpha nodes become dirty from a rule add/remove we drop the class for
that ObjectType and rebuild it.
>
> On Jan 14, 2008 8:26 AM, Mark Proctor <mproctor(a)codehaus.org
> <mailto:mproctor@codehaus.org>> wrote:
>
> I can now generate an alpha network, currently java as a string.
> We can
> change this to generate a class with ASM bytecode - so thats one
> class
> per one ObjectType. So the main thing is it shows the algorithm
> works,
> including node sharing and hashing via the case statement.
>
> package org.drools.benchmark.manners
>
> rule rule1
> when
> context : Context( state == Context.START_UP )
> guest : Guest( name == "mark", sex != Sex.M, hobby ==
> Hobby.H1)
> count : Count()
> then
> end
>
> rule rule2
> when
> context : Context( state == Context.START_UP )
> guest : Guest( name == "mark", sex != Sex.M , hobby ==
> Hobby.H2)
> count : Count()
> then
> end
>
> rule rule3
> when
> context : Context( state == Context.START_UP )
> guest : Guest( name == "luke", sex != Sex.M, hobby ==
> Hobby.H3)
> count : Count()
> then
> end
>
> rule rule4
> when
> context : Context( state == Context.START_UP )
> guest : Guest( name == "mark", sex != Sex.M, hobby ==
> Hobby.H4 )
> count : Count()
> then
> end
>
> The following is produced for above (obviously doesn't compile, but
> shows the algo works):
> public class Compiled[ClassObjectType
> class=org.drools.benchmark.manners.Count ]AlphaNetwork implements
> RightTupleSink {
> RightTupleSink sink10;
> RightTupleSink sink17;
> RightTupleSink sink26;
> RightTupleSink sink33;
> public void assertObject(....) {
> sink10.assertRight (handle, wm, context);
> sink17.assertRight(handle, wm, context);
> sink26.assertRight(handle, wm, context);
> sink33.assertRight(handle, wm, context);
> }
> }
>
> public class Compiled[ClassObjectType
> class=org.drools.benchmark.manners.Context]AlphaNetwork implements
> RightTupleSink {
> AlphaNodeFieldConstraint alphaNodeConstraint2;
> RightTupleSink sink3;
> public void assertObject(....) {
> if ( alphaNodeConstraint2.isAllowed(handle, wm) ) {
> sink3.assertRight(handle, wm, context);
> }
> }
> }
>
> public class Compiled[ClassObjectType
> class=org.drools.benchmark.manners.Guest]AlphaNetwork implements
> RightTupleSink {
> AlphaNodeFieldConstraint alphaNodeConstraint5;
> AlphaNodeFieldConstraint alphaNodeConstraint6;
> AlphaNodeFieldConstraint alphaNodeConstraint30;
> RightTupleSink sink31;
> AlphaNodeFieldConstraint alphaNodeConstraint7;
> RightTupleSink sink8;
> AlphaNodeFieldConstraint alphaNodeConstraint14;
> RightTupleSink sink15;
> AlphaNodeFieldConstraint alphaNodeConstraint21;
> AlphaNodeFieldConstraint alphaNodeConstraint22;
> AlphaNodeFieldConstraint alphaNodeConstraint23;
> RightTupleSink sink24;
> public void assertObject(....) {
> if ( alphaNodeConstraint5.isAllowed(handle, wm) ) {
> if ( alphaNodeConstraint6.isAllowed (handle, wm) ) {
> HashKey key = new HashKey(handle);
> swtich
> ((RightTupleSink)this.hashedSinkedMap(key)).getId() {
> case 7: {
> sink8.assertRight (handle, wm, context);
> };
> case 14: {
> sink15.assertRight(handle, wm, context);
> };
> case 30: {
> sink31.assertRight(handle, wm, context);
> };
> };
> }
> }
> if ( alphaNodeConstraint21.isAllowed(handle, wm) ) {
> if ( alphaNodeConstraint22.isAllowed (handle, wm) ) {
> if ( alphaNodeConstraint23.isAllowed(handle, wm) ) {
> sink24.assertRight(handle, wm, context);
> }
> }
> }
> }
> }
>
>
>
>
>
>
> --
> Michael D Neale
> home: www.michaelneale.net <http://www.michaelneale.net>
> blog: michaelneale.blogspot.com <http://michaelneale.blogspot.com>
18 years
More efficient retraction without shadow proxies
by Mark Proctor
I've spent the last week or so working on a performance branch. The end
result is slightly better performance and we don't need shadow proxies
any more, apart from those that want protecting in a multi-threaded
environment - so they can be optional and off by default. If we an
combine this with the compiled alpha node network stuff we should be
getting some good performance and userbility gains for our next release
- assuming the cep and concurrency stuff hasn't hampered performance too
much :)
http://anonsvn.labs.jboss.com/labs/jbossrules/branches/righttuple/
In the branch, not everything compiles, but enough compiles to run
manners and waltz. I now need to undertake the hard work of merging with
trunk, not easy as edson has changed a lot for the CEP stuff.
Mark
18 years
AlphaNodeCompiler
by Mark Proctor
Currently each literal constraint is a node, so something like:
Guest( name == "mark", sex != Sex.M, hobby == Hobby.H1)
Has three chained alpha nodes. To evaluate a pattern we have to
propagate to each alpha node in turn.
I can now generate a compiled alpha network per object type
JBRULES-1418, currently java as a string, for prototyping purposes. We
can change the java code to generate a class with ASM bytecode - so
that's one class per one ObjectType. This means each ObjectType has all
it's literal constraints, for all rules, evaluated in a single method;
that method will propagate full matched facts to the alpha network via
sink variable references .So the main thing is it shows the algorithm
works, including node sharing and hashing via the case statement.
currently it just empbeds each alpahconstraint with an isAllowed
constraint, we could probably look at inlining some of that logic too
to have even less indirection.
Anyone want to finish this of for me? :)
i.e. generating ASM, writting unit tests, and wiring it up to the Rete
builder.
package org.drools.benchmark.manners
rule rule1
when
context : Context( state == Context.START_UP )
guest : Guest( name == "mark", sex != Sex.M, hobby == Hobby.H1)
count : Count()
then
end
rule rule2
when
context : Context( state == Context.START_UP )
guest : Guest( name == "mark", sex != Sex.M, hobby == Hobby.H2)
count : Count()
then
end
rule rule3
when
context : Context( state == Context.START_UP )
guest : Guest( name == "luke", sex != Sex.M, hobby == Hobby.H3)
count : Count()
then
end
rule rule4
when
context : Context( state == Context.START_UP )
guest : Guest( name == "mark", sex != Sex.M, hobby == Hobby.H4)
count : Count()
then
end
The following is produced for above (obviously doesn't compile, but
shows the algo works):
public class Compiled[ClassObjectType
class=org.drools.benchmark.manners.Count]AlphaNetwork implements
RightTupleSink {
RightTupleSink sink10;
RightTupleSink sink17;
RightTupleSink sink26;
RightTupleSink sink33;
public void assertObject(....) {
sink10.assertRight(handle, wm, context);
sink17.assertRight(handle, wm, context);
sink26.assertRight(handle, wm, context);
sink33.assertRight(handle, wm, context);
}
}
public class Compiled[ClassObjectType
class=org.drools.benchmark.manners.Context]AlphaNetwork implements
RightTupleSink {
AlphaNodeFieldConstraint alphaNodeConstraint2;
RightTupleSink sink3;
public void assertObject(....) {
if ( alphaNodeConstraint2.isAllowed(handle, wm) ) {
sink3.assertRight(handle, wm, context);
}
}
}
public class Compiled[ClassObjectType
class=org.drools.benchmark.manners.Guest]AlphaNetwork implements
RightTupleSink {
AlphaNodeFieldConstraint alphaNodeConstraint5;
AlphaNodeFieldConstraint alphaNodeConstraint6;
AlphaNodeFieldConstraint alphaNodeConstraint30;
RightTupleSink sink31;
AlphaNodeFieldConstraint alphaNodeConstraint7;
RightTupleSink sink8;
AlphaNodeFieldConstraint alphaNodeConstraint14;
RightTupleSink sink15;
AlphaNodeFieldConstraint alphaNodeConstraint21;
AlphaNodeFieldConstraint alphaNodeConstraint22;
AlphaNodeFieldConstraint alphaNodeConstraint23;
RightTupleSink sink24;
public void assertObject(....) {
if ( alphaNodeConstraint5.isAllowed(handle, wm) ) {
if ( alphaNodeConstraint6.isAllowed(handle, wm) ) {
HashKey key = new HashKey(handle);
swtich ((RightTupleSink)this.hashedSinkedMap(key)).getId() {
case 7: {
sink8.assertRight(handle, wm, context);
};
case 14: {
sink15.assertRight(handle, wm, context);
};
case 30: {
sink31.assertRight(handle, wm, context);
};
};
}
}
if ( alphaNodeConstraint21.isAllowed(handle, wm) ) {
if ( alphaNodeConstraint22.isAllowed(handle, wm) ) {
if ( alphaNodeConstraint23.isAllowed(handle, wm) ) {
sink24.assertRight(handle, wm, context);
}
}
}
}
}
18 years
Justifying favorite colors
by Geoffrey De Smet
Conan and I had a discussion whether the current behavior of drools has
a bug or a feature. What do you think?
Let's say I have a Person STATED fact:
- Person: name=John, favoriteColor=RED
- Person: name=Elvis, favoriteColor=GREEN
- Person: name=Tom, favoriteColor=GREEN
Person has an equals/hashcode based on the name only.
I also have a logically asserted ExistingFavoriteColor
which just takes a color and has a equals/hashcode based on the color.
So now we have a rule which logically asserts all existing favorite colors:
rule "favoriteColor"
when
Person($color : favoriteColor)
then
insertLogical(new ExistingFavoriteColor($color));
end
So if we fire all rules the first time, there will be 2 existing
favorite colors: RED and GREEN.
Next, John changes his mind, and has a new favoriteColor YELLOW.
When all rules are fired, what exisiting favorite colors would you expect?
a) YELLOW and GREEN because no one likes RED anymore
b) RED, YELLOW and GREEN because John used to like RED
--
With kind regards,
Geoffrey De Smet
18 years
BRMS - please hold off changes for a while
by Michael Neale
I have to do some open heart surgery on it, merging will be a nightmare. But
once she is back, it will be a totally new body.
Please ping me if this is an issue for anyone.
18 years
