[JBoss JIRA] (DROOLS-242) Add out-of-the-box possibility to dump DRL created from decision tables
by Petr Široký (JIRA)
[ https://issues.jboss.org/browse/DROOLS-242?page=com.atlassian.jira.plugin... ]
Petr Široký updated DROOLS-242:
-------------------------------
Description:
To get the DRL generated from decision table one has to currently use following code:
{code}
File dtable = new File("../resources/dtable.xls");
KieResources kieResources = KieServices.Factory.get().getResources();
Resource dtableResource = kieResources.newFileSystemResource(dtable);
SpreadsheetCompiler compiler = new SpreadsheetCompiler();
String drl = compiler.compile(dtableResource.getInputStream(), InputType.XLS);
{code}
It would be nice to have this functionality out-of-the-box, similarly like 'drools.dump.dir' which is used to dump the Java classes generated from DRL.
Looking at how the options are being used I see basically three possible solutions here (I maybe missing some other options):
- get the value of `drools.dump.dir` manually using the ChainedProperties.
- add this config. option into DecisionTableConfiguration. This would prevent the backwards comptibility issues when changing the DecisionTableProvider interface, but I am not entirely sure it is the right place for this kind of config.
- pass the entire KnowledgeBuilderConfiguration object into DecisionTableProvider.loadFromInputStream(). This seems like the best option from the clean-code point of view, but it would mean that the DecisionTableProvider interface would have to altered.
was:
To get the DRL generated from decision table one has to currently use following code:
{code}
File dtable = new File("../resources/dtable.xls");
KieResources kieResources = KieServices.Factory.get().getResources();
Resource dtableResource = kieResources.newFileSystemResource(dtable);
SpreadsheetCompiler compiler = new SpreadsheetCompiler();
String drl = compiler.compile(dtableResource.getInputStream(), InputType.XLS);
{code}
It would be nice to have this functionality out-of-the-box, similarly like 'drools.dump.dir' which is used to dump the Java classes generated from DRL.
Looking at how the options are being used I see basically three possible solutions here (I maybe missing some other options):
- get the value of `drools.dump.dir` manually using the ChainedProperties. I think this is not good idea as it is duplicating the code.
- add this config. option into DecisionTableConfiguration. This would prevent the backwards comptibility issues when changing the DecisionTableProvider interface, but I am not entirely sure it is the right place for this kind of config.
- pass the entire KnowledgeBuilderConfiguration object into DecisionTableProvider.loadFromInputStream(). This seems like the best option from the clean-code point of view, but it would mean that the DecisionTableProvider interface would have to altered.
> Add out-of-the-box possibility to dump DRL created from decision tables
> ------------------------------------------------------------------------
>
> Key: DROOLS-242
> URL: https://issues.jboss.org/browse/DROOLS-242
> Project: Drools
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Affects Versions: 6.0.0.CR2
> Reporter: Petr Široký
> Assignee: Petr Široký
>
> To get the DRL generated from decision table one has to currently use following code:
> {code}
> File dtable = new File("../resources/dtable.xls");
> KieResources kieResources = KieServices.Factory.get().getResources();
> Resource dtableResource = kieResources.newFileSystemResource(dtable);
> SpreadsheetCompiler compiler = new SpreadsheetCompiler();
> String drl = compiler.compile(dtableResource.getInputStream(), InputType.XLS);
> {code}
> It would be nice to have this functionality out-of-the-box, similarly like 'drools.dump.dir' which is used to dump the Java classes generated from DRL.
> Looking at how the options are being used I see basically three possible solutions here (I maybe missing some other options):
> - get the value of `drools.dump.dir` manually using the ChainedProperties.
> - add this config. option into DecisionTableConfiguration. This would prevent the backwards comptibility issues when changing the DecisionTableProvider interface, but I am not entirely sure it is the right place for this kind of config.
> - pass the entire KnowledgeBuilderConfiguration object into DecisionTableProvider.loadFromInputStream(). This seems like the best option from the clean-code point of view, but it would mean that the DecisionTableProvider interface would have to altered.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 8 months
[JBoss JIRA] (WFLY-3455) JBAS014544: No EJB found with interface of type
by Enrique González Martínez (JIRA)
[ https://issues.jboss.org/browse/WFLY-3455?page=com.atlassian.jira.plugin.... ]
Enrique González Martínez reassigned WFLY-3455:
-----------------------------------------------
Assignee: Enrique González Martínez (was: David Lloyd)
> JBAS014544: No EJB found with interface of type
> -----------------------------------------------
>
> Key: WFLY-3455
> URL: https://issues.jboss.org/browse/WFLY-3455
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: EJB
> Affects Versions: 8.1.0.Final
> Environment: Ubuntu 14.04 LTS: Linux blackbox 3.13.0-27-generic #50-Ubuntu SMP Thu May 15 18:06:16 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
> Java: java version "1.7.0_60"
> Java(TM) SE Runtime Environment (build 1.7.0_60-b19)
> Java HotSpot(TM) 64-Bit Server VM (build 24.60-b09, mixed mode)
> Reporter: Gregor Kovač
> Assignee: Enrique González Martínez
> Attachments: WildflyTest.zip
>
>
> I have an EAR with an Stateless EJB that implements a Remote interface.
> In another application (WAR) I access his EJB like this: @EJB(beanInterface=RemoteBean.class) RemoteBean bean; When I deploy EAR I can see the JNDI name of the EJB, but when I deploy WAR I get error: JBAS014544: No EJB found with interface of type .....
> I have attached an example application.
> You can build it with Maven, deploy and see that error.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 8 months
[JBoss JIRA] (DROOLS-483) Repeated class loading of absent services
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-483?page=com.atlassian.jira.plugin... ]
Mario Fusco commented on DROOLS-483:
------------------------------------
Hi and sorry for the huge delay in dealing with this.
The improvement you're suggesting is ok in principle, but as you anticipated, it doesn't work well in an OSGi environment and this is why we didn't merge your pull request yet.
I believe this further issue could be fixable by making our OSGi Activators to recognize this situation and deal with it, but this needs a bit of time to be done correctly.
That is why we chose the safest (and slowest) path for now. Anyway I think that what you're proposing makes completely sense and I'll try to extend what you did to make it work also on OSGi asap. You don't need to rebase your PR, I'll do it when I'll have time to work on it.
Thanks for your help and patience,
Mario
> Repeated class loading of absent services
> -----------------------------------------
>
> Key: DROOLS-483
> URL: https://issues.jboss.org/browse/DROOLS-483
> Project: Drools
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Affects Versions: 5.5.0.Final, 5.6.0.Final, 6.0.1.Final, 6.1.0.Final
> Reporter: Frank Pavageau
> Assignee: Mark Proctor
>
> h3. Context
> The {{ServiceRegistry}} is used to get the providers for a number of services, several of which don't have an implementation in a Drools artifact but in jBPM, for example.
> Those providers include:
> - {{ProcessBuilderFactoryService}} (implemented by {{org.jbpm.process.builder.ProcessBuilderFactoryServiceImpl}}) called in the constructor of {{KnowledgeBuilderImpl}} through {{ProcessBuilderFactory}}
> - {{ProcessRuntimeFactoryService}} (implemented by {{org.jbpm.process.instance.ProcessRuntimeFactoryServiceImpl}}) called in the constructor of {{StatefulKnowledgeSessionImpl}} through {{ProcessRuntimeFactory}}, so this one especially can be called frequently
> Both {{ProcessBuilderFactory}} and {{ProcessRuntimeFactory}} use the fact that the static field containing the service is not null to know they've been initialized, which means they'll continuously try to load the class if it's not actually in the classpath.
> h3. Enhancement
> If this behavior is not needed for the OSGi support, I'd like to see the initialization test use a boolean field to only try loading the class once. And if it is needed for OSGi, maybe the behavior could be configured.
> h3. Rationale
> Attempting to load a class is a costly operation, especially in the context of a web application running on Tomcat. I've pushed a [JMH|http://openjdk.java.net/projects/code-tools/jmh/] benchmark on [Github|https://github.com/fpavageau/bench-for-name] to illustrate the point (see the [README.md|https://github.com/fpavageau/bench-for-name#results]): a failed call to Class.forName() takes ~22 microseconds using the context classloader of the benchmark (i.e. probably the system classloader), ~75 microseconds using a Tomcat classloader configured ({{WebappClassLoader}}) with 100 empty jars (that need to be scanned for the missing class). Combined with the fact that {{Class.forName()}} calls {{ClassLoader.loadClass()}} which in the case of {{WebappClassLoader}} is a synchronized method, it becomes a nice bottleneck in a high-traffic application creating {{StatefulKnowledgeSessions}} extensively, because of the lock contention.
> Another side-effect of this flow is that {{ServiceRegistryImpl}} continuously gets a {{ClassNotFoundException}}, then throws an {{IllegalArgumentException}}, which means 2 stacktraces to fill for each call, and that is also an [expensive operation|http://shipilev.net/blog/2014/exceptional-performance/] when throwing exceptions is not exceptional and becomes the regular control flow.
> I've been able to grab stacktraces from Drools to {{WebappClassLoader.loadClass()}} when doing thread dumps on an application with sufficient load, so it's frequent enough that it can be observed by sampling and not just a rhetorical question.
> I could create a pull request, but I'd like to get some feedback first.
> Note: most calls to {{ServiceRegistry.get()}} use the same pattern, but the 2 I have picked out are the ones which happen the most frequently for my use case.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 8 months
[JBoss JIRA] (WFLY-3801) Wrong Transaction behaviour for EJBs if JTS is enabled
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-3801?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration updated WFLY-3801:
------------------------------------------
Bugzilla Update: Perform
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1136054
> Wrong Transaction behaviour for EJBs if JTS is enabled
> ------------------------------------------------------
>
> Key: WFLY-3801
> URL: https://issues.jboss.org/browse/WFLY-3801
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: EJB, Transactions
> Affects Versions: 8.1.0.Final
> Environment: standalone-full profile with JTS enabled
> Reporter: Wolf-Dieter Fink
> Assignee: David Lloyd
> Attachments: enableJTS.cli, reproducer.zip, server.log
>
>
> If JTS is enabled the invocation of EJB's might show a arjuna warning for each method invocation:
> WARN [com.arjuna.ats.jts] (RequestProcessor-5) ARJUNA022261: ServerTopLevelAction detected that the transaction was inactive
> This is only the case if other resources are involved, i.e. a DB via JPA.
> If a simple bean is used (like ejb-remote quickstart) this warning is not shown.
> It looks like the transaction is local commited but in case of a SFSB @Remove method the result is a " WFLYEE0006: Failed to destroy component instance Instance of SFTestBean" and the lifecycle method @PreDestroy is not invoked.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 8 months
[JBoss JIRA] (WFLY-3801) Wrong Transaction behaviour for EJBs if JTS is enabled
by Wolf-Dieter Fink (JIRA)
[ https://issues.jboss.org/browse/WFLY-3801?page=com.atlassian.jira.plugin.... ]
Wolf-Dieter Fink updated WFLY-3801:
-----------------------------------
Attachment: reproducer.zip
mvn project for reproduce
> Wrong Transaction behaviour for EJBs if JTS is enabled
> ------------------------------------------------------
>
> Key: WFLY-3801
> URL: https://issues.jboss.org/browse/WFLY-3801
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: EJB, Transactions
> Affects Versions: 8.1.0.Final
> Environment: standalone-full profile with JTS enabled
> Reporter: Wolf-Dieter Fink
> Assignee: David Lloyd
> Attachments: enableJTS.cli, reproducer.zip, server.log
>
>
> If JTS is enabled the invocation of EJB's might show a arjuna warning for each method invocation:
> WARN [com.arjuna.ats.jts] (RequestProcessor-5) ARJUNA022261: ServerTopLevelAction detected that the transaction was inactive
> This is only the case if other resources are involved, i.e. a DB via JPA.
> If a simple bean is used (like ejb-remote quickstart) this warning is not shown.
> It looks like the transaction is local commited but in case of a SFSB @Remove method the result is a " WFLYEE0006: Failed to destroy component instance Instance of SFTestBean" and the lifecycle method @PreDestroy is not invoked.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 8 months
[JBoss JIRA] (WFLY-3801) Wrong Transaction behaviour for EJBs if JTS is enabled
by Wolf-Dieter Fink (JIRA)
[ https://issues.jboss.org/browse/WFLY-3801?page=com.atlassian.jira.plugin.... ]
Wolf-Dieter Fink updated WFLY-3801:
-----------------------------------
Attachment: enableJTS.cli
> Wrong Transaction behaviour for EJBs if JTS is enabled
> ------------------------------------------------------
>
> Key: WFLY-3801
> URL: https://issues.jboss.org/browse/WFLY-3801
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: EJB, Transactions
> Affects Versions: 8.1.0.Final
> Environment: standalone-full profile with JTS enabled
> Reporter: Wolf-Dieter Fink
> Assignee: David Lloyd
> Attachments: enableJTS.cli, server.log
>
>
> If JTS is enabled the invocation of EJB's might show a arjuna warning for each method invocation:
> WARN [com.arjuna.ats.jts] (RequestProcessor-5) ARJUNA022261: ServerTopLevelAction detected that the transaction was inactive
> This is only the case if other resources are involved, i.e. a DB via JPA.
> If a simple bean is used (like ejb-remote quickstart) this warning is not shown.
> It looks like the transaction is local commited but in case of a SFSB @Remove method the result is a " WFLYEE0006: Failed to destroy component instance Instance of SFTestBean" and the lifecycle method @PreDestroy is not invoked.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 8 months
[JBoss JIRA] (WFLY-3801) Wrong Transaction behaviour for EJBs if JTS is enabled
by Wolf-Dieter Fink (JIRA)
[ https://issues.jboss.org/browse/WFLY-3801?page=com.atlassian.jira.plugin.... ]
Wolf-Dieter Fink updated WFLY-3801:
-----------------------------------
Attachment: server.log
> Wrong Transaction behaviour for EJBs if JTS is enabled
> ------------------------------------------------------
>
> Key: WFLY-3801
> URL: https://issues.jboss.org/browse/WFLY-3801
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: EJB, Transactions
> Affects Versions: 8.1.0.Final
> Environment: standalone-full profile with JTS enabled
> Reporter: Wolf-Dieter Fink
> Assignee: David Lloyd
> Attachments: server.log
>
>
> If JTS is enabled the invocation of EJB's might show a arjuna warning for each method invocation:
> WARN [com.arjuna.ats.jts] (RequestProcessor-5) ARJUNA022261: ServerTopLevelAction detected that the transaction was inactive
> This is only the case if other resources are involved, i.e. a DB via JPA.
> If a simple bean is used (like ejb-remote quickstart) this warning is not shown.
> It looks like the transaction is local commited but in case of a SFSB @Remove method the result is a " WFLYEE0006: Failed to destroy component instance Instance of SFTestBean" and the lifecycle method @PreDestroy is not invoked.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 8 months
[JBoss JIRA] (WFLY-3801) Wrong Transaction behaviour for EJBs if JTS is enabled
by Wolf-Dieter Fink (JIRA)
Wolf-Dieter Fink created WFLY-3801:
--------------------------------------
Summary: Wrong Transaction behaviour for EJBs if JTS is enabled
Key: WFLY-3801
URL: https://issues.jboss.org/browse/WFLY-3801
Project: WildFly
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: EJB, Transactions
Affects Versions: 8.1.0.Final
Environment: standalone-full profile with JTS enabled
Reporter: Wolf-Dieter Fink
Assignee: David Lloyd
If JTS is enabled the invocation of EJB's might show a arjuna warning for each method invocation:
WARN [com.arjuna.ats.jts] (RequestProcessor-5) ARJUNA022261: ServerTopLevelAction detected that the transaction was inactive
This is only the case if other resources are involved, i.e. a DB via JPA.
If a simple bean is used (like ejb-remote quickstart) this warning is not shown.
It looks like the transaction is local commited but in case of a SFSB @Remove method the result is a " WFLYEE0006: Failed to destroy component instance Instance of SFTestBean" and the lifecycle method @PreDestroy is not invoked.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 8 months
[JBoss JIRA] (DROOLS-586) Drools doesn't calculate maximum expiration time properly
by Davide Sottara (JIRA)
[ https://issues.jboss.org/browse/DROOLS-586?page=com.atlassian.jira.plugin... ]
Davide Sottara updated DROOLS-586:
----------------------------------
Fix Version/s: (was: 6.1.0.Final)
Priority: Critical (was: Major)
Assignee: Edson Tirelli (was: Mark Proctor)
Affects Version/s: 6.2.0.Beta1
6.1.0.CR2
> Drools doesn't calculate maximum expiration time properly
> ---------------------------------------------------------
>
> Key: DROOLS-586
> URL: https://issues.jboss.org/browse/DROOLS-586
> Project: Drools
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 6.1.0.CR2, 6.2.0.Beta1
> Environment: Linux, Java SE 1.7
> Reporter: kairat kushaev
> Assignee: Edson Tirelli
> Priority: Critical
>
> Hello guys,
> we found some contradiction between actual Drools behavior,
> We use the following Rule:
> import drools.test.Event;
> dialect "mvel"
> declare Event
> @role(event)
> @expires(10s)
> end
> rule "ExampleRule"
> when
> ( $a : Event(name == "event a") ) and
> ( $b : Event((name == "event b") && (this after [1ms, 15s] $a)) )
> then
> System.out.println("bingo!");
> end
> In the code above Drools should wait for the second event when the first event came. But it turns out that Drools doesn't wait for the second event because of @expires tag. The value in this tag is less than this after value.
> According to documentation
> "The engine will make this analysis for the whole rulebase and find the offset for every event type. Whenever an implicit expiration offset clashes with the explicit expiration offset, then engine will use the greater of the two."
> but it is not calculating maximal expiration offset. Also we are using STREAM mode.
> Could you please clarify the situation?
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 8 months
[JBoss JIRA] (DROOLS-586) Drools doesn't calculate maximum expiration time properly
by Davide Sottara (JIRA)
[ https://issues.jboss.org/browse/DROOLS-586?page=com.atlassian.jira.plugin... ]
Davide Sottara commented on DROOLS-586:
---------------------------------------
It's confirmed, we are investigating
> Drools doesn't calculate maximum expiration time properly
> ---------------------------------------------------------
>
> Key: DROOLS-586
> URL: https://issues.jboss.org/browse/DROOLS-586
> Project: Drools
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Environment: Linux, Java SE 1.7
> Reporter: kairat kushaev
> Assignee: Mark Proctor
> Fix For: 6.1.0.Final
>
>
> Hello guys,
> we found some contradiction between actual Drools behavior,
> We use the following Rule:
> import drools.test.Event;
> dialect "mvel"
> declare Event
> @role(event)
> @expires(10s)
> end
> rule "ExampleRule"
> when
> ( $a : Event(name == "event a") ) and
> ( $b : Event((name == "event b") && (this after [1ms, 15s] $a)) )
> then
> System.out.println("bingo!");
> end
> In the code above Drools should wait for the second event when the first event came. But it turns out that Drools doesn't wait for the second event because of @expires tag. The value in this tag is less than this after value.
> According to documentation
> "The engine will make this analysis for the whole rulebase and find the offset for every event type. Whenever an implicit expiration offset clashes with the explicit expiration offset, then engine will use the greater of the two."
> but it is not calculating maximal expiration offset. Also we are using STREAM mode.
> Could you please clarify the situation?
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 8 months