[rules-dev] Question about kie - api & kie - internal (OSGIactivator)
Cristiano Gavião
cvgaviao at gmail.com
Thu Mar 28 15:41:32 EDT 2013
Trying to figure out the services that we could expose but seems that
won't be a simple job...
The first one that I found was org.kie.api.KieServices.
but I got really concerned about its default implementation... certainly
we will need to create an OSGi impl...
I could see that now there is a internal service registry that we
certainly need to wrap on top of OSGi one.
another concern is that I saw a lot of factory using static methods...
that will difficult to use osgi factory services...
On 28/03/13 10:45, Charles Moulliard wrote:
> I should have a look to the code as I don't know for the moment which
> one we would like to expose ?
>
>
> On Thu, Mar 28, 2013 at 2:42 PM, Cristiano Gavião <cvgaviao at gmail.com
> <mailto:cvgaviao at gmail.com>> wrote:
>
> well, the ones that is currently exposed is enough for you or do
> you want something more?
>
> 2013/3/28 Charles Moulliard <ch007m at gmail.com
> <mailto:ch007m at gmail.com>>
>
> We can use both on Karaf.
>
> Anyway the question is more for the moment "Which OSGI
> services would we like to expose on OSGI platform" instead of
> How to achieve that ?
>
>
> On Thu, Mar 28, 2013 at 1:51 PM, Cristiano Gavião
> <cvgaviao at gmail.com <mailto:cvgaviao at gmail.com>> wrote:
>
> I agree with you.... Blueprint and CDI has this advantage
> over DS.
>
> But I think I never had the necessity to inject beans in
> many years of development with OSGi. Injecting simple
> components and services fitted well all my needs. :) And
> the best from DS is that it is smart, small and fast.
>
> As Blueprint, CDI and DS uses xml we can provide all. But
> I don't know If there is a way to choose only one at
> runtime... I mean, what could happen in a system where we
> have both Blueprint and DS active?
>
>
> 2013/3/28 Charles Moulliard <ch007m at gmail.com
> <mailto:ch007m at gmail.com>>
>
> There is nevertheless one advantage of Aries Blueprint
> over Declarative Service which is :
> "Unlike Declarative Services, Blueprint can inject not
> only OSGi services, but also managed beans, i.e. plain
> old Java objects. Managed beans are local to the
> current component and cannot be injected into other
> components. Each Blueprint-enabled bundle has its own
> Blueprint context with managed beans and OSGi service
> references. The contexts of different bundles can
> interact by injecting services published by another
> bundle."
>
>
> On Wed, Mar 27, 2013 at 8:26 PM, Charles Moulliard
> <ch007m at gmail.com <mailto:ch007m at gmail.com>> wrote:
>
> Great !
>
>
> On Wed, Mar 27, 2013 at 7:04 PM, Cristiano Gavião
> <cvgaviao at gmail.com <mailto:cvgaviao at gmail.com>>
> wrote:
>
> Hi Charles,
>
> Step one (installation of bundles and its
> dependencies) seems to be ok ;)
>
> [INFO] drools-osgi-enviroment-tests
> ...................... SUCCESS [6.559s]
> [INFO] drools-osgi-enviroment-tests-common
> ............... SUCCESS [15.887s]
> [INFO]
> drools-osgi-enviroment-tests-equinox-juno
> ......... SUCCESS [20.176s]
> [INFO]
> drools-osgi-enviroment-tests-equinox-kepler
> ....... SUCCESS [17.581s]
> [INFO] drools-osgi-enviroment-tests-felix
> ................ SUCCESS [15.874s]
> [INFO] drools-osgi-enviroment-tests-jbosgi
> ............... SUCCESS [39.769s]
> [INFO]
> drools-osgi-enviroment-tests-knoplerfish
> .......... SUCCESS [14.839s]
> [INFO]
> ------------------------------------------------------------------------
>
> next step is to reuse the existent tests-jars
>
> cheers,
>
>
> Cristiano
>
>
>
> 2013/3/27 Charles Moulliard <ch007m at gmail.com
> <mailto:ch007m at gmail.com>>
>
> I think that those packages have been
> added since JDK 1.7 xxx. Reason why you
> should deploy the following bundles :
>
> https://github.com/droolsjbpm/droolsjbpm-integration/blob/master/drools-osgi/drools-karaf-features/src/main/filtered-resources/repository/features.xml
>
> with these versions
>
> https://github.com/droolsjbpm/droolsjbpm-integration/blob/master/drools-osgi/drools-karaf-features/pom.xml
>
>
> and more specifically 2.2.1 for jaxb-x
>
>
> On Wed, Mar 27, 2013 at 4:32 PM, Cristiano
> Gavião <cvgaviao at gmail.com
> <mailto:cvgaviao at gmail.com>> wrote:
>
> The packages that I'm aware of until
> now is:
> - org.apache.poi.openxml4j.exceptions
> - org.apache.poi.ss.usermodel (note
> that poi.jar exports this too)
>
> I'm getting another problem with
> servicemix bundles related to
> com.sun.tools.xjc. it seems that there
> is no bundle exporting
> com.sun.source.tree that is being
> required:
>
> ERROR: Bundle
> org.drools.decisiontables [38] Error
> starting
> mvn:org.drools/drools-decisiontables/6.0.0-SNAPSHOT
> (org.osgi.framework.BundleException:
> Unresolved constraint in bundle
> org.drools.decisiontables [38]: Unable
> to resolve 38.0: missing requirement
> [38.0] osgi.wiring.package;
> (osgi.wiring.package=org.drools.compiler.compiler)
> [caused by: Unable to resolve 29.0:
> missing requirement [29.0]
> osgi.wiring.package;
> (osgi.wiring.package=org.drools.core)
> [caused by: Unable to resolve 30.0:
> missing requirement [30.0]
> osgi.wiring.package;
> (osgi.wiring.package=com.sun.tools.xjc) [caused
> by: Unable to resolve 32.0: missing
> requirement [32.0]
> osgi.wiring.package;
> (osgi.wiring.package=com.sun.source.tree)]]])
> org.osgi.framework.BundleException:
> Unresolved constraint in bundle
> org.drools.decisiontables [38]: Unable
> to resolve 38.0: missing requirement
> [38.0] osgi.wiring.package;
> (osgi.wiring.package=org.drools.compiler.compiler)
> [caused by: Unable to resolve 29.0:
> missing requirement [29.0]
> osgi.wiring.package;
> (osgi.wiring.package=org.drools.core)
> [caused by: Unable to resolve 30.0:
> missing requirement [30.0]
> osgi.wiring.package;
> (osgi.wiring.package=com.sun.tools.xjc) [caused
> by: Unable to resolve 32.0: missing
> requirement [32.0]
> osgi.wiring.package;
> (osgi.wiring.package=com.sun.source.tree)]]]
>
> I'm using this deps:
>
> <dependency>
> <groupId>org.apache.servicemix.bundles</groupId>
> <artifactId>org.apache.servicemix.bundles.jaxb-xjc</artifactId>
> <version>2.2.6_1</version>
> </dependency>
> <dependency>
> <groupId>org.apache.servicemix.bundles</groupId>
> <artifactId>org.apache.servicemix.bundles.jaxb-impl</artifactId>
> <version>2.2.6_1</version>
> </dependency>
> <dependency>
> <groupId>org.apache.servicemix.specs</groupId>
> <artifactId>org.apache.servicemix.specs.jaxb-api-2.2</artifactId>
> <version>2.2.0</version>
> </dependency>
> <dependency>
> <groupId>org.apache.servicemix.specs</groupId>
> <artifactId>org.apache.servicemix.specs.activation-api-1.1</artifactId>
> <version>2.2.0</version>
> </dependency>
> <dependency>
> <groupId>org.apache.servicemix.specs</groupId>
> <artifactId>org.apache.servicemix.specs.stax-api-1.2</artifactId>
> <version>2.2.0</version>
> </dependency>
>
>
> 2013/3/27 Charles Moulliard
> <ch007m at gmail.com
> <mailto:ch007m at gmail.com>>
>
> Can you please provide me the list
> of packages to be exported and I
> will include also poi-ooxml ?
>
>
> On Wed, Mar 27, 2013 at 3:03 PM,
> Cristiano Gavião
> <cvgaviao at gmail.com
> <mailto:cvgaviao at gmail.com>> wrote:
>
>
>
> 2013/3/27 Charles Moulliard
> <ch007m at gmail.com
> <mailto:ch007m at gmail.com>>
>
> 1) For Karaf project, we
> mostly use activator or
> Aries Blueprint
> (http://aries.apache.org/modules/blueprint.html).
> Declarative Service is
> rather new top of karaf
> (http://sully6768.blogspot.be/2012/09/scr-components-with-karaf.html)
>
>
> As a consumer you can still
> using both blueprint or
> BundleContext.getService() to
> reference the services.
>
> What I found good in both
> Blueprint and DS is that they
> ensure the component/services
> lifecycle and we could still
> use Configuration Admin with them.
>
> The problem with blueprint is
> that is not default installed
> in most distributions while DS is.
> Is DS installed by default in
> Karaf?
>
>
> 2) For poi-ooxml, we
> should use the ServiceMix
> bundle
> (http://repo1.maven.org/maven2/org/apache/servicemix/bundles/org.apache.servicemix.bundles.poi/3.9_1/)
> until they provide a OSGI
> bundle of POI.
>
>
> Unfortunately this bundle
> don't export the package
> needed. it wraps the poi.jar
> but not poi-ooxml.
> org.apache.poi.ss.usermodel.Workbook.class
> :(
>
>
>
> On Wed, Mar 27, 2013 at
> 1:53 PM, Cristiano Gavião
> <cvgaviao at gmail.com
> <mailto:cvgaviao at gmail.com>>
> wrote:
>
> I won't change that
> code for while... It
> is still be there
> until you decide to
> move it to the new one. ;)
>
> Btw, I have two questions:
>
> 1)what do you think
> about to use
> Declarative Services
> to register the
> services instead do it
> manually at activator ?
>
> 2) how are you dealing
> with poi-ooxml
> dependency in
> drools-decisiontables?
> there is no osgified
> jar for it...
>
>
>
> 2013/3/27 Charles
> Moulliard
> <ch007m at gmail.com
> <mailto:ch007m at gmail.com>>
>
> Hi Christiano,
>
> I prefer that
> first we finalize
> the OSGI bundles
> (drools-decisiontables,
> drools-jpa,
> drools-jbpm, ...)
> before changing
> pax-exam code
> which is working
> and also used by
> Apache Camel/Karaf
> projects ;-)
>
> Regards,
>
> Charles
>
>
> On Wed, Mar 27,
> 2013 at 1:44 PM,
> Cristiano Gavião
> <cvgaviao at gmail.com <mailto:cvgaviao at gmail.com>>
> wrote:
>
> Hello,
>
> I already look
> at it. The
> problem is
> that this
> tests are
> using an old
> version (2.x)
> of pax-exam
> and using a
> karaf specific
> api too.
> That version
> will be
> dropped by
> karaf team
> soon. see [1]
> and [2].
>
> Btw, Pax-exam
> was improved a
> lot in version
> 3.x.
>
> [1] -
> http://karaf.922171.n3.nabble.com/Discuss-Karaf-and-Pax-Exam-3-x-td4028074.html
> [2] -
> https://ops4j1.jira.com/browse/PAXEXAM-503
>
> regards,
>
> Cristiano
>
>
>
> 2013/3/27
> Charles
> Moulliard
> <ch007m at gmail.com
> <mailto:ch007m at gmail.com>>
>
> Christiano,
>
> Can you
> please
> have a
> look here
> as there
> is already
> a pax-exam
> test for
> karaf
> (https://github.com/droolsjbpm/droolsjbpm-integration/tree/master/drools-osgi/drools-karaf-itest)
> ?
>
> Regards,
>
> Charles
>
>
> On Tue,
> Mar 26,
> 2013 at
> 11:11 AM,
> Cristiano
> Gavião
> <cvgaviao at gmail.com
> <mailto:cvgaviao at gmail.com>>
> wrote:
>
> I'm
> creating
> a
> pax-exam
> project where
> I will
> run
> some
> test
> on top
> of
> equinox and
> felix.
>
> After
> I
> commit
> and
> push
> it
> maybe
> you
> could
> add
> karaf
> stuffs. so
> it
> could
> help
> us to
> identify
> the
> reason
> of the
> error
> you
> are
> talking about...
>
>
>
> On
> 25/03/13
> 14:19,
> Charles Moulliard
> wrote:
>> There
>> was
>> another
>> error
>> when
>> using
>> singleton
>> := true.
>>
>>
>> On
>> Mon,
>> Mar
>> 25,
>> 2013
>> at
>> 6:15
>> PM,
>> Cristiano
>> Gavião <cvgaviao at gmail.com
>> <mailto:cvgaviao at gmail.com>>
>> wrote:
>>
>> well,
>> I
>> never
>> seen
>> any
>> error
>> related
>> to singleton
>> attribute
>> at Felix
>> or Equinox.
>>
>>
>> The
>> error
>> you
>> have
>> reported
>> seems
>> to be
>> related
>> to what
>> is being
>> done
>> (and
>> not
>> being
>> undone)
>> inside
>> the
>> activator...
>>
>>
>>
>> 2013/3/25
>> Charles
>> Moulliard
>> <ch007m at gmail.com
>> <mailto:ch007m at gmail.com>>
>>
>> Not
>> at
>> all
>> but
>> using
>> singleton
>> :=
>> true
>> option
>> generates
>> error
>> when
>> we
>> do
>> a stop,
>> update
>> start
>> on
>> Apache
>> Karaf.
>>
>> We
>> never
>> used
>> that
>> property
>> to
>> generate
>> all
>> the
>> bundles
>> that
>> we
>> have
>> in
>> the
>> project
>> Karaf,
>> ServiceMix,
>> Geronimo,
>> ...
>>
>>
>> On
>> Mon,
>> Mar
>> 25,
>> 2013
>> at
>> 4:34
>> PM,
>> Cristiano
>> Gavião
>> <cvgaviao at gmail.com
>> <mailto:cvgaviao at gmail.com>>
>> wrote:
>>
>> Charles,
>>
>>
>> I saw
>> that
>> you
>> removed
>> singleton:=true
>> in
>> your
>> commit.
>> This
>> is
>> because
>> do
>> you
>> plan
>> to
>> have
>> more
>> than
>> one
>> version
>> of
>> drools/jbpm
>> running
>> at
>> same
>> time?
>>
>> regards,
>>
>> Cristiano
>>
>>
>>
>> 2013/3/25
>> Cristiano
>> Gavião
>> <cvgaviao at gmail.com
>> <mailto:cvgaviao at gmail.com>>
>>
>> Charles,
>>
>> I already
>> changed
>> the
>> manifest
>> generation
>> of
>> kie
>> and
>> other
>> drools
>> modules.
>> I created
>> some
>> pull
>> requests
>> for
>> such
>> changes.
>>
>> Next
>> thing
>> that
>> I planned
>> to
>> do
>> this
>> week(Wed)
>> was
>> to
>> review
>> each
>> Activator,
>> I think
>> we
>> could
>> improve
>> it...
>>
>>
>> regards,
>>
>> Cristiano
>>
>>
>>
>> On
>> 25/03/13
>> 04:52,
>> Charles
>> Moulliard
>> wrote:
>>> Hi,
>>>
>>>
>>> The org.kie.api.osgi.Activator
>>> class
>>> of
>>> kie
>>> project needs
>>> the
>>> class
>>> ServiceRegistryImpl
>>> (&
>>> Interface
>>> ServiceRegistry
>>> of
>>> kie
>>> internal)
>>> to
>>> register
>>> an
>>> OSGI
>>> Service
>>> (Interface)
>>>
>>> this.serviceRegistry
>>> = bc.registerService(
>>> ServiceRegistry.class.getName(),
>>> ServiceRegistryImpl.getInstance(),
>>> new
>>> Hashtable()
>>> );
>>>
>>> but
>>> the
>>> maven
>>> module
>>> kie
>>> api
>>> does
>>> not
>>> have
>>> a dependency
>>> with
>>> kie
>>> internal
>>> as
>>> the
>>> class
>>> ServiceRegistry
>>> & ServiceRegistryImpl
>>> are
>>> part
>>> of
>>> the
>>> module
>>> kie
>>> internal
>>> & package
>>> org.kie.internal.utils
>>>
>>> Questions
>>> :
>>> - What
>>> are
>>> the
>>> plans
>>> regarding
>>> to
>>> the
>>> Activator
>>> of
>>> Kie
>>> api
>>> bundle
>>> - what
>>> does
>>> it
>>> want
>>> to
>>> do
>>> ?
>>> - Can
>>> we
>>> add
>>> the
>>> missing dependency
>>> in
>>> kie
>>> api
>>> project
>>> ?
>>>
>>> Regards,
>>> --
>>>
>>> Charles
>>> Moulliard
>>> Apache
>>> Committer
>>> / Sr.
>>> Enterprise
>>> Architect
>>> (RedHat)
>>> Twitter
>>> : @cmoulliard
>>> | Blog
>>> : http://cmoulliard.blogspot.com
>>>
>>>
>>>
>>> _______________________________________________
>>> rules-dev mailing list
>>> rules-dev at lists.jboss.org <mailto:rules-dev at lists.jboss.org>
>>> https://lists.jboss.org/mailman/listinfo/rules-dev
>>
>>
>>
>>
>> --
>>
>> "Tudo
>> vale
>> a pena
>> se
>> a alma
>> não
>> é pequena..."
>>
>> _______________________________________________
>> rules-dev
>> mailing
>> list
>> rules-dev at lists.jboss.org
>> <mailto:rules-dev at lists.jboss.org>
>> https://lists.jboss.org/mailman/listinfo/rules-dev
>>
>>
>>
>>
>> --
>>
>> Charles
>> Moulliard
>> Apache
>> Committer
>> / Sr.
>> Enterprise
>> Architect
>> (RedHat)
>> Twitter
>> : @cmoulliard
>> | Blog
>> : http://cmoulliard.blogspot.com
>>
>>
>> _______________________________________________
>> rules-dev
>> mailing
>> list
>> rules-dev at lists.jboss.org
>> <mailto:rules-dev at lists.jboss.org>
>> https://lists.jboss.org/mailman/listinfo/rules-dev
>>
>>
>>
>> _______________________________________________
>> rules-dev
>> mailing
>> list
>> rules-dev at lists.jboss.org
>> <mailto:rules-dev at lists.jboss.org>
>> https://lists.jboss.org/mailman/listinfo/rules-dev
>>
>>
>>
>>
>> --
>> Charles
>> Moulliard
>> Apache Committer
>> / Sr.
>> Enterprise
>> Architect
>> (RedHat)
>> Twitter
>> :
>> @cmoulliard
>> | Blog :
>> http://cmoulliard.blogspot.com
>>
>>
>>
>> _______________________________________________
>> rules-dev mailing list
>> rules-dev at lists.jboss.org <mailto:rules-dev at lists.jboss.org>
>> https://lists.jboss.org/mailman/listinfo/rules-dev
>
>
> _______________________________________________
> rules-dev
> mailing list
> rules-dev at lists.jboss.org
> <mailto:rules-dev at lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/rules-dev
>
>
>
>
> --
> Charles
> Moulliard
> Apache
> Committer
> / Sr.
> Enterprise
> Architect
> (RedHat)
> Twitter :
> @cmoulliard | Blog
> :
> http://cmoulliard.blogspot.com
>
>
> _______________________________________________
> rules-dev
> mailing list
> rules-dev at lists.jboss.org
> <mailto:rules-dev at lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/rules-dev
>
>
>
>
> --
> "Tudo vale a
> pena se a alma
> não é pequena..."
>
> _______________________________________________
> rules-dev
> mailing list
> rules-dev at lists.jboss.org
> <mailto:rules-dev at lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/rules-dev
>
>
>
>
> --
> Charles Moulliard
> Apache Committer /
> Sr. Enterprise
> Architect (RedHat)
> Twitter :
> @cmoulliard | Blog
> :
> http://cmoulliard.blogspot.com
>
>
> _______________________________________________
> rules-dev mailing list
> rules-dev at lists.jboss.org
> <mailto:rules-dev at lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/rules-dev
>
>
>
>
> --
> "Tudo vale a pena se a
> alma não é pequena..."
>
> _______________________________________________
> rules-dev mailing list
> rules-dev at lists.jboss.org
> <mailto:rules-dev at lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/rules-dev
>
>
>
>
> --
> Charles Moulliard
> Apache Committer / Sr.
> Enterprise Architect (RedHat)
> Twitter : @cmoulliard
> | Blog :
> http://cmoulliard.blogspot.com
>
>
> _______________________________________________
> rules-dev mailing list
> rules-dev at lists.jboss.org
> <mailto:rules-dev at lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/rules-dev
>
>
>
>
> --
> "Tudo vale a pena se a alma
> não é pequena..."
>
> _______________________________________________
> rules-dev mailing list
> rules-dev at lists.jboss.org
> <mailto:rules-dev at lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/rules-dev
>
>
>
>
> --
> Charles Moulliard
> Apache Committer / Sr. Enterprise
> Architect (RedHat)
> Twitter : @cmoulliard | Blog :
> http://cmoulliard.blogspot.com
>
>
> _______________________________________________
> rules-dev mailing list
> rules-dev at lists.jboss.org
> <mailto:rules-dev at lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/rules-dev
>
>
>
>
> --
> "Tudo vale a pena se a alma não é
> pequena..."
>
> _______________________________________________
> rules-dev mailing list
> rules-dev at lists.jboss.org
> <mailto:rules-dev at lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/rules-dev
>
>
>
>
> --
> Charles Moulliard
> Apache Committer / Sr. Enterprise
> Architect (RedHat)
> Twitter : @cmoulliard | Blog :
> http://cmoulliard.blogspot.com
>
>
> _______________________________________________
> rules-dev mailing list
> rules-dev at lists.jboss.org
> <mailto:rules-dev at lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/rules-dev
>
>
>
>
> --
> "Tudo vale a pena se a alma não é pequena..."
>
> _______________________________________________
> rules-dev mailing list
> rules-dev at lists.jboss.org
> <mailto:rules-dev at lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/rules-dev
>
>
>
>
> --
> Charles Moulliard
> Apache Committer / Sr. Enterprise Architect (RedHat)
> Twitter : @cmoulliard | Blog :
> http://cmoulliard.blogspot.com
>
>
>
>
> --
> Charles Moulliard
> Apache Committer / Sr. Enterprise Architect (RedHat)
> Twitter : @cmoulliard | Blog :
> http://cmoulliard.blogspot.com
>
>
> _______________________________________________
> rules-dev mailing list
> rules-dev at lists.jboss.org
> <mailto:rules-dev at lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/rules-dev
>
>
>
>
> --
> "Tudo vale a pena se a alma não é pequena..."
>
> _______________________________________________
> rules-dev mailing list
> rules-dev at lists.jboss.org <mailto:rules-dev at lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/rules-dev
>
>
>
>
> --
> Charles Moulliard
> Apache Committer / Sr. Enterprise Architect (RedHat)
> Twitter : @cmoulliard | Blog : http://cmoulliard.blogspot.com
>
>
> _______________________________________________
> rules-dev mailing list
> rules-dev at lists.jboss.org <mailto:rules-dev at lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/rules-dev
>
>
>
>
> --
> "Tudo vale a pena se a alma não é pequena..."
>
> _______________________________________________
> rules-dev mailing list
> rules-dev at lists.jboss.org <mailto:rules-dev at lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/rules-dev
>
>
>
>
> --
> Charles Moulliard
> Apache Committer / Sr. Enterprise Architect (RedHat)
> Twitter : @cmoulliard | Blog : http://cmoulliard.blogspot.com
>
>
>
> _______________________________________________
> rules-dev mailing list
> rules-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-dev/attachments/20130328/2a113f4b/attachment-0001.html
More information about the rules-dev
mailing list