[JBoss JIRA] (DROOLS-588) Constraints with same expression causes a node sharing even if they shouldn't
by Mario Fusco (JIRA)
Mario Fusco created DROOLS-588:
----------------------------------
Summary: Constraints with same expression causes a node sharing even if they shouldn't
Key: DROOLS-588
URL: https://issues.jboss.org/browse/DROOLS-588
Project: Drools
Issue Type: Bug
Security Level: Public (Everyone can see)
Reporter: Mario Fusco
Assignee: Mario Fusco
Reoroducer:
{code}
@Test
public void testWrongNodeSharing() {
String drl1 =
"package test1\n" +
"import static " + Misc2Test.class.getCanonicalName() + ".parseInt;\n" +
"global java.util.List list;\n" +
"rule R when\n" +
" String( parseInt(this) == 0 )\n" +
"then\n" +
" list.add(\"OK\");\n" +
"end";
String drl2 =
"package test2\n" +
"import static java.lang.Integer.parseInt;\n" +
"global java.util.List list;\n" +
"rule R when\n" +
" String( parseInt(this) == 0 )\n" +
"then\n" +
" list.add(\"NOT OK\");\n" +
"end";
KieHelper helper = new KieHelper();
helper.addContent( drl1, ResourceType.DRL );
helper.addContent( drl2, ResourceType.DRL );
KieSession kieSession = helper.build().newKieSession();
List list = new ArrayList();
kieSession.setGlobal( "list", list );
kieSession.insert( "3" );
kieSession.fireAllRules();
assertEquals( 1, list.size() );
assertEquals( "OK", list.get(0) );
}
public static int parseInt(String s) {
return 0;
}
{code}
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 10 months
[JBoss JIRA] (WFLY-1264) Create a test to get notifications when hosts join/leave a domain
by Panagiotis Sotiropoulos (JIRA)
[ https://issues.jboss.org/browse/WFLY-1264?page=com.atlassian.jira.plugin.... ]
Panagiotis Sotiropoulos commented on WFLY-1264:
-----------------------------------------------
Arquilllian test created to test monitoring when hosts join/leave a domain using ManagementClient. This functionality is not yet supported by ManagementClient.
> Create a test to get notifications when hosts join/leave a domain
> -----------------------------------------------------------------
>
> Key: WFLY-1264
> URL: https://issues.jboss.org/browse/WFLY-1264
> Project: WildFly
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Components: Test Suite
> Reporter: Andrew Rubinger
> Assignee: Panagiotis Sotiropoulos
>
> Should be implemented by using the mechanism provided by AS7-1415, injection of the ManagementClient into the test. Verify this is working to fulfill the feature request from QE to get notifications on hosts joining/leaving the Domain. May depend upon the presence of an AS7 Domain Controller Container.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 10 months
[JBoss JIRA] (WFLY-3492) JSSE configuration in security domain wrongly acceptes empty parameters
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFLY-3492?page=com.atlassian.jira.plugin.... ]
Kabir Khan edited comment on WFLY-3492 at 9/1/14 11:57 AM:
-----------------------------------------------------------
Looking a bit more into this, if I use:
{code}
/subsystem=security/security-domain=trust-domain/jsse=classic:add(keystore={password=1234test,url=/Users/kabir/sourcecontrol/wildfly/git/wildfly/security/subsystem/src/test/resources/clientcert.jks})
{code}
e.g. truststore *=* {...} the operation becomes:
{code}
{
"address" => [
("subsystem" => "security"),
("security-domain" => "trust-domain"),
("jsse" => "classic")
],
"operation" => "add",
"keystore" => {
"password" => "1234test",
"url" => "/Users/kabir/sourcecontrol/wildfly/git/wildfly/security/subsystem/src/test/resources/clientcert.jks"
},
---SNIP---
}
{code}
However, if I do
{code}
/subsystem=security/security-domain=trust-domain/jsse=classic:add(keystore=>{password=1234test,url=/Users/kabir/sourcecontrol/wildfly/git/wildfly/security/subsystem/src/test/resources/clientcert.jks})
{code}
e.g. truststore *=>* {...} the operation becomes:
{code}
{
"address" => [
("subsystem" => "security"),
("security-domain" => "trust-domain"),
("jsse" => "classic")
],
"operation" => "add",
"keystore" => ">",
--- SNIP ----
}
{code}
So perhaps rather than a validation error, this is a CLI parsing problem in general? It seems that *=>* should get rejected.
[~loubyansky] [~brian.stansberry] What do you think?
was (Author: kabirkhan):
Looking a bit more into this, if I use:
{code}
/subsystem=security/security-domain=trust-domain/jsse=classic:add(keystore={password=1234test,url=/Users/kabir/sourcecontrol/wildfly/git/wildfly/security/subsystem/src/test/resources/clientcert.jks})
{code}
e.g. truststore*=*{...} the operation becomes:
{code}
{
"address" => [
("subsystem" => "security"),
("security-domain" => "trust-domain"),
("jsse" => "classic")
],
"operation" => "add",
"keystore" => {
"password" => "1234test",
"url" => "/Users/kabir/sourcecontrol/wildfly/git/wildfly/security/subsystem/src/test/resources/clientcert.jks"
},
---SNIP---
}
{code}
However, if I do
{code}
/subsystem=security/security-domain=trust-domain/jsse=classic:add(keystore=>{password=1234test,url=/Users/kabir/sourcecontrol/wildfly/git/wildfly/security/subsystem/src/test/resources/clientcert.jks})
{code}
e.g. truststore*=>*{...} the operation becomes:
{code}
{
"address" => [
("subsystem" => "security"),
("security-domain" => "trust-domain"),
("jsse" => "classic")
],
"operation" => "add",
"keystore" => ">",
--- SNIP ----
}
{code}
So perhaps rather than a validation error, this is a CLI parsing problem in general? It seems that *=>* should get rejected.
[~loubyansky] [~brian.stansberry] What do you think?
> JSSE configuration in security domain wrongly acceptes empty parameters
> -----------------------------------------------------------------------
>
> Key: WFLY-3492
> URL: https://issues.jboss.org/browse/WFLY-3492
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Domain Management
> Affects Versions: 8.1.0.Final
> Reporter: Chao Wang
> Assignee: Chao Wang
>
> Description from https://bugzilla.redhat.com/show_bug.cgi?id=1080069:
> {noformat}
> When adding a jsse configuration in security domain through CLI, it's not persisted correctly.
> Steps to reproduce:
> * Run CLI (./jboss-cli.sh -c) and use this commands to configure new security domain:
> /subsystem=security/security-domain=trust-domain:add
> /subsystem=security/security-domain=trust-domain/jsse=classic:add(truststore=>{password=1234test,url=/home/jcacek/projects/ocsp-check/build/trusted-clients.jks})
> reload
> * check standalone.xml, where should be sth. like
> <security-domain name="trust-domain">
> <jsse truststore-password="1234test" truststore-url="/home/jcacek/projects/ocsp-check/build/trusted-clients.jks"/>
> </security-domain>
> But there is:
> <security-domain name="trust-domain">
> <jsse/>
> </security-domain>
> {noformat}
> {noformat}
> I had a mistake in the second command, it should be:
> /subsystem=security/security-domain=trust-domain/jsse=classic:add(truststore={password=>1234test,url=>/home/jcacek/projects/ocsp-check/build/trusted-clients.jks})
> Then it works.
> Nevertheless it's probably still a bug, when the original command returns:
> {
> "outcome" => "success",
> "response-headers" => {
> "operation-requires-reload" => true,
> "process-state" => "reload-required"
> }
> }
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 10 months
[JBoss JIRA] (WFLY-3492) JSSE configuration in security domain wrongly acceptes empty parameters
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFLY-3492?page=com.atlassian.jira.plugin.... ]
Kabir Khan commented on WFLY-3492:
----------------------------------
Looking a bit more into this, if I use:
{code}
/subsystem=security/security-domain=trust-domain/jsse=classic:add(keystore={password=1234test,url=/Users/kabir/sourcecontrol/wildfly/git/wildfly/security/subsystem/src/test/resources/clientcert.jks})
{code}
e.g. truststore*=*{...} the operation becomes:
{code}
{
"address" => [
("subsystem" => "security"),
("security-domain" => "trust-domain"),
("jsse" => "classic")
],
"operation" => "add",
"keystore" => {
"password" => "1234test",
"url" => "/Users/kabir/sourcecontrol/wildfly/git/wildfly/security/subsystem/src/test/resources/clientcert.jks"
},
---SNIP---
}
{code}
However, if I do
{code}
/subsystem=security/security-domain=trust-domain/jsse=classic:add(keystore=>{password=1234test,url=/Users/kabir/sourcecontrol/wildfly/git/wildfly/security/subsystem/src/test/resources/clientcert.jks})
{code}
e.g. truststore*=>*{...} the operation becomes:
{code}
{
"address" => [
("subsystem" => "security"),
("security-domain" => "trust-domain"),
("jsse" => "classic")
],
"operation" => "add",
"keystore" => ">",
--- SNIP ----
}
{code}
So perhaps rather than a validation error, this is a CLI parsing problem in general? It seems that *=>* should get rejected.
[~loubyansky] [~brian.stansberry] What do you think?
> JSSE configuration in security domain wrongly acceptes empty parameters
> -----------------------------------------------------------------------
>
> Key: WFLY-3492
> URL: https://issues.jboss.org/browse/WFLY-3492
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Domain Management
> Affects Versions: 8.1.0.Final
> Reporter: Chao Wang
> Assignee: Chao Wang
>
> Description from https://bugzilla.redhat.com/show_bug.cgi?id=1080069:
> {noformat}
> When adding a jsse configuration in security domain through CLI, it's not persisted correctly.
> Steps to reproduce:
> * Run CLI (./jboss-cli.sh -c) and use this commands to configure new security domain:
> /subsystem=security/security-domain=trust-domain:add
> /subsystem=security/security-domain=trust-domain/jsse=classic:add(truststore=>{password=1234test,url=/home/jcacek/projects/ocsp-check/build/trusted-clients.jks})
> reload
> * check standalone.xml, where should be sth. like
> <security-domain name="trust-domain">
> <jsse truststore-password="1234test" truststore-url="/home/jcacek/projects/ocsp-check/build/trusted-clients.jks"/>
> </security-domain>
> But there is:
> <security-domain name="trust-domain">
> <jsse/>
> </security-domain>
> {noformat}
> {noformat}
> I had a mistake in the second command, it should be:
> /subsystem=security/security-domain=trust-domain/jsse=classic:add(truststore={password=>1234test,url=>/home/jcacek/projects/ocsp-check/build/trusted-clients.jks})
> Then it works.
> Nevertheless it's probably still a bug, when the original command returns:
> {
> "outcome" => "success",
> "response-headers" => {
> "operation-requires-reload" => true,
> "process-state" => "reload-required"
> }
> }
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 10 months
[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.
Using the 'drools.dump.dir' property seems like the best option. The name is general enough and users would have to use/remember yet another config. property.
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 compatibility 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.
- 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.
> Using the 'drools.dump.dir' property seems like the best option. The name is general enough and users would have to use/remember yet another config. property.
> 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 compatibility 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)
11 years, 10 months
[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)
11 years, 10 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)
11 years, 10 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)
11 years, 10 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)
11 years, 10 months