[JBoss JIRA] (AS7-6255) Memory leak caused by endless piling up of delete-on-exit hooks for JMX authentication challenges
by Taras Tielkes (JIRA)
Taras Tielkes created AS7-6255:
----------------------------------
Summary: Memory leak caused by endless piling up of delete-on-exit hooks for JMX authentication challenges
Key: AS7-6255
URL: https://issues.jboss.org/browse/AS7-6255
Project: Application Server 7
Issue Type: Bug
Components: JMX
Affects Versions: 7.1.1.Final
Reporter: Taras Tielkes
Assignee: Stuart Douglas
We're running 7.1.1, with a patch applied for REMJMX-45 to limit the worst leaks coming from the JMX subsystem.
However, even with this patch applied we can only survive for a few days in a production-like scenario.
Inspection of the out-of-memory heap dumps shows a large accumulation of entries inside {{java.io.DeleteOnExitHook}}, all having values like "{{C:\jars\jboss-as-7.1.1.Final\standalone\tmp\auth\challenge-4303257}}".
Given sufficient JMX connections made to a running instance of 7.1.1, this will at some point exhaust the JVM heap. Typically the paths will be longer than the example above, accelerating the process.
--
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
11 years, 3 months
[JBoss JIRA] (AS7-6254) Memory leak caused by retained connection ids in RemotingConnectorServer superclass
by Taras Tielkes (JIRA)
[ https://issues.jboss.org/browse/AS7-6254?page=com.atlassian.jira.plugin.s... ]
Taras Tielkes updated AS7-6254:
-------------------------------
Description:
We're running 7.1.1, with a patch applied for REMJMX-45 to limit the worst leaks coming from the JMX subsystem.
However, even with this patch applied we can only survive for a few days in a production-like scenario.
It seems that {{org.jboss.remotingjmx.RemotingConnectorServer}} never calls the {{connectionClosed()}}/{{connectionFailed()}} methods in its superclass.
As such, the connection ids that are stored in the field {{javax.management.remote.JMXConnectorServer#connectionIds}} are never released.
Given sufficient connections made to a running instance of 7.1.1 (for example, various monitoring tools), an out-of-memory end-state is inevitable.
was:
We're running 7.1.1, with a patch applied for REMJMX-45 to limit the worst leaks coming from the JMX subsystem.
However, even with this patch applied we can only survive for a few days in a production-like scenario.
It seems that {{org.jboss.remotingjmx.RemotingConnectorServer}} never calls the {{connectionClosed()}}/{{connectionFailed()}} methods in its superclass.
As such, the connection ids that are stored in the field {{javax.management.remote.JMXConnectorServer#connectionIds}} are never released.
Given sufficient connections make to a running instance of 7.1.1 (for example, various monitoring tools), an out-of-memory end-state is inevitable.
> Memory leak caused by retained connection ids in RemotingConnectorServer superclass
> ------------------------------------------------------------------------------------
>
> Key: AS7-6254
> URL: https://issues.jboss.org/browse/AS7-6254
> Project: Application Server 7
> Issue Type: Bug
> Components: JMX
> Affects Versions: 7.1.1.Final
> Reporter: Taras Tielkes
> Assignee: Stuart Douglas
>
> We're running 7.1.1, with a patch applied for REMJMX-45 to limit the worst leaks coming from the JMX subsystem.
> However, even with this patch applied we can only survive for a few days in a production-like scenario.
> It seems that {{org.jboss.remotingjmx.RemotingConnectorServer}} never calls the {{connectionClosed()}}/{{connectionFailed()}} methods in its superclass.
> As such, the connection ids that are stored in the field {{javax.management.remote.JMXConnectorServer#connectionIds}} are never released.
> Given sufficient connections made to a running instance of 7.1.1 (for example, various monitoring tools), an out-of-memory end-state is inevitable.
--
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
11 years, 3 months
[JBoss JIRA] (AS7-6254) Memory leak caused by retained connection ids in RemotingConnectorServer superclass
by Taras Tielkes (JIRA)
Taras Tielkes created AS7-6254:
----------------------------------
Summary: Memory leak caused by retained connection ids in RemotingConnectorServer superclass
Key: AS7-6254
URL: https://issues.jboss.org/browse/AS7-6254
Project: Application Server 7
Issue Type: Bug
Components: JMX
Affects Versions: 7.1.1.Final
Reporter: Taras Tielkes
Assignee: Stuart Douglas
We're running 7.1.1, with a patch applied for REMJMX-45 to limit the worst leaks coming from the JMX subsystem.
However, even with this patch applied we can only survive for a few days in a production-like scenario.
It seems that {{org.jboss.remotingjmx.RemotingConnectorServer}} never calls the {{connectionClosed()}}/{{connectionFailed()}} methods in its superclass.
As such, the connection ids that are stored in the field {{javax.management.remote.JMXConnectorServer#connectionIds}} are never released.
Given sufficient connections make to a running instance of 7.1.1 (for example, various monitoring tools), an out-of-memory end-state is inevitable.
--
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
11 years, 3 months
[JBoss JIRA] (JBAS-9526) High CPU with lots of Waiting threads on JIoEndpoint$Worker on version 5.0.1
by shikhar khanna (JIRA)
[ https://issues.jboss.org/browse/JBAS-9526?page=com.atlassian.jira.plugin.... ]
shikhar khanna updated JBAS-9526:
---------------------------------
Description:
High CPU with lots of Waiting threads on JIoEndpoint$Worker on version 5.0.1
- Running a 100 user load test on JBoss 5.0.1.
- Getting High CPU
- Analyzed thread dumps and found almost 50-60% threads are waiting as per below snippet\
Thread Name : http-0.0.0.0-8080-8 State : in Object.wait() Java Stack at java.lang.Object.wait(Native Method) - waiting on [0x24d875d0] (a org.apache.tomcat.util.net.JIoEndpoint$Worker) at java.lang.Object.wait(Object.java:485) at org.apache.tomcat.util.net.JIoEndpoint$Worker.await(JIoEndpoint.java:416) - locked [0x24d875d0] (a org.apache.tomcat.util.net.JIoEndpoint$Worker) at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:442) at java.lang.Thread.run(Thread.java:662)
> High CPU with lots of Waiting threads on JIoEndpoint$Worker on version 5.0.1
> ----------------------------------------------------------------------------
>
> Key: JBAS-9526
> URL: https://issues.jboss.org/browse/JBAS-9526
> Project: Application Server 3 4 5 and 6
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Reporter: shikhar khanna
>
> High CPU with lots of Waiting threads on JIoEndpoint$Worker on version 5.0.1
> - Running a 100 user load test on JBoss 5.0.1.
> - Getting High CPU
> - Analyzed thread dumps and found almost 50-60% threads are waiting as per below snippet\
> Thread Name : http-0.0.0.0-8080-8 State : in Object.wait() Java Stack at java.lang.Object.wait(Native Method) - waiting on [0x24d875d0] (a org.apache.tomcat.util.net.JIoEndpoint$Worker) at java.lang.Object.wait(Object.java:485) at org.apache.tomcat.util.net.JIoEndpoint$Worker.await(JIoEndpoint.java:416) - locked [0x24d875d0] (a org.apache.tomcat.util.net.JIoEndpoint$Worker) at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:442) at java.lang.Thread.run(Thread.java:662)
--
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
11 years, 4 months
[JBoss JIRA] (JBAS-7218) ENC EM injection erroneously happens only once for web modules
by henk de boer (JIRA)
[ https://issues.jboss.org/browse/JBAS-7218?page=com.atlassian.jira.plugin.... ]
henk de boer commented on JBAS-7218:
------------------------------------
I tested this again with JBoss AS 7.1.2.Final-redhat-1, and now it works :)
E.g. executing the following code from within a Servlet, given the setup as described in the forum reference now returns 2 distinct instances:
{code}
EntityManager entityManagerx = (EntityManager) new InitialContext().lookup("java:comp/env/persistence/test");
EntityManager entityManagery = (EntityManager) new InitialContext().lookup("java:comp/env/persistence/test");
{code}
> ENC EM injection erroneously happens only once for web modules
> --------------------------------------------------------------
>
> Key: JBAS-7218
> URL: https://issues.jboss.org/browse/JBAS-7218
> Project: Application Server 3 4 5 and 6
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: JBossAS-5.1.0.GA
> Environment: Observed problem on Mac OS X 10.5.7 and Debian Lenny 64 bits using JDK 6
> Reporter: henk de boer
> Assignee: Scott Marlow
>
> Using a persistence-context-ref element in the web.xml of a web module, it appears that this causes an EntityManager instance to be injected only once into the ENC of this component.
> However, the EJB 3.0 spec states in section 16.2.1:
> "In general, lookups of objects in the JNDI java: namespace are required to return a new instance of the requested object every time."
> So the observed behavior seems to violate the spec. In addition, this is particularly troublesome since an EntityManager is explicitly not thread-safe. Using the same EM instance for simultaneous requests therefor doesn't work.
> Of course there are several other methods to obtain an EM reference, for instance binding an EM factory directly to JNDI and using that to obtain the reference.
--
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
11 years, 4 months
[JBoss JIRA] (JBWEB-219) stdout and stderr cause double newlines
by Kamil Prochazka (JIRA)
[ https://issues.jboss.org/browse/JBWEB-219?page=com.atlassian.jira.plugin.... ]
Kamil Prochazka commented on JBWEB-219:
---------------------------------------
I came across this issue too with my log4j ConversionPattern.
Something like this: log4j.appender.file.layout.ConversionPattern=%d{ISO8601} %-5p %c{1} - %m%n
I just replaced %m%n with %m\n.
Works fine on windows machine.
Suppose this issue is related to OS new line delimiter.
> stdout and stderr cause double newlines
> ---------------------------------------
>
> Key: JBWEB-219
> URL: https://issues.jboss.org/browse/JBWEB-219
> Project: JBoss Web
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Environment: Windows 7
> Reporter: Karsten Wutzke
> Assignee: Remy Maucherat
> Priority: Minor
>
> stdout and stderr cause double newlines (e.g. in the Eclipse console).
> This can be especially annoying when printing stack traces...
--
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
11 years, 4 months
[JBoss JIRA] (JBRULES-3709) When use method of FACT match(Object... objs), throws java.lang.RuntimeException: cannot invoke method
by Yingzhi Wang (JIRA)
[ https://issues.jboss.org/browse/JBRULES-3709?page=com.atlassian.jira.plug... ]
Yingzhi Wang updated JBRULES-3709:
----------------------------------
Attachment: user_src.zip
The source of the issue
> When use method of FACT match(Object... objs), throws java.lang.RuntimeException: cannot invoke method
> -------------------------------------------------------------------------------------------------------
>
> Key: JBRULES-3709
> URL: https://issues.jboss.org/browse/JBRULES-3709
> Project: JBRULES
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: drools-core
> Affects Versions: 5.4.0.Final, 5.5.0.Final
> Environment: OS: Windows xp
> IDE: Eclipse
> JRE: 1.6
> Reporter: Yingzhi Wang
> Assignee: Mark Proctor
> Priority: Critical
> Labels: RuntimeException, invoke, method
> Attachments: user_src.zip
>
>
> I writed a method of fact User "public boolean match(Boolean... bs)", and when I use it in drl like this "User(match(true, true))", it will thows exception: java.lang.RuntimeException: cannot invoke method: match. But if I change it to User(match(true)), it will be ok.
> And also, If I insert fact first, then add the rule, It will throws this exception, if I add the rule first, then insert fact, it will be ok.
> Is DRools not support method(Object... objs)?
> FACT: User
> package user;
> public class User {
> public boolean match(Boolean... bs) {
> return true;
> }
> public boolean matchList(Boolean b1, Boolean b2) {
> return true;
> }
> }
> DRL: user.drl
> package test
> import user.User
> rule "test"
> when
> // User(match(true)) // is ok
> User(match(true, true)) // is err
> // User(matchList(true, true)) // is ok
> then
> System.out.println("It's OK!");
> end
> main:
> KnowledgeBase base = KnowledgeBaseFactory.newKnowledgeBase();
> StatefulKnowledgeSession s = base.newStatefulKnowledgeSession();
> // user insert here will be err
> User user = new User();
> s.insert(user);
>
> // add rule
> KnowledgeBuilder builder = KnowledgeBuilderFactory.newKnowledgeBuilder();
> builder.add(ResourceFactory.newClassPathResource("user.drl", Test.class), ResourceType.DRL);
> KnowledgeBuilderErrors errs = builder.getErrors();
> if (!errs.isEmpty()) {
> for (KnowledgeBuilderError e: errs) {
> System.out.println(e.toString());
> }
> }
> Collection<KnowledgePackage> col = builder.getKnowledgePackages();
> base.addKnowledgePackages(col);
>
> // user insert here is ok
> // User user = new User();
> // s.insert(user);
>
> // fire
> s.fireAllRules();
> Exception:
> Exception in thread "main" java.lang.RuntimeException: cannot invoke method: match
> at org.mvel2.optimizers.impl.refl.nodes.MethodAccessor.getValue(MethodAccessor.java:63)
> at org.mvel2.ast.ASTNode.getReducedValueAccelerated(ASTNode.java:108)
> at org.mvel2.MVELRuntime.execute(MVELRuntime.java:85)
> at org.mvel2.compiler.CompiledExpression.getValue(CompiledExpression.java:123)
> at org.mvel2.MVEL.executeExpression(MVEL.java:930)
> at org.drools.rule.constraint.MvelConditionEvaluator.evaluate(MvelConditionEvaluator.java:70)
> at org.drools.rule.constraint.MvelConditionEvaluator.evaluate(MvelConditionEvaluator.java:49)
> at org.drools.rule.constraint.MvelConstraint.evaluate(MvelConstraint.java:167)
> at org.drools.rule.constraint.MvelConstraint.isAllowed(MvelConstraint.java:124)
> at org.drools.reteoo.AlphaNode$ObjectSinkUpdateAdapter.assertObject(AlphaNode.java:325)
> at org.drools.reteoo.ObjectTypeNode.updateSink(ObjectTypeNode.java:334)
> at org.drools.reteoo.AlphaNode.updateSink(AlphaNode.java:203)
> at org.drools.reteoo.LeftInputAdapterNode.attach(LeftInputAdapterNode.java:120)
> at org.drools.reteoo.builder.BuildUtils.attachNode(BuildUtils.java:145)
> at org.drools.reteoo.builder.GroupElementBuilder$AndBuilder.build(GroupElementBuilder.java:127)
> at org.drools.reteoo.builder.GroupElementBuilder.build(GroupElementBuilder.java:71)
> at org.drools.reteoo.builder.ReteooRuleBuilder.addSubRule(ReteooRuleBuilder.java:155)
> at org.drools.reteoo.builder.ReteooRuleBuilder.addRule(ReteooRuleBuilder.java:128)
> at org.drools.reteoo.ReteooBuilder.addRule(ReteooBuilder.java:116)
> at org.drools.reteoo.ReteooRuleBase.addRule(ReteooRuleBase.java:445)
> at org.drools.common.AbstractRuleBase.addRule(AbstractRuleBase.java:956)
> at org.drools.common.AbstractRuleBase.addPackages(AbstractRuleBase.java:627)
> at org.drools.reteoo.ReteooRuleBase.addPackages(ReteooRuleBase.java:472)
> at org.drools.impl.KnowledgeBaseImpl.addKnowledgePackages(KnowledgeBaseImpl.java:150)
> at user.Test.main(Test.java:36)
> Caused by: java.lang.ArrayIndexOutOfBoundsException: 2
> at org.mvel2.optimizers.impl.refl.nodes.MethodAccessor.executeAll(MethodAccessor.java:149)
> at org.mvel2.optimizers.impl.refl.nodes.MethodAccessor.getValue(MethodAccessor.java:48)
> ... 24 more
--
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
11 years, 4 months
[JBoss JIRA] (JBRULES-3709) When use method of FACT match(Object... objs), throws java.lang.RuntimeException: cannot invoke method
by Yingzhi Wang (JIRA)
Yingzhi Wang created JBRULES-3709:
-------------------------------------
Summary: When use method of FACT match(Object... objs), throws java.lang.RuntimeException: cannot invoke method
Key: JBRULES-3709
URL: https://issues.jboss.org/browse/JBRULES-3709
Project: JBRULES
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: drools-core
Affects Versions: 5.5.0.Final, 5.4.0.Final
Environment: OS: Windows xp
IDE: Eclipse
JRE: 1.6
Reporter: Yingzhi Wang
Assignee: Mark Proctor
Priority: Critical
I writed a method of fact User "public boolean match(Boolean... bs)", and when I use it in drl like this "User(match(true, true))", it will thows exception: java.lang.RuntimeException: cannot invoke method: match. But if I change it to User(match(true)), it will be ok.
And also, If I insert fact first, then add the rule, It will throws this exception, if I add the rule first, then insert fact, it will be ok.
Is DRools not support method(Object... objs)?
FACT: User
package user;
public class User {
public boolean match(Boolean... bs) {
return true;
}
public boolean matchList(Boolean b1, Boolean b2) {
return true;
}
}
DRL: user.drl
package test
import user.User
rule "test"
when
// User(match(true)) // is ok
User(match(true, true)) // is err
// User(matchList(true, true)) // is ok
then
System.out.println("It's OK!");
end
main:
KnowledgeBase base = KnowledgeBaseFactory.newKnowledgeBase();
StatefulKnowledgeSession s = base.newStatefulKnowledgeSession();
// user insert here will be err
User user = new User();
s.insert(user);
// add rule
KnowledgeBuilder builder = KnowledgeBuilderFactory.newKnowledgeBuilder();
builder.add(ResourceFactory.newClassPathResource("user.drl", Test.class), ResourceType.DRL);
KnowledgeBuilderErrors errs = builder.getErrors();
if (!errs.isEmpty()) {
for (KnowledgeBuilderError e: errs) {
System.out.println(e.toString());
}
}
Collection<KnowledgePackage> col = builder.getKnowledgePackages();
base.addKnowledgePackages(col);
// user insert here is ok
// User user = new User();
// s.insert(user);
// fire
s.fireAllRules();
Exception:
Exception in thread "main" java.lang.RuntimeException: cannot invoke method: match
at org.mvel2.optimizers.impl.refl.nodes.MethodAccessor.getValue(MethodAccessor.java:63)
at org.mvel2.ast.ASTNode.getReducedValueAccelerated(ASTNode.java:108)
at org.mvel2.MVELRuntime.execute(MVELRuntime.java:85)
at org.mvel2.compiler.CompiledExpression.getValue(CompiledExpression.java:123)
at org.mvel2.MVEL.executeExpression(MVEL.java:930)
at org.drools.rule.constraint.MvelConditionEvaluator.evaluate(MvelConditionEvaluator.java:70)
at org.drools.rule.constraint.MvelConditionEvaluator.evaluate(MvelConditionEvaluator.java:49)
at org.drools.rule.constraint.MvelConstraint.evaluate(MvelConstraint.java:167)
at org.drools.rule.constraint.MvelConstraint.isAllowed(MvelConstraint.java:124)
at org.drools.reteoo.AlphaNode$ObjectSinkUpdateAdapter.assertObject(AlphaNode.java:325)
at org.drools.reteoo.ObjectTypeNode.updateSink(ObjectTypeNode.java:334)
at org.drools.reteoo.AlphaNode.updateSink(AlphaNode.java:203)
at org.drools.reteoo.LeftInputAdapterNode.attach(LeftInputAdapterNode.java:120)
at org.drools.reteoo.builder.BuildUtils.attachNode(BuildUtils.java:145)
at org.drools.reteoo.builder.GroupElementBuilder$AndBuilder.build(GroupElementBuilder.java:127)
at org.drools.reteoo.builder.GroupElementBuilder.build(GroupElementBuilder.java:71)
at org.drools.reteoo.builder.ReteooRuleBuilder.addSubRule(ReteooRuleBuilder.java:155)
at org.drools.reteoo.builder.ReteooRuleBuilder.addRule(ReteooRuleBuilder.java:128)
at org.drools.reteoo.ReteooBuilder.addRule(ReteooBuilder.java:116)
at org.drools.reteoo.ReteooRuleBase.addRule(ReteooRuleBase.java:445)
at org.drools.common.AbstractRuleBase.addRule(AbstractRuleBase.java:956)
at org.drools.common.AbstractRuleBase.addPackages(AbstractRuleBase.java:627)
at org.drools.reteoo.ReteooRuleBase.addPackages(ReteooRuleBase.java:472)
at org.drools.impl.KnowledgeBaseImpl.addKnowledgePackages(KnowledgeBaseImpl.java:150)
at user.Test.main(Test.java:36)
Caused by: java.lang.ArrayIndexOutOfBoundsException: 2
at org.mvel2.optimizers.impl.refl.nodes.MethodAccessor.executeAll(MethodAccessor.java:149)
at org.mvel2.optimizers.impl.refl.nodes.MethodAccessor.getValue(MethodAccessor.java:48)
... 24 more
--
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
11 years, 4 months
[JBoss JIRA] (AS7-3177) Method expression parameters causes MethodNotFoundException
by José Dâmaso (JIRA)
[ https://issues.jboss.org/browse/AS7-3177?page=com.atlassian.jira.plugin.s... ]
José Dâmaso commented on AS7-3177:
----------------------------------
I'm having this issue in 7.1.3 (built from source).
I have a login page that shows the login error with ExtendedFormAuthenticator valve.
This works without problems in 7.1.1.Final.
{code:xml|title=login.xhtml (excerpt)}
<f:metadata>
<f:event type="preRenderView" listener="#{loginErrorController.addErrorMessage(sessionScope.j_exception)}"/>
</f:metadata>
{code}
Backing bean:
{code:title=LoginErrorController.java}
@Named
@RequestScoped
public class LoginErrorController extends BasePageController {
public void addErrorMessage(Throwable t) {
if (t != null) {
FacesMessageUtils.error(t.getMessage());
}
}
}
{code}
Stack trace of NPE on initial login page load (sessionScope.j_exception is null):
{code}
17:03:45,868 ERROR [pt.jd.portal.web.faces.exception.DefaultExceptionHandler] (http-localhost/127.0.0.1:8080-1) An unexpected internal error has occurred: java.lang.NullPointerException
at java.lang.Class.isAssignableFrom(Native Method) [rt.jar:1.6.0_37]
at org.apache.el.util.ReflectionUtil.isAssignableFrom(ReflectionUtil.java:319) [jbossweb-7.0.17.Final.jar:]
at org.apache.el.util.ReflectionUtil.getMethod(ReflectionUtil.java:185) [jbossweb-7.0.17.Final.jar:]
at org.apache.el.parser.AstValue.invoke(AstValue.java:257) [jbossweb-7.0.17.Final.jar:]
at org.apache.el.MethodExpressionImpl.invoke(MethodExpressionImpl.java:278) [jbossweb-7.0.17.Final.jar:]
at org.jboss.weld.util.el.ForwardingMethodExpression.invoke(ForwardingMethodExpression.java:39) [weld-core-1.1.9.Final.jar:2012-08-06 19:12]
at org.jboss.weld.el.WeldMethodExpression.invoke(WeldMethodExpression.java:50) [weld-core-1.1.9.Final.jar:2012-08-06 19:12]
at com.sun.faces.facelets.el.TagMethodExpression.invoke(TagMethodExpression.java:105) [jsf-impl-2.1.11-jbossorg-3.jar:]
at com.sun.faces.facelets.tag.jsf.core.DeclarativeSystemEventListener.processEvent(EventHandler.java:128) [jsf-impl-2.1.11-jbossorg-3.jar:]
at javax.faces.component.UIComponent$ComponentSystemEventListenerAdapter.processEvent(UIComponent.java:2486) [jboss-jsf-api_2.1_spec-2.0.4.Final.jar:2.0.4.Final]
at javax.faces.event.SystemEvent.processListener(SystemEvent.java:106) [jboss-jsf-api_2.1_spec-2.0.4.Final.jar:2.0.4.Final]
at com.sun.faces.application.ApplicationImpl.processListeners(ApplicationImpl.java:2168) [jsf-impl-2.1.11-jbossorg-3.jar:]
at com.sun.faces.application.ApplicationImpl.invokeComponentListenersFor(ApplicationImpl.java:2116) [jsf-impl-2.1.11-jbossorg-3.jar:]
at com.sun.faces.application.ApplicationImpl.publishEvent(ApplicationImpl.java:288) [jsf-impl-2.1.11-jbossorg-3.jar:]
at com.sun.faces.application.ApplicationImpl.publishEvent(ApplicationImpl.java:246) [jsf-impl-2.1.11-jbossorg-3.jar:]
at org.jboss.as.weld.webtier.jsf.ForwardingApplication.publishEvent(ForwardingApplication.java:293) [jboss-as-weld-7.1.3.Final.jar:7.1.3.Final]
at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:108) [jsf-impl-2.1.11-jbossorg-3.jar:]
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101) [jsf-impl-2.1.11-jbossorg-3.jar:]
at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:139) [jsf-impl-2.1.11-jbossorg-3.jar:]
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:594) [jboss-jsf-api_2.1_spec-2.0.4.Final.jar:2.0.4.Final]
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:329) [jbossweb-7.0.17.Final.jar:]
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248) [jbossweb-7.0.17.Final.jar:]
at org.jboss.weld.servlet.WeldCrossContextFilter.doFilter(WeldCrossContextFilter.java:62) [weld-core-1.1.9.Final.jar:2012-08-06 19:12]
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:280) [jbossweb-7.0.17.Final.jar:]
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248) [jbossweb-7.0.17.Final.jar:]
at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:840) [jbossweb-7.0.17.Final.jar:]
at org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:622) [jbossweb-7.0.17.Final.jar:]
at org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:560) [jbossweb-7.0.17.Final.jar:]
at org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:488) [jbossweb-7.0.17.Final.jar:]
at org.apache.catalina.authenticator.FormAuthenticator.forwardToLoginPage(FormAuthenticator.java:362) [jbossweb-7.0.17.Final.jar:]
at org.jboss.as.web.security.ExtendedFormAuthenticator.forwardToLoginPage(ExtendedFormAuthenticator.java:127) [jboss-as-web-7.1.3.Final.jar:7.1.3.Final]
at org.apache.catalina.authenticator.FormAuthenticator.authenticate(FormAuthenticator.java:265) [jbossweb-7.0.17.Final.jar:]
at org.jboss.as.web.security.ExtendedFormAuthenticator.authenticate(ExtendedFormAuthenticator.java:78) [jboss-as-web-7.1.3.Final.jar:7.1.3.Final]
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:455) [jbossweb-7.0.17.Final.jar:]
at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:165) [jboss-as-web-7.1.3.Final.jar:7.1.3.Final]
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:155) [jbossweb-7.0.17.Final.jar:]
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) [jbossweb-7.0.17.Final.jar:]
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) [jbossweb-7.0.17.Final.jar:]
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:372) [jbossweb-7.0.17.Final.jar:]
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877) [jbossweb-7.0.17.Final.jar:]
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:679) [jbossweb-7.0.17.Final.jar:]
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:931) [jbossweb-7.0.17.Final.jar:]
at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_37]
{code}
> Method expression parameters causes MethodNotFoundException
> -----------------------------------------------------------
>
> Key: AS7-3177
> URL: https://issues.jboss.org/browse/AS7-3177
> Project: Application Server 7
> Issue Type: Bug
> Affects Versions: 7.1.0.CR1b
> Reporter: Stian Thorgersen
> Assignee: Remy Maucherat
> Fix For: 7.1.0.Final
>
>
> I have a web app that works in 7.0.2.Final, but doesn't work in 7.1.0.CR1b. The problem seems to be that method expression parameters no longer works. When trying to invoke a method with parameters the following exception is thrown:
> {code}
> 21:08:22,931 WARNING [javax.enterprise.resource.webcontainer.jsf.lifecycle] (http-localhost-127.0.0.1-8080-5) #{activeActions.select(active.parentId)}: java.lang.NullPointerException: javax.faces.FacesException: #{activeActions.select(active.serviceAgreement.parentId)}: java.lang.NullPointerException
> at com.sun.faces.application.ActionListenerImpl.processAction(ActionListenerImpl.java:110) [jsf-impl-2.1.5-jbossorg-1.jar:2.1.5-SNAPSHOT]
> at javax.faces.component.UICommand.broadcast(UICommand.java:315) [jboss-jsf-api_2.1_spec-2.0.0.Beta1.jar:2.0.0.Beta1]
> at javax.faces.component.UIViewRoot.broadcastEvents(UIViewRoot.java:794) [jboss-jsf-api_2.1_spec-2.0.0.Beta1.jar:2.0.0.Beta1]
> at javax.faces.component.UIViewRoot.processApplication(UIViewRoot.java:1259) [jboss-jsf-api_2.1_spec-2.0.0.Beta1.jar:2.0.0.Beta1]
> at com.sun.faces.lifecycle.InvokeApplicationPhase.execute(InvokeApplicationPhase.java:81) [jsf-impl-2.1.5-jbossorg-1.jar:2.1.5-SNAPSHOT]
> at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101) [jsf-impl-2.1.5-jbossorg-1.jar:2.1.5-SNAPSHOT]
> at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118) [jsf-impl-2.1.5-jbossorg-1.jar:2.1.5-SNAPSHOT]
> at javax.faces.webapp.FacesServlet.service(FacesServlet.java:593) [jboss-jsf-api_2.1_spec-2.0.0.Beta1.jar:2.0.0.Beta1]
> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:329) [jbossweb-7.0.7.Final.jar:]
> at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248) [jbossweb-7.0.7.Final.jar:]
> at org.jboss.weld.servlet.ConversationPropagationFilter.doFilter(ConversationPropagationFilter.java:62) [weld-core-1.1.4.Final.jar:2011-11-22 20:01]
> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:280) [jbossweb-7.0.7.Final.jar:]
> at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248) [jbossweb-7.0.7.Final.jar:]
> at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:275) [jbossweb-7.0.7.Final.jar:]
> at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:161) [jbossweb-7.0.7.Final.jar:]
> at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:489) [jbossweb-7.0.7.Final.jar:]
> at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:151) [jboss-as-web-7.1.0.CR1b.jar:7.1.0.CR1b]
> at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:155) [jbossweb-7.0.7.Final.jar:]
> at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) [jbossweb-7.0.7.Final.jar:]
> at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) [jbossweb-7.0.7.Final.jar:]
> at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:362) [jbossweb-7.0.7.Final.jar:]
> at org.apache.coyote.http11.Http11AprProcessor.process(Http11AprProcessor.java:897) [jbossweb-7.0.7.Final.jar:]
> at org.apache.coyote.http11.Http11AprProtocol$Http11ConnectionHandler.process(Http11AprProtocol.java:626) [jbossweb-7.0.7.Final.jar:]
> at org.apache.tomcat.util.net.AprEndpoint$Worker.run(AprEndpoint.java:2033) [jbossweb-7.0.7.Final.jar:]
> at java.lang.Thread.run(Thread.java:679) [:1.6.0_23]
> Caused by: javax.faces.el.MethodNotFoundException: java.lang.NullPointerException
> at javax.faces.component.MethodBindingMethodExpressionAdapter.invoke(MethodBindingMethodExpressionAdapter.java:104) [jboss-jsf-api_2.1_spec-2.0.0.Beta1.jar:2.0.0.Beta1]
> at com.sun.faces.application.ActionListenerImpl.processAction(ActionListenerImpl.java:102) [jsf-impl-2.1.5-jbossorg-1.jar:2.1.5-SNAPSHOT]
> ... 24 more
> Caused by: java.lang.NullPointerException
> at java.lang.Class.isAssignableFrom(Native Method) [:1.6.0_23]
> at org.apache.el.util.ReflectionUtil.isAssignableFrom(ReflectionUtil.java:299) [jbossweb-7.0.7.Final.jar:]
> at org.apache.el.util.ReflectionUtil.getMethod(ReflectionUtil.java:172) [jbossweb-7.0.7.Final.jar:]
> at org.apache.el.parser.AstValue.invoke(AstValue.java:251) [jbossweb-7.0.7.Final.jar:]
> at org.apache.el.MethodExpressionImpl.invoke(MethodExpressionImpl.java:278) [jbossweb-7.0.7.Final.jar:]
> at org.jboss.weld.util.el.ForwardingMethodExpression.invoke(ForwardingMethodExpression.java:39) [weld-core-1.1.4.Final.jar:2011-11-22 20:01]
> at org.jboss.weld.el.WeldMethodExpression.invoke(WeldMethodExpression.java:50) [weld-core-1.1.4.Final.jar:2011-11-22 20:01]
> at com.sun.faces.facelets.el.TagMethodExpression.invoke(TagMethodExpression.java:105) [jsf-impl-2.1.5-jbossorg-1.jar:2.1.5-SNAPSHOT]
> at javax.faces.component.MethodBindingMethodExpressionAdapter.invoke(MethodBindingMethodExpressionAdapter.java:88) [jboss-jsf-api_2.1_spec-2.0.0.Beta1.jar:2.0.0.Beta1]
> ... 25 more
> {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
11 years, 4 months