[JBoss JIRA] (DROOLS-388) Inconsistent behavior of "contains" operator
by Davide Sottara (JIRA)
[ https://issues.jboss.org/browse/DROOLS-388?page=com.atlassian.jira.plugin... ]
Davide Sottara updated DROOLS-388:
----------------------------------
Description:
The compiler accepts constraints such as
{code}
Person( fullName contains 'Jr' ) // should be fullName.contains('Jr')
{code}
Interestingly, MVEL evaluates it as the string operation "contains", but
once the constraint is jitted it is again evaluated as a collection operator.
That is, a rule such as:
{code}
when
$s : String( this contains "foo" )
then
{code}
with inputs "foo1" .. "fooN" effectively fires an unpredictable number of times before starting to fail silently
was:
The compiler accepts constraints such as
{code}
Person( fullName contains 'Jr' ) // should be fullName.contains('Jr')
{code}
Interestingly, MVEL evaluates it as the string "contains", but once
the constraint is jitted it is again evaluated as a collection operator.
That is, a rule such as:
{code}
when
$s : String( this contains "foo" )
then
{code}
with inputs "foo1" .. "fooN" effectively fires an unpredictable number of times before starting to fail silently
> Inconsistent behavior of "contains" operator
> --------------------------------------------
>
> Key: DROOLS-388
> URL: https://issues.jboss.org/browse/DROOLS-388
> Project: Drools
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 5.5.1.Final, 6.0.0.Final
> Reporter: Davide Sottara
> Assignee: Mario Fusco
> Priority: Minor
>
> The compiler accepts constraints such as
> {code}
> Person( fullName contains 'Jr' ) // should be fullName.contains('Jr')
> {code}
> Interestingly, MVEL evaluates it as the string operation "contains", but
> once the constraint is jitted it is again evaluated as a collection operator.
> That is, a rule such as:
> {code}
> when
> $s : String( this contains "foo" )
> then
> {code}
> with inputs "foo1" .. "fooN" effectively fires an unpredictable number of times before starting to fail silently
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 6 months
[JBoss JIRA] (DROOLS-388) Inconsistent behavior of "contains" operator
by Davide Sottara (JIRA)
Davide Sottara created DROOLS-388:
-------------------------------------
Summary: Inconsistent behavior of "contains" operator
Key: DROOLS-388
URL: https://issues.jboss.org/browse/DROOLS-388
Project: Drools
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 6.0.0.Final, 5.5.1.Final
Reporter: Davide Sottara
Assignee: Mario Fusco
Priority: Minor
The compiler accepts constraints such as
{code}
Person( fullName contains 'Jr' ) // should be fullName.contains('Jr')
{code}
Interestingly, MVEL evaluates it as the string "contains", but once
the constraint is jitted it is again evaluated as a collection operator.
That is, a rule such as:
{code}
when
$s : String( this contains "foo" )
then
{code}
with inputs "foo1" .. "fooN" effectively fires an unpredictable number of times before starting to fail silently
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 6 months
[JBoss JIRA] (DROOLS-387) NoSuchElementException on addKnowledgePackages when a "not" follows an "eval"
by Davide Sottara (JIRA)
[ https://issues.jboss.org/browse/DROOLS-387?page=com.atlassian.jira.plugin... ]
Davide Sottara commented on DROOLS-387:
---------------------------------------
Could you please try 5.6.0.CR1? I could not reproduce the problem with that version
Thanks
Davide
> NoSuchElementException on addKnowledgePackages when a "not" follows an "eval"
> -----------------------------------------------------------------------------
>
> Key: DROOLS-387
> URL: https://issues.jboss.org/browse/DROOLS-387
> Project: Drools
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 5.5.0.Final
> Environment: java version "1.7.0_21"
> Reporter: Jason Saint
> Assignee: Mark Proctor
>
> I apologize if this has already been reported, but I did not see anything in search results for which this looked like a duplicate.
> With the following 2 rules, compiling the first and adding it to a knowledge base causes subsequent package additions to fail with a NoSuchElementException.
> rule "Problem"
> when
> eval(true == true)
> not String() from "Problem"
> then
> end
> rule "Test1"
> when
> $test : String() from "Test"
> then
> end
> The following java code will produce the exception on the second call to addKnowledgePackages (tried with Drools 5.4 and 5.5)
> {code}
> package com.chiprewards.droolsbug;
> import org.drools.KnowledgeBase;
> import org.drools.KnowledgeBaseFactory;
> import org.drools.builder.KnowledgeBuilder;
> import org.drools.builder.KnowledgeBuilderErrors;
> import org.drools.builder.KnowledgeBuilderFactory;
> import org.drools.io.Resource;
> import org.drools.builder.ResourceType;
> import org.drools.io.ResourceFactory;
> /**
> * Hello world!
> *
> */
> public class App
> {
> public static void main( String[] args )
> {
> KnowledgeBase kBase = KnowledgeBaseFactory.newKnowledgeBase();
> KnowledgeBuilder kbuilder = KnowledgeBuilderFactory.newKnowledgeBuilder();
>
> String problem_rule = "rule \"Problem\"\n when\n eval(true == true)\n not String() from \"Problem\"\n then\nend";
>
> Resource resource = ResourceFactory.newByteArrayResource(problem_rule.getBytes());
> kbuilder.add(resource, ResourceType.DRL);
> if(kbuilder.hasErrors()) {
> System.out.println("First rule had error parsing");
> System.exit(1);
> }
>
> kBase.addKnowledgePackages(kbuilder.getKnowledgePackages());
>
> //Add second rule
>
> String next_rule = "rule \"Test\"\n when\n String() from \"Test\"\n then\nend";
>
> resource = ResourceFactory.newByteArrayResource(next_rule.getBytes());
> kbuilder.add(resource, ResourceType.DRL);
> if(kbuilder.hasErrors()) {
> System.out.println("Second rule had error parsing");
> System.exit(1);
> }
>
> kBase.addKnowledgePackages(kbuilder.getKnowledgePackages());
> }
> }
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 6 months
[JBoss JIRA] (DROOLS-387) NoSuchElementException on addKnowledgePackages when a "not" follows an "eval"
by Jason Saint (JIRA)
[ https://issues.jboss.org/browse/DROOLS-387?page=com.atlassian.jira.plugin... ]
Jason Saint updated DROOLS-387:
-------------------------------
Description:
I apologize if this has already been reported, but I did not see anything in search results for which this looked like a duplicate.
With the following 2 rules, compiling the first and adding it to a knowledge base causes subsequent package additions to fail with a NoSuchElementException.
rule "Problem"
when
eval(true == true)
not String() from "Problem"
then
end
rule "Test1"
when
$test : String() from "Test"
then
end
The following java code will produce the exception on the second call to addKnowledgePackages (tried with Drools 5.4 and 5.5)
{code}
package com.chiprewards.droolsbug;
import org.drools.KnowledgeBase;
import org.drools.KnowledgeBaseFactory;
import org.drools.builder.KnowledgeBuilder;
import org.drools.builder.KnowledgeBuilderErrors;
import org.drools.builder.KnowledgeBuilderFactory;
import org.drools.io.Resource;
import org.drools.builder.ResourceType;
import org.drools.io.ResourceFactory;
/**
* Hello world!
*
*/
public class App
{
public static void main( String[] args )
{
KnowledgeBase kBase = KnowledgeBaseFactory.newKnowledgeBase();
KnowledgeBuilder kbuilder = KnowledgeBuilderFactory.newKnowledgeBuilder();
String problem_rule = "rule \"Problem\"\n when\n eval(true == true)\n not String() from \"Problem\"\n then\nend";
Resource resource = ResourceFactory.newByteArrayResource(problem_rule.getBytes());
kbuilder.add(resource, ResourceType.DRL);
if(kbuilder.hasErrors()) {
System.out.println("First rule had error parsing");
System.exit(1);
}
kBase.addKnowledgePackages(kbuilder.getKnowledgePackages());
//Add second rule
String next_rule = "rule \"Test\"\n when\n String() from \"Test\"\n then\nend";
resource = ResourceFactory.newByteArrayResource(next_rule.getBytes());
kbuilder.add(resource, ResourceType.DRL);
if(kbuilder.hasErrors()) {
System.out.println("Second rule had error parsing");
System.exit(1);
}
kBase.addKnowledgePackages(kbuilder.getKnowledgePackages());
}
}
{code}
was:
I apologize if this has already been reported, but I did not see anything in search results for which this looked like a duplicate.
With the following 2 rules, compiling the first and adding it to a knowledge base causes subsequent package additions to fail with a NoSuchElementException.
rule "Problem"
when
eval(true == true)
not String() from "Problem"
then
end
rule "Test1"
when
$test : String() from "Test"
then
end
The following java code will produce the exception (tried with Drools 5.4 and 5.5)
{code}
package com.chiprewards.droolsbug;
import org.drools.KnowledgeBase;
import org.drools.KnowledgeBaseFactory;
import org.drools.builder.KnowledgeBuilder;
import org.drools.builder.KnowledgeBuilderErrors;
import org.drools.builder.KnowledgeBuilderFactory;
import org.drools.io.Resource;
import org.drools.builder.ResourceType;
import org.drools.io.ResourceFactory;
/**
* Hello world!
*
*/
public class App
{
public static void main( String[] args )
{
KnowledgeBase kBase = KnowledgeBaseFactory.newKnowledgeBase();
KnowledgeBuilder kbuilder = KnowledgeBuilderFactory.newKnowledgeBuilder();
String problem_rule = "rule \"Problem\"\n when\n eval(true == true)\n not String() from \"Problem\"\n then\nend";
Resource resource = ResourceFactory.newByteArrayResource(problem_rule.getBytes());
kbuilder.add(resource, ResourceType.DRL);
if(kbuilder.hasErrors()) {
System.out.println("First rule had error parsing");
System.exit(1);
}
kBase.addKnowledgePackages(kbuilder.getKnowledgePackages());
//Add second rule
String next_rule = "rule \"Test\"\n when\n String() from \"Test\"\n then\nend";
resource = ResourceFactory.newByteArrayResource(next_rule.getBytes());
kbuilder.add(resource, ResourceType.DRL);
if(kbuilder.hasErrors()) {
System.out.println("Second rule had error parsing");
System.exit(1);
}
kBase.addKnowledgePackages(kbuilder.getKnowledgePackages());
}
}
{code}
> NoSuchElementException on addKnowledgePackages when a "not" follows an "eval"
> -----------------------------------------------------------------------------
>
> Key: DROOLS-387
> URL: https://issues.jboss.org/browse/DROOLS-387
> Project: Drools
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 5.5.0.Final
> Environment: java version "1.7.0_21"
> Reporter: Jason Saint
> Assignee: Mark Proctor
>
> I apologize if this has already been reported, but I did not see anything in search results for which this looked like a duplicate.
> With the following 2 rules, compiling the first and adding it to a knowledge base causes subsequent package additions to fail with a NoSuchElementException.
> rule "Problem"
> when
> eval(true == true)
> not String() from "Problem"
> then
> end
> rule "Test1"
> when
> $test : String() from "Test"
> then
> end
> The following java code will produce the exception on the second call to addKnowledgePackages (tried with Drools 5.4 and 5.5)
> {code}
> package com.chiprewards.droolsbug;
> import org.drools.KnowledgeBase;
> import org.drools.KnowledgeBaseFactory;
> import org.drools.builder.KnowledgeBuilder;
> import org.drools.builder.KnowledgeBuilderErrors;
> import org.drools.builder.KnowledgeBuilderFactory;
> import org.drools.io.Resource;
> import org.drools.builder.ResourceType;
> import org.drools.io.ResourceFactory;
> /**
> * Hello world!
> *
> */
> public class App
> {
> public static void main( String[] args )
> {
> KnowledgeBase kBase = KnowledgeBaseFactory.newKnowledgeBase();
> KnowledgeBuilder kbuilder = KnowledgeBuilderFactory.newKnowledgeBuilder();
>
> String problem_rule = "rule \"Problem\"\n when\n eval(true == true)\n not String() from \"Problem\"\n then\nend";
>
> Resource resource = ResourceFactory.newByteArrayResource(problem_rule.getBytes());
> kbuilder.add(resource, ResourceType.DRL);
> if(kbuilder.hasErrors()) {
> System.out.println("First rule had error parsing");
> System.exit(1);
> }
>
> kBase.addKnowledgePackages(kbuilder.getKnowledgePackages());
>
> //Add second rule
>
> String next_rule = "rule \"Test\"\n when\n String() from \"Test\"\n then\nend";
>
> resource = ResourceFactory.newByteArrayResource(next_rule.getBytes());
> kbuilder.add(resource, ResourceType.DRL);
> if(kbuilder.hasErrors()) {
> System.out.println("Second rule had error parsing");
> System.exit(1);
> }
>
> kBase.addKnowledgePackages(kbuilder.getKnowledgePackages());
> }
> }
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 6 months
[JBoss JIRA] (DROOLS-387) NoSuchElementException on addKnowledgePackages when a "not" follows an "eval"
by Jason Saint (JIRA)
Jason Saint created DROOLS-387:
----------------------------------
Summary: NoSuchElementException on addKnowledgePackages when a "not" follows an "eval"
Key: DROOLS-387
URL: https://issues.jboss.org/browse/DROOLS-387
Project: Drools
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 5.5.0.Final
Environment: java version "1.7.0_21"
Reporter: Jason Saint
Assignee: Mark Proctor
I apologize if this has already been reported, but I did not see anything in search results for which this looked like a duplicate.
With the following 2 rules, compiling the first and adding it to a knowledge base causes subsequent package additions to fail with a NoSuchElementException.
rule "Problem"
when
eval(true == true)
not String() from "Problem"
then
end
rule "Test1"
when
$test : String() from "Test"
then
end
The following java code will produce the exception (tried with Drools 5.4 and 5.5)
{code}
package com.chiprewards.droolsbug;
import org.drools.KnowledgeBase;
import org.drools.KnowledgeBaseFactory;
import org.drools.builder.KnowledgeBuilder;
import org.drools.builder.KnowledgeBuilderErrors;
import org.drools.builder.KnowledgeBuilderFactory;
import org.drools.io.Resource;
import org.drools.builder.ResourceType;
import org.drools.io.ResourceFactory;
/**
* Hello world!
*
*/
public class App
{
public static void main( String[] args )
{
KnowledgeBase kBase = KnowledgeBaseFactory.newKnowledgeBase();
KnowledgeBuilder kbuilder = KnowledgeBuilderFactory.newKnowledgeBuilder();
String problem_rule = "rule \"Problem\"\n when\n eval(true == true)\n not String() from \"Problem\"\n then\nend";
Resource resource = ResourceFactory.newByteArrayResource(problem_rule.getBytes());
kbuilder.add(resource, ResourceType.DRL);
if(kbuilder.hasErrors()) {
System.out.println("First rule had error parsing");
System.exit(1);
}
kBase.addKnowledgePackages(kbuilder.getKnowledgePackages());
//Add second rule
String next_rule = "rule \"Test\"\n when\n String() from \"Test\"\n then\nend";
resource = ResourceFactory.newByteArrayResource(next_rule.getBytes());
kbuilder.add(resource, ResourceType.DRL);
if(kbuilder.hasErrors()) {
System.out.println("Second rule had error parsing");
System.exit(1);
}
kBase.addKnowledgePackages(kbuilder.getKnowledgePackages());
}
}
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 6 months
[JBoss JIRA] (WFLY-2692) infinite wait in BasicComponent#waitForComponentStart() causes server hang
by jaikiran pai (JIRA)
[ https://issues.jboss.org/browse/WFLY-2692?page=com.atlassian.jira.plugin.... ]
jaikiran pai commented on WFLY-2692:
------------------------------------
I think this is a duplicate of https://issues.jboss.org/browse/WFLY-917
> infinite wait in BasicComponent#waitForComponentStart() causes server hang
> --------------------------------------------------------------------------
>
> Key: WFLY-2692
> URL: https://issues.jboss.org/browse/WFLY-2692
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: EE
> Affects Versions: 8.0.0.CR1
> Reporter: Thomas Frühbeck
> Assignee: David Lloyd
> Labels: EE, MSC, hangs
> Attachments: WFLY-2692_infiniteHang_stacktrace.log
>
>
> some error in deployment may cause infinite wait on BasicComponent#waitForComponentStart():
> protected void waitForComponentStart() {
> if (!gate) {
> // Block until successful start
> synchronized (this) {
> while (!gate) {
> // TODO: check for failure condition
> try {
> wait();
>
> The server life cycle management is completely blocked, no normal redeployment/shutdown will work!
> Please provide some remedy (e.g. timed wait and fail?), IMHO this is really _very_ distressing for a production ready system.
>
> Sample stack trace:
> "MSC service thread 1-7" prio=10 tid=0x00007f6c60001800 nid=0x7af0 in Object.wait() [0x00007f6cbd785000]
> java.lang.Thread.State: WAITING (on object monitor)
> at java.lang.Object.wait(Native Method)
> - waiting on <0x00000000e20a0a20> (a org.jboss.as.ejb3.component.singleton.SingletonComponent)
> at java.lang.Object.wait(Object.java:503)
> at org.jboss.as.ee.component.BasicComponent.waitForComponentStart(BasicComponent.java:115)
> - locked <0x00000000e20a0a20> (a org.jboss.as.ejb3.component.singleton.SingletonComponent)
> at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:145)
> at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:133)
> at org.jboss.as.ee.component.BasicComponent.createInstance(BasicComponent.java:89)
> at org.jboss.as.ejb3.component.singleton.SingletonComponent.getComponentInstance(SingletonComponent.java:123)
> - locked <0x00000000e20bfa10> (a java.lang.Object)
> at org.jboss.as.ejb3.component.singleton.SingletonComponentInstanceAssociationInterceptor.processInvocation(SingletonComponentInstanceAssociationInterce
> ptor.java:47)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:95)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:59)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:55)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:325)
> at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:437)
> at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:325)
> at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:185)
> at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:182)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:73)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 6 months
[JBoss JIRA] (WFLY-2692) infinite wait in BasicComponent#waitForComponentStart() causes server hang
by Thomas Frühbeck (JIRA)
[ https://issues.jboss.org/browse/WFLY-2692?page=com.atlassian.jira.plugin.... ]
Thomas Frühbeck updated WFLY-2692:
----------------------------------
Attachment: WFLY-2692_infiniteHang_stacktrace.log
full stack dump of infinitely blocked server
> infinite wait in BasicComponent#waitForComponentStart() causes server hang
> --------------------------------------------------------------------------
>
> Key: WFLY-2692
> URL: https://issues.jboss.org/browse/WFLY-2692
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: EE
> Affects Versions: 8.0.0.CR1
> Reporter: Thomas Frühbeck
> Assignee: David Lloyd
> Labels: EE, MSC, hangs
> Attachments: WFLY-2692_infiniteHang_stacktrace.log
>
>
> some error in deployment may cause infinite wait on BasicComponent#waitForComponentStart():
> protected void waitForComponentStart() {
> if (!gate) {
> // Block until successful start
> synchronized (this) {
> while (!gate) {
> // TODO: check for failure condition
> try {
> wait();
>
> The server life cycle management is completely blocked, no normal redeployment/shutdown will work!
> Please provide some remedy (e.g. timed wait and fail?), IMHO this is really _very_ distressing for a production ready system.
>
> Sample stack trace:
> "MSC service thread 1-7" prio=10 tid=0x00007f6c60001800 nid=0x7af0 in Object.wait() [0x00007f6cbd785000]
> java.lang.Thread.State: WAITING (on object monitor)
> at java.lang.Object.wait(Native Method)
> - waiting on <0x00000000e20a0a20> (a org.jboss.as.ejb3.component.singleton.SingletonComponent)
> at java.lang.Object.wait(Object.java:503)
> at org.jboss.as.ee.component.BasicComponent.waitForComponentStart(BasicComponent.java:115)
> - locked <0x00000000e20a0a20> (a org.jboss.as.ejb3.component.singleton.SingletonComponent)
> at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:145)
> at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:133)
> at org.jboss.as.ee.component.BasicComponent.createInstance(BasicComponent.java:89)
> at org.jboss.as.ejb3.component.singleton.SingletonComponent.getComponentInstance(SingletonComponent.java:123)
> - locked <0x00000000e20bfa10> (a java.lang.Object)
> at org.jboss.as.ejb3.component.singleton.SingletonComponentInstanceAssociationInterceptor.processInvocation(SingletonComponentInstanceAssociationInterce
> ptor.java:47)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:95)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:59)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:55)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:325)
> at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:437)
> at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:325)
> at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:185)
> at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:182)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:73)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 6 months
[JBoss JIRA] (WFLY-2692) infinite wait in BasicComponent#waitForComponentStart() causes server hang
by Thomas Frühbeck (JIRA)
Thomas Frühbeck created WFLY-2692:
-------------------------------------
Summary: infinite wait in BasicComponent#waitForComponentStart() causes server hang
Key: WFLY-2692
URL: https://issues.jboss.org/browse/WFLY-2692
Project: WildFly
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: EE
Affects Versions: 8.0.0.CR1
Reporter: Thomas Frühbeck
Assignee: David Lloyd
some error in deployment may cause infinite wait on BasicComponent#waitForComponentStart():
protected void waitForComponentStart() {
if (!gate) {
// Block until successful start
synchronized (this) {
while (!gate) {
// TODO: check for failure condition
try {
wait();
The server life cycle management is completely blocked, no normal redeployment/shutdown will work!
Please provide some remedy (e.g. timed wait and fail?), IMHO this is really _very_ distressing for a production ready system.
Sample stack trace:
"MSC service thread 1-7" prio=10 tid=0x00007f6c60001800 nid=0x7af0 in Object.wait() [0x00007f6cbd785000]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on <0x00000000e20a0a20> (a org.jboss.as.ejb3.component.singleton.SingletonComponent)
at java.lang.Object.wait(Object.java:503)
at org.jboss.as.ee.component.BasicComponent.waitForComponentStart(BasicComponent.java:115)
- locked <0x00000000e20a0a20> (a org.jboss.as.ejb3.component.singleton.SingletonComponent)
at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:145)
at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:133)
at org.jboss.as.ee.component.BasicComponent.createInstance(BasicComponent.java:89)
at org.jboss.as.ejb3.component.singleton.SingletonComponent.getComponentInstance(SingletonComponent.java:123)
- locked <0x00000000e20bfa10> (a java.lang.Object)
at org.jboss.as.ejb3.component.singleton.SingletonComponentInstanceAssociationInterceptor.processInvocation(SingletonComponentInstanceAssociationInterce
ptor.java:47)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:95)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:59)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:55)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:325)
at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:437)
at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:325)
at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:185)
at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:182)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:73)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 6 months
[JBoss JIRA] (WFLY-2689) @Producer method never called when producing a bean from a static module
by Pedro Igor (JIRA)
[ https://issues.jboss.org/browse/WFLY-2689?page=com.atlassian.jira.plugin.... ]
Pedro Igor commented on WFLY-2689:
----------------------------------
FYI, the same code works for EAP 6.1 and 6.2.
> @Producer method never called when producing a bean from a static module
> ------------------------------------------------------------------------
>
> Key: WFLY-2689
> URL: https://issues.jboss.org/browse/WFLY-2689
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: CDI / Weld
> Affects Versions: 8.0.0.CR1
> Environment: WildFly 8.0.0.CR1
> Reporter: Pedro Igor
> Assignee: Stuart Douglas
>
> I've configured a static module for PicketLink CDI library. This library provides some extensions which are loaded fine, as described by WFLY-1370.
> However, I'm trying to deploy my application which the following producer method:
> {code}
> @Produces
> @PicketLink
> public PartitionManager getPartitionManager() {
> // produce an instance
> }
> {code}
> Where the @PicketLink annotation is a qualifier that allows my deployment to provide its own instance instead.
> In the PicketLink side, we have a injection point as follows:
> @Inject
> @PicketLink
> private Instance<PartitionManager> partitionManagerInstance;
> Where a call to partitionManagerInstance.isUnsatisfied() always returns true, even if my deployment provides a proper producer method.
> The issue here is that the producer method is never called, despite the use of qualifiers or not.
> FYI, I'm able to listen for events fired by PicketLink during the application startup as follows:
> public void observeIdentityConfigurationEvent(@Observes IdentityConfigurationEvent event) {
> // observer
> }
> Where IdentityConfigurationEvent is one of the lifecycle events fired by PicketLink during the startup.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 6 months