Paul Browne | 1 Nov 21:55 2007
Picon

Re: [rules-dev] Using JAAS with BRMS on Weblogic

Trevor,

Did you get anywhere with this? Does it work when you don't have the 
JAAS policy in place? Are you able to secure other non-BRMS webapps?

Not really Drools related, but I'm curious.

Regards

Paul

Harris Trevor wrote:
>
> I have been doing some research and I have found that I set this up 
> wrong but it still does not work?
>
> I have now done the following:
>
> Edited components.xml and added
>
> <security:identity authenticate-method="#{authenticator.authenticate}" 
> jaas-config-name="brms"/>
>
> Added the following to the weblogic server jvm startup
>
> -Djava.security.auth.login.config=d:\jass.config
>
> Created a file jass.config containing
>
> brms {
(Continue reading)

Harris Trevor | 2 Nov 09:52 2007

RE: [rules-dev] Using JAAS with BRMS on Weblogic

No I was not able to get it to work. BRMS uses seam which I have not
used before. As you can see it just does not seem to register the
configuration.

Sorry I cannot be of more help 

Regards Trevor

-----Original Message-----
From: rules-dev-bounces <at> lists.jboss.org
[mailto:rules-dev-bounces <at> lists.jboss.org] On Behalf Of Paul Browne
Sent: 01 November 2007 20:56
To: Rules Dev List
Subject: Re: [rules-dev] Using JAAS with BRMS on Weblogic

Trevor,

Did you get anywhere with this? Does it work when you don't have the 
JAAS policy in place? Are you able to secure other non-BRMS webapps?

Not really Drools related, but I'm curious.

Regards

Paul

Harris Trevor wrote:
>
> I have been doing some research and I have found that I set this up 
> wrong but it still does not work?
(Continue reading)

nicolae oana | 5 Nov 10:41 2007
Picon

[rules-dev] "First CfP of ANSyM 2008: Adaptive Networked Systems and Media"

[We apologize in advance if you receive multiple copies of this CFP]

ANSyM’2008: Adaptive Networked Systems and Media
------------------------------------------------

June 18-20, 2008, Wroclaw, Poland
http://oxygen.informatik.tu-cottbus.de/ANSyM2008

Special session within the framework of IEA/AIE 2008 conference
http://www.iea-aie.pwr.wroc.pl/

Please submit your paper here:
http://www.iea-aie.pwr.wroc.pl/conftool


Session Organizers
------------------
Dan Popescu, http://automation.ucv.ro/membri/Dan%20Popescu/DPopescu.htm
University of Craiova, Romania, dpopescu <at> automation.ucv.ro

Costin Badica, http://software.ucv.ro/~badica_costin
University of Craiova, Romania, badica_costin <at> software.ucv.ro

Adrian Giurca, http://www.informatik.tu-cottbus.de/~agiurca/
Brandenburg University of Technology, Germany, giurca <at> tu-cottbus.de


Call for Papers
---------------
Adaptability is a generic property of a system that consists in the system’s capability to self-adjust its behavior according to its input, load or users in order to meet certain performance criteria. Adaptability has been described as a characteristic of autonomous behavior and is often related to possessing learning capabilities through analysis of past behaviors and interactions. Adaptability has been intensely studied by various areas of engineering including artificial intelligence, control systems and human centered systems. Adaptability has been set as an important requirement for systems devised to work in new generation global networked and distributed environments like wireless networks, P2P networks, Web systems, multi-agent systems, grids, etc. Such systems are expected to pose new challenges for the development and application of adaptation techniques, due to their special characteristics including: interconnectivity, interactivity, distribution, heterogeneity an
default-tolerance.

This special session welcomes submissions covering all aspects of adaptability in networked systems and media, including (but not limited to):
- Self-configuring and self-structuring systems
- Adaptive control in communication networks
- Adaptive networked control systems
- Rule-based adaptive systems
- Computational intelligence and adaptability
- Adaptability in multi-agent systems
- Personalized and adaptive hypermedia
- Adaptive information provisioning
- Adaptive coordination
- Adaptability in e-services, including e-learning and e-commerce
- Adaptive negotiation
- Context-aware systems
- Machine learning methods for adaptive systems
- Adaptive security systems

Papers acceptance will be judged based on their relevance, clarity of presentation, originality and accuracy of results and proposed solutions.

The papers will be published in the IEA/AIE 2008 conference proceedings, in a bound volume by Springer Verlag in their Lecture Notes in Artificial Intelligence series.

Important dates
---------------
Papers submission: November 15, 2007
Notification of acceptance: February 1, 2008
Final submission: February 28, 2008
Workshop date: To be announced (Inside June 18-20, 2008)

Program Committee
-----------------
Rajendra Akerkar, Technomathematics Research Foundation, India
Steve Banks, University of Sheffield, UK
Dumitru Burdescu, University of Craiova, Romania
Dorian Cojocaru, University of Craiova, Romania
Jens Dietrich, Institute of Information Sciences and Technology, New Zealand
Petr Dostal, Tomas Bata University in Zlin, Czech Republic
Dragan Gasevic, Athabasca University, Canada
Maria Ganzha, Elblag University of Humanities and Economics, Poland
Dariusz Krol, Wroclaw University of Technology, Poland
Ronaldo Menezes, Florida Institute of Technology, USA
Masoud Mohammadian, University of Canberra, Australia
Grzegorz J. Nalepa, AGH University of Science and Technology, Poland
Philippe Trigano, University of Technology of Compiegne, France
Marcin Paprzycki, Systems Research Institute, Polish Academy of Science, Poland
Janusz Sobecki, Wroclaw University of Technology, Poland
Vladimir Rasvan, University of Craiova, Romania
Athanasios Vasilakos, University of Western Macedonia, Greece
Gerd Wagner, Brandenburg University of Technology at Cottbus, Germany

__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

_______________________________________________
rules-dev mailing list
rules-dev <at> lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
PN Subramanian | 6 Nov 10:27 2007
Picon

[rules-dev] Drools with j2sdk1.4

Hi,

While going through the manual for Drools 4.0, i came across this

"Drools works with JDK1.5 and above. ..." -

We use j2sdk1.4/j2ee 1.4 in our project - can we use Drools ? Would the feature set be limited ?

--
P.N.Subramanian

_______________________________________________
rules-dev mailing list
rules-dev <at> lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
Edson Tirelli | 6 Nov 11:58 2007

Re: [rules-dev] Drools with j2sdk1.4


    Drools 4.0.x works for Java 1.4. Although, Drools 4.1 and above will probably only work for Java 5+.

    []s
    Edson

2007/11/6, PN Subramanian < pn.subramanian <at> gmail.com>:
Hi,

While going through the manual for Drools 4.0, i came across this

"Drools works with JDK1.5 and above. ..." -

We use j2sdk1.4/j2ee 1.4 in our project - can we use Drools ? Would the feature set be limited ?

--
P.N.Subramanian

_______________________________________________
rules-dev mailing list
rules-dev <at> lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev




--
  Edson Tirelli
  Software Engineer - JBoss Rules Core Developer
  Office: +55 11 3529-6000
  Mobile: +55 11 9287-5646
  JBoss, a division of Red Hat <at> www.jboss.com
_______________________________________________
rules-dev mailing list
rules-dev <at> lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
Mark Proctor | 6 Nov 16:43 2007

Re: [rules-dev] Drools with j2sdk1.4

Edson Tirelli wrote:

    Drools 4.0.x works for Java 1.4. Although, Drools 4.1 and above will probably only work for Java 5+.
the BRMS in 4.0.x is JDK1.5 and above, the engine, compiler, decision tables, jsr94 etc are jdk1.4 in Drools 4.0.x. for our next major release everything will be jdk1.5+

    []s
    Edson

2007/11/6, PN Subramanian < pn.subramanian <at> gmail.com>:
Hi,

While going through the manual for Drools 4.0, i came across this

"Drools works with JDK1.5 and above. ..." -

We use j2sdk1.4/j2ee 1.4 in our project - can we use Drools ? Would the feature set be limited ?

--
P.N.Subramanian

_______________________________________________
rules-dev mailing list
rules-dev <at> lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev




--
  Edson Tirelli
  Software Engineer - JBoss Rules Core Developer
  Office: +55 11 3529-6000
  Mobile: +55 11 9287-5646
  JBoss, a division of Red Hat <at> www.jboss.com _______________________________________________ rules-dev mailing list rules-dev <at> lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-dev

_______________________________________________
rules-dev mailing list
rules-dev <at> lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
Edson Tirelli | 7 Nov 22:12 2007

[rules-dev] Determining if a class is an event or not


   All,

   I reached a point where I need to make a design decision and would like your opinion about it.
   Imagine the following scenario:

   A user has a domain model like this:

package a.b.c ;
public interface Event { ... }

package x.y.z;
public class MyEvent implements a.b.c.Event {...}

   Then, in his DRL file he writes:

package p.q.r;
import event a.b.c.*;  
rule X
when
    Event( ... )
then
    ...
end

   So, it is clear that a.b.c.Event should be handled as an event by the engine.
   At runtime, the user asserts an object of the class x.y.z.MyEvent into the working memory. Seems clear to me (and probably to the user) that MyEvent should be handled as an event, since by DRL semantics, a.b.c.* are all events, and by OO class hierarchy concept, since a.b.c.Event is an event, x.y.z.MyEvent is an event too.

   My question is: how the engine knows that MyEvent is an event, since it only has the x.y.z.MyEvent class as input?
   The only answer I have is that when the first MyEvent instance is asserted into the working memory, we must get the class name and iterate over all event import declarations checking for a match. In case no one is found, we need to repeat the process for each interface and each class up in the MyEvent hierarchy. Once this process is complete, we cache the results in the ObjectTypeConf.
   This may be a quite heavy process to be executed each time a fact of a different class is asserted in the working memory for the first time, but I can't think a different user-friendly way to solve the question.

   The alternatives would be intrusive, IMO, breaking the drools premise to work with user-defined POJOs as facts: use anotations to annotate classes that are events, or mandate users implement a specific interface for events.

    Any better idea?

    []s
    Edson



   


--
  Edson Tirelli
  Software Engineer - JBoss Rules Core Developer
  Office: +55 11 3529-6000
  Mobile: +55 11 9287-5646
  JBoss, a division of Red Hat <at> www.jboss.com
_______________________________________________
rules-dev mailing list
rules-dev <at> lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
Matthias | 8 Nov 14:08 2007
Picon

Re: [rules-dev] Determining if a class is an event or not

Edson Tirelli <tirelli <at> post.com> writes:

> 
> 
>    All,   I reached a point where I need to make a design decision and would
like your opinion about it.   Imagine the following scenario:   A user has a
domain model like this:package a.b.c
> ;public interface Event { ... }package x.y.z;public class MyEvent implements
a.b.c.Event {...}   Then, in his DRL file he writes:package p.q.r;import event
a.b.c.*;    rule Xwhen
>     Event( ... )then    ...end   So, it is clear that a.b.c.Event should be
handled as an event by the engine.   At runtime, the user asserts an object of
the class x.y.z.MyEvent into the working memory. Seems clear to me (and probably
to the user) that MyEvent should be handled as an event, since by DRL semantics, 
> a.b.c.* are all events, and by OO class hierarchy concept, since a.b.c.Event
is an event, x.y.z.MyEvent is an event too.   My question is: how the engine
knows that MyEvent is an event, since it only has the x.y.z.MyEvent
>  class as input?   The only answer I have is that when the first MyEvent
instance is asserted into the working memory, we must get the class name and
iterate over all event import declarations checking for a match. In case no one
is found, we need to repeat the process for each interface and each class up in
the MyEvent hierarchy. Once this process is complete, we cache the results in
the ObjectTypeConf. 
>    This may be a quite heavy process to be executed each time a fact of a
different class is asserted in the working memory for the first time, but I
can't think a different user-friendly way to solve the question.
>    The alternatives would be intrusive, IMO, breaking the drools premise to
work with user-defined POJOs as facts: use anotations to annotate classes that
are events, or mandate users implement a specific interface for events.
>     Any better idea?    []s    Edson    --   Edson Tirelli  Software Engineer
- JBoss Rules Core Developer  Office: +55 11 3529-6000  Mobile: +55 11 9287-5646
>   JBoss, a division of Red Hat  <at>  www.jboss.com
> 
> 
> _______________________________________________
> rules-dev mailing list
> rules-dev <at> lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
> 

Edson,

I got your striving not to mandate users implement a specific interface for
events. However, why not at least introducing an empty event interface (i.e. a
marker interface, similar to the Serializable interface in Java) the
user-defined event class(es) have to implement? This way, when inserting a
MyEvent instance, you can simply check whether it implements the event interface
(by means of 'instanceof'). Moreover, while parsing the import statements of a
rule file, it enables you to double-check whether all the "event imports" really
refer to classes implementing the (empty) event interface.
In this regard, for me another question raises: Without making any restrictions
on the structure for a user defined event class, how do you make sure it has all
the  required attributes of an event (which in my opinion must be a timestamp,
at least) and how do you access them (necessary for temporal relationships)?
Having said this, in my opinion defining an empty event interface may not be
sufficient; in addition, it must force the user to implement a method returning
the event's occurrence date (i.e. the timestamp) at least... Or how would you
handle this issue?

Matthias 

_______________________________________________
rules-dev mailing list
rules-dev <at> lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev

Anstis, Michael (M. | 8 Nov 15:27 2007
Picon

RE: [rules-dev] Determining if a class is an event or not

Here's my 2 cents - as a non-contributor to Drools codebase ;-)

You could add insertEventFactTypeThingie to the API? Then you need just
check that the class has been declared as an event in the DRL similar to
what must already happen for normal DRL imports. I personally don't have
issue with implementing a marker interface (this is what frameworks like
Hibernate, EJB3 and Spring etc have been imposing for years). What "wiring"
does the POJO need to become an Event for use in Drools? Are you trying to
internalise too much at the risk of making the event mechanism inflexible?

Cheers,

Mike

-----Original Message-----
From: rules-dev-bounces <at> lists.jboss.org
[mailto:rules-dev-bounces <at> lists.jboss.org] On Behalf Of Matthias
Sent: 08 November 2007 13:09
To: rules-dev <at> lists.jboss.org
Subject: Re: [rules-dev] Determining if a class is an event or not

Edson Tirelli <tirelli <at> post.com> writes:

> 
> 
>    All,   I reached a point where I need to make a design decision and
would
like your opinion about it.   Imagine the following scenario:   A user has a
domain model like this:package a.b.c
> ;public interface Event { ... }package x.y.z;public class MyEvent
implements
a.b.c.Event {...}   Then, in his DRL file he writes:package p.q.r;import
event
a.b.c.*;    rule Xwhen
>     Event( ... )then    ...end   So, it is clear that a.b.c.Event should
be
handled as an event by the engine.   At runtime, the user asserts an object
of
the class x.y.z.MyEvent into the working memory. Seems clear to me (and
probably
to the user) that MyEvent should be handled as an event, since by DRL
semantics, 
> a.b.c.* are all events, and by OO class hierarchy concept, since
a.b.c.Event
is an event, x.y.z.MyEvent is an event too.   My question is: how the engine
knows that MyEvent is an event, since it only has the x.y.z.MyEvent
>  class as input?   The only answer I have is that when the first MyEvent
instance is asserted into the working memory, we must get the class name and
iterate over all event import declarations checking for a match. In case no
one
is found, we need to repeat the process for each interface and each class up
in
the MyEvent hierarchy. Once this process is complete, we cache the results
in
the ObjectTypeConf. 
>    This may be a quite heavy process to be executed each time a fact of a
different class is asserted in the working memory for the first time, but I
can't think a different user-friendly way to solve the question.
>    The alternatives would be intrusive, IMO, breaking the drools premise
to
work with user-defined POJOs as facts: use anotations to annotate classes
that
are events, or mandate users implement a specific interface for events.
>     Any better idea?    []s    Edson    --   Edson Tirelli  Software
Engineer
- JBoss Rules Core Developer  Office: +55 11 3529-6000  Mobile: +55 11
9287-5646
>   JBoss, a division of Red Hat  <at>  www.jboss.com
> 
> 
> _______________________________________________
> rules-dev mailing list
> rules-dev <at> lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
> 

Edson,

I got your striving not to mandate users implement a specific interface for
events. However, why not at least introducing an empty event interface (i.e.
a
marker interface, similar to the Serializable interface in Java) the
user-defined event class(es) have to implement? This way, when inserting a
MyEvent instance, you can simply check whether it implements the event
interface
(by means of 'instanceof'). Moreover, while parsing the import statements of
a
rule file, it enables you to double-check whether all the "event imports"
really
refer to classes implementing the (empty) event interface.
In this regard, for me another question raises: Without making any
restrictions
on the structure for a user defined event class, how do you make sure it has
all
the  required attributes of an event (which in my opinion must be a
timestamp,
at least) and how do you access them (necessary for temporal relationships)?
Having said this, in my opinion defining an empty event interface may not be
sufficient; in addition, it must force the user to implement a method
returning
the event's occurrence date (i.e. the timestamp) at least... Or how would
you
handle this issue?

Matthias 

_______________________________________________
rules-dev mailing list
rules-dev <at> lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
Attachment (smime.p7s): application/x-pkcs7-signature, 5621 bytes
_______________________________________________
rules-dev mailing list
rules-dev <at> lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
Edson Tirelli | 8 Nov 15:44 2007

Re: [rules-dev] Determining if a class is an event or not


   Matthias,

   Thanks for the feedback. Since you are starting to dig into drools inner workings, I think it is good to dig a bit more on this subject and detail my comments, so that we can have your opinion on the broader subject of the platform design.

> However, why not at least introducing an empty event interface (i.e. a marker interface, similar to the Serializable interface in Java) the user-defined event class(es) have to implement?
   We always tried to avoid mandating the user to change its domain model to use Drools and "contaminating" it with Drools specific classes/interfaces. This way, different from other engines, we work with simple POJOs as facts. There are also other reasons for that, like we want to implement support for other fact types, like ontologies, etc, but the main one I still thing is the one above.
    So, we can have an Event interface or an annotation that the user may use to explicit mark a Java class as an event, but IMO, we should use the Event interface as an alternative way of doing it, and not as the only way.
    A simpler solution we could go for is to mandate that the user declares all its event classes/interfaces with a declare like statement in the DRL instead of using the "import event" syntax. Something like that:

declare event a.b.c.Foo;

    So the engine can load the class/interface a.b.c.Foo and check each asserted fact to see if it is an a.b.c.Foo instance. That would be easier from an engine perspective, but would be verbose from a users perspective, since we would not be able to allow wildcards in such declaration. Would that be better?

    The other question you asked is really interesting and I also don't have a definitive answer, but have some ideas:

> In this regard, for me another question raises: Without making any restrictions on the structure for a user defined event class, how do you make sure it has all the  required attributes of an event (which in my opinion must be a timestamp, at least) and how do you access them (necessary for temporal relationships)?
    In the paper "Discarding unused temporal information in a Production System", by Dan Teodosiu and Günter Pollak, they state that "Events carry an additional *implicit* attribute that represents the timestamp. The value of this attribute is automatically set upon creation of an event to the current value of the system-clock."
    I agree with them, except for the "system-clock" part. Replace "system-clock" by "engine-clock" and I think we get the best compromise.
    We know that most real-world events are generated with an explicit timestamp attribute, but since we may be handling events coming from different sources without any guarantee that the sources have synchronized clocks, we can not rely on the eventual explicit timestamp attribute for reasoning in the engine. Not relying on that also give us the ability to handle events that do not contain the explicit timestamp attribute.
    What I am thinking is:

1. In current Drools implementation, each fact asserted into the rules engine is wrapped in a FactHandle implementation. This FactHandle implementation contains metadata attributes that are used by the engine during fact manipulation and reasoning. What I'm suggesting is we derive a new EventFactHandle implementation that would contain all event's implicit attributes and metada we need, including the timestamp. This would allow us to also support different semantic-models for the timestamp, and that is why I asked you about the point-interval semantics. The easiest one would be the point-in-time semantic, obviously.

2. We also will need to create the engine clock abstraction, and, as we discussed previously, we will probably need 4 implementations:
- "System Clock": a clock that periodically synchronizes with the machine clock
- "Event based clock": a clock that is updated every time a given event arrives
- "Pseudo Clock": a generic implementation that is arbitrarily updated by application code
- "Event Attribute Clock": a clock that is updated by a configured event attribute

3. Every time a new event is inserted into the engine, we would then populate the "implicit" attributes by using a configurable strategy. For instance, if a user wants to use the explicit value of the object timestamp as the event timestamp, the configurable strategy would simply copy the value of the attribute to the implicit event attribute. If the user wants to use the engine clock timestamp at assertion time as the event timestamp, the configurable strategy would simply request the current value to the engine clock and populate the event timestamp with this attribute.

   What do you think about the above?

    Thanks,
      Edson



2007/11/8, Matthias <matthias.groch <at> sap.com>:
Edson Tirelli <tirelli <at> post.com> writes:

>
>
>    All,   I reached a point where I need to make a design decision and would
like your opinion about it.   Imagine the following scenario:   A user has a
domain model like this:package a.b.c
> ;public interface Event { ... }package x.y.z;public class MyEvent implements
a.b.c.Event {...}   Then, in his DRL file he writes:package p.q.r;import event
a.b.c.*;    rule Xwhen
>     Event( ... )then    ...end   So, it is clear that a.b.c.Event should be
handled as an event by the engine.   At runtime, the user asserts an object of
the class x.y.z.MyEvent into the working memory. Seems clear to me (and probably
to the user) that MyEvent should be handled as an event, since by DRL semantics,
> a.b.c.* are all events, and by OO class hierarchy concept, since a.b.c.Event
is an event, x.y.z.MyEvent is an event too.   My question is: how the engine
knows that MyEvent is an event, since it only has the x.y.z.MyEvent
>  class as input?   The only answer I have is that when the first MyEvent
instance is asserted into the working memory, we must get the class name and
iterate over all event import declarations checking for a match. In case no one
is found, we need to repeat the process for each interface and each class up in
the MyEvent hierarchy. Once this process is complete, we cache the results in
the ObjectTypeConf.
>    This may be a quite heavy process to be executed each time a fact of a
different class is asserted in the working memory for the first time, but I
can't think a different user-friendly way to solve the question.
>    The alternatives would be intrusive, IMO, breaking the drools premise to
work with user-defined POJOs as facts: use anotations to annotate classes that
are events, or mandate users implement a specific interface for events.
>     Any better idea?    []s    Edson    --   Edson Tirelli  Software Engineer
- JBoss Rules Core Developer  Office: +55 11 3529-6000  Mobile: +55 11 9287-5646
>   JBoss, a division of Red Hat  <at>  www.jboss.com
>
>
> _______________________________________________
> rules-dev mailing list
> rules-dev <at> lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
>


Edson,

I got your striving not to mandate users implement a specific interface for
events. However, why not at least introducing an empty event interface (i.e. a
marker interface, similar to the Serializable interface in Java) the
user-defined event class(es) have to implement? This way, when inserting a
MyEvent instance, you can simply check whether it implements the event interface
(by means of 'instanceof'). Moreover, while parsing the import statements of a
rule file, it enables you to double-check whether all the "event imports" really
refer to classes implementing the (empty) event interface.
In this regard, for me another question raises: Without making any restrictions
on the structure for a user defined event class, how do you make sure it has all
the  required attributes of an event (which in my opinion must be a timestamp,
at least) and how do you access them (necessary for temporal relationships)?
Having said this, in my opinion defining an empty event interface may not be
sufficient; in addition, it must force the user to implement a method returning
the event's occurrence date (i.e. the timestamp) at least... Or how would you
handle this issue?

Matthias

_______________________________________________
rules-dev mailing list
rules-dev <at> lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev



--
  Edson Tirelli
  Software Engineer - JBoss Rules Core Developer
  Office: +55 11 3529-6000
  Mobile: +55 11 9287-5646
  JBoss, a division of Red Hat <at> www.jboss.com
_______________________________________________
rules-dev mailing list
rules-dev <at> lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev

Gmane