Drools and Java 1.8
by Wolfgang Laun
The error message from 6.1.0.CR1 is clear: "Unable to resolve class
'dynop.Main$$Lambda$1/20003005" in ClassFieldAccessorCache.
Is the support for Java lambdas on the Drools roadmap?
Regards
Wolfgng
9 years, 8 months
Re: [rules-dev] [jbpm-dev] services registered by OSGi bundle activators of Kie, Drools and Jbpm are still needed ?
by Cristiano Gavião
Kris and Mark,
I passed this morning analyzing the activators... I'm attaching a sheet
where I added all Activators being used by Kie, JBPM and Drools. Note
that where I marked with red I saw "signs of smell things" and added a
comment...
below I write the reasons I think that we should to remove completely
those activators...
On 18-08-2014 07:28, Kris Verlaenen wrote:
> Cristiano,
>
> Cristiano Gavião schreef op 15/08/2014 17:02:
>> Hi,
>>
>> has a long time that I don't play with Drools and JBPM source code. This
>> week I was walking through them again and saw a lot of new elements,
>> interfaces and new ways to setup things.
>>
>> I saw that some Blueprint specific annotations and classes were created
>> (kie-aries-blueprint).
>> But the existent osgi activators are still registering some services
>> that seems not be appropriated anymore. at least they are different from
>> the set of elements in blueprint namespace (environment, kmodule, kbase
>> and others ) that I saw.
>>
>> For example, in activator of drools-core we have a
>> KnowledgeBaseFactoryServiceImpl being registered. in drools-compiler we
>> have KnowledgeBuilderFactoryServiceImpl being registered.
>>
>> I can't use blueprint, so I need to figure out what is the best setup
>> workflow for OSGi and get the proper services registered.
>>
>> Question, is the kie-aries-blueprint.xsd reflecting the actual state of
>> kie, drools and jbpm core setup workflow, so I can use it as start
>> point?
>>
>> could someone check that and give me a feedback ?
> It is true that using factories isn't always trivial in OSGi,
well, in reality static factory is not recommended at all in osgi. just
because normally it is implemented adding a strong "dependency" between
API and one Implementation. and that is against modularity that OSGi
preaches. In those scenarios in order to change an implementation almost
all the times you will need to change the api also.
I saw the addition of ServiceRegistryImpl to concentrate the services
without a DI. that would reduced a bit this problem (btw, I saw some
factories where it isn't being used yet: org.kie.api.KieServices) but
not all... to me the best solution for non-osgi to separate API from
Implementor still is JavaSE Service Locator.
> so the activators you are referring to are used (internally) to do
> additional registration for OSGi. They should be working and are
> required when using OSGi.
Maybe those activators used to be required and useful (internally) some
day. But currently, I don't think they are needed anymore.
The reasons I think they should be removed:
First, there many services being registered using interfaces from
non-API packages;
Second, the focus of RedHat seems to be Fusion/ Karaf and they already
use blueprint natively.
Third, there are a project exclusive for blueprint based setup, so
doesn't make any sense to me to use ServiceTracker and register things
"by hand in activator" and then complement that using blueprint. Why not
just use blueprint ??
Fourth, we can't use one of the most useful features of OSGi, the
Configuration Admin service. So, we can't (re)configure the registered
services at runtime using simple service properties...
Fifth, those activators don't scale ! if I have an environment
(multi-tenant) where I need to have more than one version running same
time.
So, would help much more if those activators were removed, and improve
the blueprint project to register all that is needed for it. after that
we could create other projects for people wanting to use OSGi
Declarative Services and maybe a OSGi CDI just like the Blueprint one....
And I bet we could figure out a much more clever way to synchronize the
"internal registry" with the OSGi service registry instead have to call
ServiceRegistryImpl.getInstance().registerLocator inside the activator
(Drools-Compiler). One possibility is to create an OSGi implementation
for ServiceRegistry interface instead use ServiceRegistryImpl in all places.
>
> On top of this, some additional "sugar" was created that allows you to
> more easily define various elements (kbase, env, etc.) so they can be
> injected more easily. You are free to use these, but this is not
> required, you could initialize these elements yourself using pure Java
> as well for example. Afaik, kie-aries-blueprint.xsd should be
> up-to-date.
>
> There are some osgi examples available here:
> https://github.com/droolsjbpm/droolsjbpm-integration/blob/master/drools-o...
>
>
> Kris
On 18-08-2014 07:28, Kris Verlaenen wrote:
> Cristiano,
>
> Cristiano Gavião schreef op 15/08/2014 17:02:
>> Hi,
>>
>> has a long time that I don't play with Drools and JBPM source code. This
>> week I was walking through them again and saw a lot of new elements,
>> interfaces and new ways to setup things.
>>
>> I saw that some Blueprint specific annotations and classes were created
>> (kie-aries-blueprint).
>> But the existent osgi activators are still registering some services
>> that seems not be appropriated anymore. at least they are different from
>> the set of elements in blueprint namespace (environment, kmodule, kbase
>> and others ) that I saw.
>>
>> For example, in activator of drools-core we have a
>> KnowledgeBaseFactoryServiceImpl being registered. in drools-compiler we
>> have KnowledgeBuilderFactoryServiceImpl being registered.
>>
>> I can't use blueprint, so I need to figure out what is the best setup
>> workflow for OSGi and get the proper services registered.
>>
>> Question, is the kie-aries-blueprint.xsd reflecting the actual state of
>> kie, drools and jbpm core setup workflow, so I can use it as start
>> point?
>>
>> could someone check that and give me a feedback ?
> It is true that using factories isn't always trivial in OSGi, so the
> activators you are referring to are used (internally) to do additional
> registration for OSGi. They should be working and are required when
> using OSGi.
>
> On top of this, some additional "sugar" was created that allows you to
> more easily define various elements (kbase, env, etc.) so they can be
> injected more easily. You are free to use these, but this is not
> required, you could initialize these elements yourself using pure Java
> as well for example. Afaik, kie-aries-blueprint.xsd should be
> up-to-date.
>
> There are some osgi examples available here:
> https://github.com/droolsjbpm/droolsjbpm-integration/blob/master/drools-o...
>
>
> Kris
9 years, 8 months
services registered by OSGi bundle activators of Kie, Drools and Jbpm are still needed ?
by Cristiano Gavião
Hi,
has a long time that I don't play with Drools and JBPM source code. This
week I was walking through them again and saw a lot of new elements,
interfaces and new ways to setup things.
I saw that some Blueprint specific annotations and classes were created
(kie-aries-blueprint).
But the existent osgi activators are still registering some services
that seems not be appropriated anymore. at least they are different from
the set of elements in blueprint namespace (environment, kmodule, kbase
and others ) that I saw.
For example, in activator of drools-core we have a
KnowledgeBaseFactoryServiceImpl being registered. in drools-compiler we
have KnowledgeBuilderFactoryServiceImpl being registered.
I can't use blueprint, so I need to figure out what is the best setup
workflow for OSGi and get the proper services registered.
Question, is the kie-aries-blueprint.xsd reflecting the actual state of
kie, drools and jbpm core setup workflow, so I can use it as start point?
could someone check that and give me a feedback ?
many thanks,
Cristiano
9 years, 8 months
Problem to build with CR2 due missing dashboard-builder-bom:pom:6.1.0.CR2
by Cristiano Gavião
Hi,
I'm trying to build with the CR2 release and I'm getting this error in
jenkins:
[ERROR] Internal error: java.lang.RuntimeException: Could not resolve project dependencies: Unable to get dependency information for org.kie:kie-api:jar:6.1.0.CR2: Failed to process POM for org.kie:kie-api:jar:6.1.0.CR2: Non-resolvable import POM: Could not find artifact org.jboss.dashboard-builder:dashboard-builder-bom:pom:6.1.0.CR2 in lunifera-thirdparty-plugins (http://maven.lunifera.org:8086/nexus/content/repositories/thirdparty/)
[ERROR] org.kie:kie-api:jar:6.1.0.CR2
I checked and
org.jboss.dashboard-builder:dashboard-builder-bom:pom:6.1.0.CR2 is not
in maven central repository.
is there any other repository that contain this?
thanks,
Cristiano
9 years, 8 months
google groups
by Mark Proctor
We are in the final stages for the discussions on lists and forums. We are likely to move all lists to google groups, as it provides a unified email list and web forum. There will be three resulting groups, instead of the current two.
Drools Setup - installation, configuration, setup and administration
Drools Usage - authoring (drl, decision tables, score cards rule templates, scenarios) and running.
Drools Development - documentation and coding of the drools project
Theses current two lists will remain and the email address will continue to work for a while. We will attempt to auto-subscribe (i.e. transfer) all existing subscribers. rules-dev people will be subscribed to drools-development. rules-users will be subscribed to both drools-setup and drools-usage - as the current list currently covers both those topics.
If anyone has any feedback, please let us know.
Mark
9 years, 8 months
Decision Tables + Templates: Consistency please!
by Michael Anstis
Hi,
I opened myself a good can of worms yesterday.
The long and short of it is the following behave differently (with regard
to the DRL generated):-
- XLS Decision Tables
- Templates
- KIE-WB Guided Decision Tables
- KIE-WB Guided Decision Table Template fragments
There is a further complication:
https://bugzilla.redhat.com/show_bug.cgi?id=996964
All of the listed rule types currently discount a constraint if it#s value
is empty, or value.trim() is empty. The requirement really only affects
String field types. The difficulty is how to differentiate between a
null-value (empty cell) and empty-string that works consistently with XLS
and the KIE-WB editors.
So, my question is what behaviour should we standardize on?
I propose the following:
- For a Pattern, with no constraints we exclude the pattern (this is
current XLS behaviour).
e.g. Person( name == $name, age == $age ). If we don't provide values for
$name and $age we don't include the Person pattern. If a user wants to
include the Pattern they'd need to add a constraint "this != null".
If we include the pattern when there are no constraints then it is more
difficult to provide a work-around to exclude the pattern if this is what
some users need (and since it's the existing behaviour; less likely to be
an issue for the majority of XLS users).
- Support escaping String literals with quotes; so a user would enter ""
or " ". This make it obvious that the cell contains a non-null value. The
surrounding quotation marks would be stripped before being used in the DRL.
WDYT? Should I put this out to the community for opinions too?
With kind regards,
Mike
9 years, 8 months
