11:44 a.m.
Hello to all,
i would like to address some problems with 3.1.0M1:
I've noticed that:
- using eclipse 3.2.2, and JPDL Plugin 3.1.0 alpha3 a program using rules does
not stop at breakpoints in rules (RHS) - ok, its alpha, maybe i'm missing
something
- throws an internal NPE at parsing rules havin NO_LOOP set (even if parse
result caching is on)
- comparisons like "bpairl : BagsPerAirline(nrOfBusinessBags >= (500 +
333))"
throw NPE if field is null - maybe adressed by
http://jira.jboss.com/jira/browse/JBRULES-627
- when
BagsPerAirline(nrOfBusinessBags >= (500 + 333)) //gives all >= 833 BUT
BagsPerAirline(nrOfBusinessBags >= 500 + 333) //all >= 500!!!!!
- when
c : Flight(flightId == 1 | == (1+1))
// throws java.lang.UnsupportedOperationException:
// does not support method call
// isAllowed(Object object, InternalWorkingMemory workingMemoiry)
// at
// org.drools.rule.ReturnValueRestriction.
// isAllowed(ReturnValueRestriction.java:137)
Thanx a lot for the "from" extension :-)
5:21 p.m.
Hey Wolfgang,
They all look problems to me. May I ask you please to open JIRAs for
them?
I will take care of them asap.
Thank you,
Edson
2007/3/27, Wolfgang Betz <Wolfgang.Betz(a)siemens.com>:
Hello to all,
i would like to address some problems with 3.1.0M1:
I've noticed that:
- using eclipse 3.2.2, and JPDL Plugin 3.1.0 alpha3 a program using rules
does
not stop at breakpoints in rules (RHS) - ok, its alpha, maybe i'm missing
something
- throws an internal NPE at parsing rules havin NO_LOOP set (even if parse
result caching is on)
- comparisons like "bpairl : BagsPerAirline(nrOfBusinessBags >= (500 +
333))"
throw NPE if field is null - maybe adressed by
http://jira.jboss.com/jira/browse/JBRULES-627
- when
BagsPerAirline(nrOfBusinessBags >= (500 + 333)) //gives all >= 833 BUT
BagsPerAirline(nrOfBusinessBags >= 500 + 333) //all >= 500!!!!!
- when
c : Flight(flightId == 1 | == (1+1))
// throws java.lang.UnsupportedOperationException:
// does not support method call
// isAllowed(Object object, InternalWorkingMemory workingMemoiry)
// at
// org.drools.rule.ReturnValueRestriction.
// isAllowed(ReturnValueRestriction.java:137)
Thanx a lot for the "from" extension :-)
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
--
Edson Tirelli
Software Engineer - JBoss Rules Core Developer
Office: +55 11 3124-6000
Mobile: +55 11 9218-4151
JBoss, a division of Red Hat @ www.jboss.com
6:31 a.m.
Hi,
firstly, I compiled my code from 3.0 to 3.1 had issues, then from 3.1 to 4, I
cant access my working memory from my rule base and in 4 you've also got rid of
Synchronized working memory.
Questions :
===========
Related to shift from 3.1 to 4
-------------------------------
Q1. Once I create a 'StatelessSession'; how do I extract the Workingmemory?
There is no acessor. My code was written for 'SynchronizedWorkingMemory' so
means double trouble if there is no backward compatibility.
Q2. Couldn't you guys have deprecated stuff instead of just wiping it off? Is
there a reason for such a change as to restrict access to WorkingMemory or
SynchronizedWorkingmemory to those who would have got comfortable using it
directly? :o)
Related to shift from 3.0 to 3.1
---------------------------------
3. When I built my code on 3.1M1 the first thing I got was a
NullPointerException, I debugged the code and found due to additon of
ShadowFacts, if the class definition is NOT FINAL, it dynamically creates a
Shadow object. Refer: org.drools.semantics.java.builder.ColumnBinder.java (1st
Method) {Sweet!} ...BUT:
Q3.1. Whats a Shadow got to do with a Class being final????????? (If 4 wasnt
released I'd say keep it that way, atleast I could disable shadow facts as a
work around)
Q3.2. To use Shadow or not comes
from "org.drools.spi.ObjectType.isShadowEnabled()"; there is no Setter for
this. So apart from making a class 'final' or defining a custom
'FactTemplate'
one does not have any option.
Q3.3. When I looked at 4 code, this code has disappeared (or probably got
refactored somewher I couldnt find it)
Final Question: Whats the deal guys? :o) Its hard enough looking at the code of
one version, but when I see drastic code change it makes one wonder if at this
rate changes, it's hard :o) Hope you understand.
Please let me know the answer to my questions!
Recommendation: I see a lot of acceptance on Decision Tables compared to DSL.
Once the code settles will give you guys some recommendations + code there, but
in the mean time please provide feature support to decsion tables as well as
you do for DRL, in future. If one can manage decision tables well, I see a lot
of power in getting people to accept rule engines compare to other approaches.
Thanks!
11:21 a.m.
Q1) Stateless is just that, stateless, you pass it the facts, it
executes and is done. If you need continuous access to the WorkingMemory
use the StatefulWorkingMemory interface, which actually extends the
WorkingMemory interface. Can you show me a use case where you neeed
access to the WorkingMemory from a StatelessSession, where you shouldn't
be using a StatefulSession to begin with.
Q2) Synchronized working memory is no longer needed, and to be honest
wasn't very good, as the WorkingMemory itself is now thread safe -
except the Iterators, but we'll eventually add thread safe adaptors for
them. Thats why its 4.0, instead of 3.1, signifying a break in API. the
changes really aren't that big and we don't want to create a confusing
and heavy api due to legacy support.
Q3.1 Shadow facts are needed if you want to work with POJOs and the
modify command, you should only disable them (i.e. use final) if you
know the object is immutable, if a class is final we can't extend it
with code generation and thus can't generate shadow facts for it, even
if we wanted to. The reason for this is we need to know the previous
value, prior to the modification. We are working on a way in which
shadow facts aren't needed, this involves not allowing "modify" outside
of the consequence and within the consequence we actually retract the
fact before any modifications and assert it after the modifications are
finished.
Q3.2 isShadowEnabled is for internal purposes only at the moment, thus
no setter. Once we have the code finish to allow optional shadow facts
we will expose some api for configuring this.
There is a lot of R&D going on and this a difficult field - it often
takes many attempts to get stuff right which results in a lot of
refactoring - but we do work on code simplication, just look at the
drools-compiler dialect API compared to how it is in 3.0 (where it was
called semantic), a huge change and massive simplifications as we move
towards pluggeable dialects.
Decision Tables in Excel are limited, although very business friendly,
to get any real power and flexability we need to be looking to
integrated this into Eclipse - due to limited resources, not sure if
that will get done any time soon - patch welcome :)
Arjun Dhar wrote:
Hi,
firstly, I compiled my code from 3.0 to 3.1 had issues, then from 3.1 to 4, I
cant access my working memory from my rule base and in 4 you've also got rid of
Synchronized working memory.
Questions :
===========
Related to shift from 3.1 to 4
-------------------------------
Q1. Once I create a 'StatelessSession'; how do I extract the Workingmemory?
There is no acessor. My code was written for 'SynchronizedWorkingMemory' so
means double trouble if there is no backward compatibility.
Q2. Couldn't you guys have deprecated stuff instead of just wiping it off? Is
there a reason for such a change as to restrict access to WorkingMemory or
SynchronizedWorkingmemory to those who would have got comfortable using it
directly? :o)
Related to shift from 3.0 to 3.1
---------------------------------
3. When I built my code on 3.1M1 the first thing I got was a
NullPointerException, I debugged the code and found due to additon of
ShadowFacts, if the class definition is NOT FINAL, it dynamically creates a
Shadow object. Refer: org.drools.semantics.java.builder.ColumnBinder.java (1st
Method) {Sweet!} ...BUT:
Q3.1. Whats a Shadow got to do with a Class being final????????? (If 4 wasnt
released I'd say keep it that way, atleast I could disable shadow facts as a
work around)
Q3.2. To use Shadow or not comes
from "org.drools.spi.ObjectType.isShadowEnabled()"; there is no Setter for
this. So apart from making a class 'final' or defining a custom
'FactTemplate'
one does not have any option.
Q3.3. When I looked at 4 code, this code has disappeared (or probably got
refactored somewher I couldnt find it)
Final Question: Whats the deal guys? :o) Its hard enough looking at the code of
one version, but when I see drastic code change it makes one wonder if at this
rate changes, it's hard :o) Hope you understand.
Please let me know the answer to my questions!
Recommendation: I see a lot of acceptance on Decision Tables compared to DSL.
Once the code settles will give you guys some recommendations + code there, but
in the mean time please provide feature support to decsion tables as well as
you do for DRL, in future. If one can manage decision tables well, I see a lot
of power in getting people to accept rule engines compare to other approaches.
Thanks!
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
12:59 p.m.
Sorry thats the stateful working memory interface, StatefulSession -
just incase my opening paragraph confuses anyone.
Mark Proctor wrote:
Q1) Stateless is just that, stateless, you pass it the facts, it
executes and is done. If you need continuous access to the
WorkingMemory use the StatefulWorkingMemory interface, which actually
extends the WorkingMemory interface. Can you show me a use case where
you neeed access to the WorkingMemory from a StatelessSession, where
you shouldn't be using a StatefulSession to begin with.
Q2) Synchronized working memory is no longer needed, and to be honest
wasn't very good, as the WorkingMemory itself is now thread safe -
except the Iterators, but we'll eventually add thread safe adaptors
for them. Thats why its 4.0, instead of 3.1, signifying a break in
API. the changes really aren't that big and we don't want to create a
confusing and heavy api due to legacy support.
Q3.1 Shadow facts are needed if you want to work with POJOs and the
modify command, you should only disable them (i.e. use final) if you
know the object is immutable, if a class is final we can't extend it
with code generation and thus can't generate shadow facts for it, even
if we wanted to. The reason for this is we need to know the previous
value, prior to the modification. We are working on a way in which
shadow facts aren't needed, this involves not allowing "modify"
outside of the consequence and within the consequence we actually
retract the fact before any modifications and assert it after the
modifications are finished.
Q3.2 isShadowEnabled is for internal purposes only at the moment, thus
no setter. Once we have the code finish to allow optional shadow facts
we will expose some api for configuring this.
There is a lot of R&D going on and this a difficult field - it often
takes many attempts to get stuff right which results in a lot of
refactoring - but we do work on code simplication, just look at the
drools-compiler dialect API compared to how it is in 3.0 (where it was
called semantic), a huge change and massive simplifications as we move
towards pluggeable dialects.
Decision Tables in Excel are limited, although very business friendly,
to get any real power and flexability we need to be looking to
integrated this into Eclipse - due to limited resources, not sure if
that will get done any time soon - patch welcome :)
Arjun Dhar wrote:
> Hi,
> firstly, I compiled my code from 3.0 to 3.1 had issues, then from
> 3.1 to 4, I cant access my working memory from my rule base and in 4
> you've also got rid of Synchronized working memory.
>
> Questions :
> ===========
>
> Related to shift from 3.1 to 4
> -------------------------------
> Q1. Once I create a 'StatelessSession'; how do I extract the
> Workingmemory? There is no acessor. My code was written for
> 'SynchronizedWorkingMemory' so means double trouble if there is no
> backward compatibility.
> Q2. Couldn't you guys have deprecated stuff instead of just wiping it
> off? Is there a reason for such a change as to restrict access to
> WorkingMemory or SynchronizedWorkingmemory to those who would have
> got comfortable using it directly? :o)
>
> Related to shift from 3.0 to 3.1
> ---------------------------------
> 3. When I built my code on 3.1M1 the first thing I got was a
> NullPointerException, I debugged the code and found due to additon of
> ShadowFacts, if the class definition is NOT FINAL, it dynamically
> creates a Shadow object. Refer:
> org.drools.semantics.java.builder.ColumnBinder.java (1st Method)
> {Sweet!} ...BUT:
>
> Q3.1. Whats a Shadow got to do with a Class being final?????????
> (If 4 wasnt released I'd say keep it that way, atleast I could
> disable shadow facts as a work around)
> Q3.2. To use Shadow or not comes from
> "org.drools.spi.ObjectType.isShadowEnabled()"; there is no Setter for
> this. So apart from making a class 'final' or defining a custom
> 'FactTemplate' one does not have any option. Q3.3. When I looked
> at 4 code, this code has disappeared (or probably got refactored
> somewher I couldnt find it)
> Final Question: Whats the deal guys? :o) Its hard enough looking at
> the code of one version, but when I see drastic code change it makes
> one wonder if at this rate changes, it's hard :o) Hope you understand.
>
> Please let me know the answer to my questions!
> Recommendation: I see a lot of acceptance on Decision Tables compared
> to DSL. Once the code settles will give you guys some recommendations
> + code there, but in the mean time please provide feature support to
> decsion tables as well as you do for DRL, in future. If one can
> manage decision tables well, I see a lot of power in getting people
> to accept rule engines compare to other approaches.
>
> Thanks!
>
> _______________________________________________
> rules-dev mailing list
> rules-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
>
>
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
6:48 p.m.
Mark Proctor <mproctor <at> codehaus.org> writes:
Sorry thats the stateful working memory interface, StatefulSession -
just incase my opening paragraph confuses anyone.
Mark Proctor wrote:
Hi Appreciate the quick response and accept all that is written; as for 1 and
3.2.
TECHNICAL
================================
[1]
"Can you show me a use case where you neeed
access to the WorkingMemory from a StatelessSession"
...
Conceptually No, since you have it covered by allowing a person to Assert a
list at a time (Faster when doing Batch mode; this is what I was doing) ,
except had built a wrapper method On the 'WorkingMemory' to achieve this. So
will just have to do re-factoring to my code which again will not be backward
compatible.
..So to summarize: Code written for JBoss Rules 4 may not work for 3.0 and 3.1.
If that isnt and enginerring issue then kindly ignore.
[3.2]
Suggestion:: If Shadows are not fully implemented then they should be
encapsulated and not be visible to users. From porting from 3.0 to 3.1 a
NullPointerException due to a feature not to be delivered, can be considered a
bug. From a blind QA perspective 3.2 is a bug!
ROOT CAUSE
================================
... I think if we look at both these points and from a project level, there is
an issue of Backward Compatibility. I guess you guys have your hands full to
care about that.
...But seriously, I understand the constraints you guys have to work with :o)
but wanted to let you know that while I'm a critic (hope am not being picky)
I'm also a big fan on what
is being built.
Thanks again!
Arjun
7:11 p.m.
Arjun,
3.1 was never a final release, it was a milestone release, 4.0 MR2 is
just a continuation of this, the api and language won't fully stabalise
and you can expect bugs unil we do a candidate release.
ShadowFacts were finished and shouldn't be visible to the user, however
code generation in Java has known problems - which hibernate proxies
also suffer from - where classes must have a default constructor and
must not use the final modifier. Thanks to Objenesis,
http://objenesis.googlecode.com/svn/docs/index.html, M2 was able to get
over the default constructor limitation, but there is nothing we can do
about final. The work towards allowing ShadowFacts to be optional is
additional to this, i.e. its a new feature. As said before these are
milestone releases, aimed to give you a "snapshot" at our R&D progress,
we give no guarantees and you must expect rough edges and big changes -
the rewards are you help us make a much better 4.0 final release.
Backwards compatability is always an issue, but that's why we did the
version number change, we believe the changes and the advantages gained
make this worth while.
Mark
Arjun Dhar wrote:
Mark Proctor <mproctor <at> codehaus.org> writes:
> Sorry thats the stateful working memory interface, StatefulSession -
> just incase my opening paragraph confuses anyone.
> Mark Proctor wrote:
>
Hi Appreciate the quick response and accept all that is written; as for 1 and
3.2.
TECHNICAL
================================
[1]
"Can you show me a use case where you neeed
> access to the WorkingMemory from a StatelessSession"
>
... Conceptually No, since you have it covered by allowing a person to Assert a
list at a time (Faster when doing Batch mode; this is what I was doing) ,
except had built a wrapper method On the 'WorkingMemory' to achieve this. So
will just have to do re-factoring to my code which again will not be backward
compatible.
..So to summarize: Code written for JBoss Rules 4 may not work for 3.0 and 3.1.
If that isnt and enginerring issue then kindly ignore.
[3.2]
Suggestion:: If Shadows are not fully implemented then they should be
encapsulated and not be visible to users. From porting from 3.0 to 3.1 a
NullPointerException due to a feature not to be delivered, can be considered a
bug. From a blind QA perspective 3.2 is a bug!
ROOT CAUSE
================================
... I think if we look at both these points and from a project level, there is
an issue of Backward Compatibility. I guess you guys have your hands full to
care about that.
...But seriously, I understand the constraints you guys have to work with :o)
but wanted to let you know that while I'm a critic (hope am not being picky)
I'm also a big fan on what
is being built.
Thanks again!
Arjun
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
7:53 p.m.
btw SyncrhonisedWorkingMemory used the same interface as WorkingMemory.
StatefulSession just extends WorkingMemory, so the API change for you
should be minimal.
Mark
Mark Proctor wrote:
Arjun,
3.1 was never a final release, it was a milestone release, 4.0 MR2 is
just a continuation of this, the api and language won't fully
stabalise and you can expect bugs unil we do a candidate release.
ShadowFacts were finished and shouldn't be visible to the user,
however code generation in Java has known problems - which hibernate
proxies also suffer from - where classes must have a default
constructor and must not use the final modifier. Thanks to Objenesis,
http://objenesis.googlecode.com/svn/docs/index.html, M2 was able to
get over the default constructor limitation, but there is nothing we
can do about final. The work towards allowing ShadowFacts to be
optional is additional to this, i.e. its a new feature. As said before
these are milestone releases, aimed to give you a "snapshot" at our
R&D progress, we give no guarantees and you must expect rough edges
and big changes - the rewards are you help us make a much better 4.0
final release.
Backwards compatability is always an issue, but that's why we did the
version number change, we believe the changes and the advantages
gained make this worth while.
Mark
Arjun Dhar wrote:
> Mark Proctor <mproctor <at> codehaus.org> writes:
>
>
>> Sorry thats the stateful working memory interface, StatefulSession -
>> just incase my opening paragraph confuses anyone.
>> Mark Proctor wrote:
>>
>
>
> Hi Appreciate the quick response and accept all that is written; as for 1 and
> 3.2.
>
> TECHNICAL
> ================================
> [1]
> "Can you show me a use case where you neeed
>
>> access to the WorkingMemory from a StatelessSession"
>>
> ... Conceptually No, since you have it covered by allowing a person to Assert a
> list at a time (Faster when doing Batch mode; this is what I was doing) ,
> except had built a wrapper method On the 'WorkingMemory' to achieve this. So
> will just have to do re-factoring to my code which again will not be backward
> compatible.
>
> ..So to summarize: Code written for JBoss Rules 4 may not work for 3.0 and 3.1.
> If that isnt and enginerring issue then kindly ignore.
>
> [3.2]
> Suggestion:: If Shadows are not fully implemented then they should be
> encapsulated and not be visible to users. From porting from 3.0 to 3.1 a
> NullPointerException due to a feature not to be delivered, can be considered a
> bug. From a blind QA perspective 3.2 is a bug!
>
>
> ROOT CAUSE
> ================================
> ... I think if we look at both these points and from a project level, there is
> an issue of Backward Compatibility. I guess you guys have your hands full to
> care about that.
>
> ...But seriously, I understand the constraints you guys have to work with :o)
> but wanted to let you know that while I'm a critic (hope am not being picky)
> I'm also a big fan on what
> is being built.
>
> Thanks again!
> Arjun
>
>
>
> _______________________________________________
> rules-dev mailing list
> rules-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
>
>
------------------------------------------------------------------------
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
2:24 a.m.
Mark Proctor <mproctor <at> codehaus.org> writes:
btw SyncrhonisedWorkingMemory used the same interface as WorkingMemory.
StatefulSession just extends WorkingMemory, so the API change for you
should be minimal.
Mark
Mark Proctor wrote:
Q) ok! ..So how do I use "WorkingMemoryFileLogger" with a StatelessSession and
how do I obtain Fact Handles to the facts I asserted?
Feature Requested:
------------------
Q) also, I wish to override the conflict resolution strategy to only have the
most significant rule execute and not bother about arranging the rest. Winner
takes all strategy. In 4 are you planning on anything for this? Ok, I think
this topic deserves a little more respect:
When we create an agenda based on priorities for the rules suited to fire; two
things need to be done
1. Intelligence to figure out in certain cases what is priority.
Example:
Rain = True <-- More generic Rule
Party = False
Rain = True <-- More specific rule
Umbrella = True
Party = True
...i've observed that in such scenarios, the rule engine can be intelligent
enoug to figure out that a more specific case exists because it is more apt for
that situation. Ofcourse GIGO, if the analyst is trying to confuse an engine,
thats illogical in the first place. But logic holds here.
2. When priorities are assigned, the Rule with the highest priority executes
firest. But that assumption is incorrect as there can be 3 possibilites:
2.1. Only execute the most important rule (Short Curcuit)
2.2. Most significant rule, fires first (Like we have when I last checked)
2.3. Most significant rule should actually execute last, because we want it to
prevail over the results carried out by others.
..While 2.3 can achieved in a less sophisticated manner by reversing the
priorities 2.1. ... there is no ready made way to achieve 2.1.
If there is, please let me know. If not, and i build it would you find
acceptance in yr next release?
thanks,
Arjun
7:59 a.m.
WorkingMemoryFileLogger is still something we need to update. You get
access to the results with StatelessSessionResults, you don't get access
to the FactHandles as they are meaningless in a stateless session, you
can't use them anyway. We may add an internal method to access the
working memory, i.e. accessible by casting, but I don't really want to
have a public method for this as your average user will just abuse it.
We use to have user pluggeable conflict resolution strategies, but it
got removed during some big refactoring, i do intend to add it in before
4.0 final. If people build useful conflict resolution strategies, we
will include them - but please do try and base them on existing
literature if you can, especially for the naming of the strategies.
Mark
Arjun Dhar wrote:
Mark Proctor <mproctor <at> codehaus.org> writes:
> btw SyncrhonisedWorkingMemory used the same interface as WorkingMemory.
> StatefulSession just extends WorkingMemory, so the API change for you
> should be minimal.
> Mark
> Mark Proctor wrote:
>
Q) ok! ..So how do I use "WorkingMemoryFileLogger" with a StatelessSession and
how do I obtain Fact Handles to the facts I asserted?
Feature Requested:
------------------
Q) also, I wish to override the conflict resolution strategy to only have the
most significant rule execute and not bother about arranging the rest. Winner
takes all strategy. In 4 are you planning on anything for this? Ok, I think
this topic deserves a little more respect:
When we create an agenda based on priorities for the rules suited to fire; two
things need to be done
1. Intelligence to figure out in certain cases what is priority.
Example:
Rain = True <-- More generic Rule
Party = False
Rain = True <-- More specific rule
Umbrella = True
Party = True
...i've observed that in such scenarios, the rule engine can be intelligent
enoug to figure out that a more specific case exists because it is more apt for
that situation. Ofcourse GIGO, if the analyst is trying to confuse an engine,
thats illogical in the first place. But logic holds here.
2. When priorities are assigned, the Rule with the highest priority executes
firest. But that assumption is incorrect as there can be 3 possibilites:
2.1. Only execute the most important rule (Short Curcuit)
2.2. Most significant rule, fires first (Like we have when I last checked)
2.3. Most significant rule should actually execute last, because we want it to
prevail over the results carried out by others.
..While 2.3 can achieved in a less sophisticated manner by reversing the
priorities 2.1. ... there is no ready made way to achieve 2.1.
If there is, please let me know. If not, and i build it would you find
acceptance in yr next release?
thanks,
Arjun
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
6432
days inactive
6480
days old
9 comments
4 participants
participants (4)
-
Arjun Dhar -
Edson Tirelli -
Mark Proctor -
Wolfgang Betz