Brian,
Sure, that's a valid use case. If answer isn't called in the drools
file, the Exchange is never answered, so if you want to add an attribute
to that endpoint for configuring automatic replies, that's totally
cool! It was just a warning that some people are using the Drools
component as a router and don't want the exchange to be answered before
the exchange forwarded from drools is done.
Regards,
Gert
ObjectOrange wrote:
Gert,
We're not using Drools as a router, only evaluating XML attributes against
some rules and then making changes to XML attributes depending on the
results of those rules; we would like to not have to call answer() in the
drools file as the people editing these through a GUI will not know what
that means (business users). Presently, if answer() is not called in a
drools file, will it get called and by what object?
Regards,
Brian
Gert Vanthienen wrote:
Brian,
The first one seems a nice addition to our Drools component, so by all
means go ahead and supply a patch for it!
Not sure what you want to do with the last one though. The answer
method should already answer the exchange, setting the 'out' message.
As for automatically responding with the request message, how will you
know when to respond? The drools endpoint can send another exchange and
that answer can trigger a real response later. Or would you propose to
make this behavior optional (and configurable through a property)?
Regards,
Gert
ObjectOrange wrote:
Thanks Gert,
In the Message class:
The ability to update the value of an XML attribute (identified by an
XPath)
with a string value or another XML attribute's value (identified by an
XPath) within a Message's body.
In DroolsEndpoint.drools(MessageExchange):
Ensure that if the Exchange was not handled and it's an InOut that the
"out"
message gets returned (using DroolsExecutionContext.answer() - a new
wrapper
method to the JBIHelper.answer()) or if the "out" message does not exist
or
is empty, the "in" message.
What do you think?
Brian
Gert Vanthienen wrote:
Brian,
The best way to start contributing is by creating a JIRA issue to
propose your change and then attach a patch file to it. You can find
more information about this on
http://servicemix.apache.org/contributing.html.
What is it you would like to change on the servicemix-drools component?
Regards,
Gert
ObjectOrange schreef:
Gert,
If I make changes to the source, how can I get these into the build? Do
I
need to become a committer or can I request the changes to be approved
by
committers?
Brian
Gert Vanthienen wrote:
Brian,
The version of the component that uses the DroolsExecutionContext is
the
most recent one. The addition of the DroolsExecutionContext is
nothing
but a simple refactoring, but this version of the component also uses
Drools 4.0.x. It is part of ServiceMix 3.3 and will go into
ServiceMix
4.
This refactoring has not been backported to the ServiceMix 3.2 branch
and
neither has the upgrade to Drools 4.0.x, so ServiceMix 3.2.x still
uses
Drools 3.x.
Regards,
Gert
ObjectOrange wrote:
I've discovered two differing copies of source for the Drools SE
component, one using the DroolsExecutionContext and one not. Which is
the
most recent?
Thx!
Brian
-----
---
Gert Vanthienen
http://gertvanthienen.blogspot.com
-----
---
Gert Vanthienen
http://gertvanthienen.blogspot.com
