[JBoss JIRA] (AS7-3177) Method expression parameters causes MethodNotFoundException
by Remy Maucherat (JIRA)
[ https://issues.jboss.org/browse/AS7-3177?page=com.atlassian.jira.plugin.s... ]
Remy Maucherat commented on AS7-3177:
-------------------------------------
I continued to port the fixes to the method mapping algorithm from the Tomcat EL (on which I rebased), which do not have my workaround. I will investigate, the need for the null check is suspicious.
> 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
13 years, 6 months
[JBoss JIRA] (JBRULES-3707) ObjectDataCompiler converter does not compile all template rules
by Martin Weiler (JIRA)
[ https://issues.jboss.org/browse/JBRULES-3707?page=com.atlassian.jira.plug... ]
Martin Weiler closed JBRULES-3707.
----------------------------------
> ObjectDataCompiler converter does not compile all template rules
> ----------------------------------------------------------------
>
> Key: JBRULES-3707
> URL: https://issues.jboss.org/browse/JBRULES-3707
> Project: JBRULES
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: drools-compiler (expert)
> Affects Versions: 5.3.0.Final
> Environment: Windows 7 32 bit
> Eclipse version - Juno
> Java version 1.7
> Reporter: Guy Baharav
> Assignee: Mark Proctor
> Labels: Commpiler, Templates
> Attachments: Pricing.rar
>
>
> When trying to compile a rule template with a datasource of a lot of rows (more than 1000), the compilers only compiles the first 1286 lines in the datasource.
> Here is the code I am using:
> //50,000 classes are created in the collection
> Collection<FRTRule> freights = FilesLoader.GetFreightRules();
> ObjectDataCompiler converter = new ObjectDataCompiler();
> //a very simple rule template is loaded.
> final InputStream templateStream = new Object().getClass().getResourceAsStream( "/Rules/Freight.drl" );
> //only 1286 rules are created in the drl string.
> String drl = converter.compile( freights, templateStream );
> Here is the rules template syntax:
> template header
> pol
> package com.zim.pricing.rules
> import com.zim.PricingPOC.PricingUI.FRTRule;
> template Pricing
> rule "Pricing_(a){row.rowNumber}"
> when
> m : FRTRule(pol == "@{pol}")
> then
> m.setPol("1");
> end
> end template
> What could the reason be that the compiler only compiles 1286 rules?
> Thanks,
> Guy
--
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
13 years, 6 months
[JBoss JIRA] (JBRULES-3707) ObjectDataCompiler converter does not compile all template rules
by Martin Weiler (JIRA)
[ https://issues.jboss.org/browse/JBRULES-3707?page=com.atlassian.jira.plug... ]
Martin Weiler resolved JBRULES-3707.
------------------------------------
Resolution: Rejected
Not a bug, see previous comment on how to address the issue.
> ObjectDataCompiler converter does not compile all template rules
> ----------------------------------------------------------------
>
> Key: JBRULES-3707
> URL: https://issues.jboss.org/browse/JBRULES-3707
> Project: JBRULES
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: drools-compiler (expert)
> Affects Versions: 5.3.0.Final
> Environment: Windows 7 32 bit
> Eclipse version - Juno
> Java version 1.7
> Reporter: Guy Baharav
> Assignee: Mark Proctor
> Labels: Commpiler, Templates
> Attachments: Pricing.rar
>
>
> When trying to compile a rule template with a datasource of a lot of rows (more than 1000), the compilers only compiles the first 1286 lines in the datasource.
> Here is the code I am using:
> //50,000 classes are created in the collection
> Collection<FRTRule> freights = FilesLoader.GetFreightRules();
> ObjectDataCompiler converter = new ObjectDataCompiler();
> //a very simple rule template is loaded.
> final InputStream templateStream = new Object().getClass().getResourceAsStream( "/Rules/Freight.drl" );
> //only 1286 rules are created in the drl string.
> String drl = converter.compile( freights, templateStream );
> Here is the rules template syntax:
> template header
> pol
> package com.zim.pricing.rules
> import com.zim.PricingPOC.PricingUI.FRTRule;
> template Pricing
> rule "Pricing_(a){row.rowNumber}"
> when
> m : FRTRule(pol == "@{pol}")
> then
> m.setPol("1");
> end
> end template
> What could the reason be that the compiler only compiles 1286 rules?
> Thanks,
> Guy
--
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
13 years, 6 months
[JBoss JIRA] (JBRULES-3707) ObjectDataCompiler converter does not compile all template rules
by Martin Weiler (JIRA)
[ https://issues.jboss.org/browse/JBRULES-3707?page=com.atlassian.jira.plug... ]
Martin Weiler commented on JBRULES-3707:
----------------------------------------
Your template (Freight.drl) has only one template column 'pol'. So the template engine stops processing when it finds an empty value for 'pol' (= it is considered as 'tableFinished'). You can confirm that 'PORT_CODE_FROM' column in BRETEST_50000.xlsx has an empty cell at row 1289.
To avoid this kind of confusion, include a column value which always exists.
> ObjectDataCompiler converter does not compile all template rules
> ----------------------------------------------------------------
>
> Key: JBRULES-3707
> URL: https://issues.jboss.org/browse/JBRULES-3707
> Project: JBRULES
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: drools-compiler (expert)
> Affects Versions: 5.3.0.Final
> Environment: Windows 7 32 bit
> Eclipse version - Juno
> Java version 1.7
> Reporter: Guy Baharav
> Assignee: Mark Proctor
> Labels: Commpiler, Templates
> Attachments: Pricing.rar
>
>
> When trying to compile a rule template with a datasource of a lot of rows (more than 1000), the compilers only compiles the first 1286 lines in the datasource.
> Here is the code I am using:
> //50,000 classes are created in the collection
> Collection<FRTRule> freights = FilesLoader.GetFreightRules();
> ObjectDataCompiler converter = new ObjectDataCompiler();
> //a very simple rule template is loaded.
> final InputStream templateStream = new Object().getClass().getResourceAsStream( "/Rules/Freight.drl" );
> //only 1286 rules are created in the drl string.
> String drl = converter.compile( freights, templateStream );
> Here is the rules template syntax:
> template header
> pol
> package com.zim.pricing.rules
> import com.zim.PricingPOC.PricingUI.FRTRule;
> template Pricing
> rule "Pricing_(a){row.rowNumber}"
> when
> m : FRTRule(pol == "@{pol}")
> then
> m.setPol("1");
> end
> end template
> What could the reason be that the compiler only compiles 1286 rules?
> Thanks,
> Guy
--
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
13 years, 6 months
[JBoss JIRA] (AS7-6031) deploy directories not cleaned up
by Bartosz Baranowski (JIRA)
[ https://issues.jboss.org/browse/AS7-6031?page=com.atlassian.jira.plugin.s... ]
Bartosz Baranowski commented on AS7-6031:
-----------------------------------------
Well there are two issues here:
1. -Xrs -
-this leaves all exploded archives in "tmp/vfs/deploymentXXXXXXX"
- temp4%&^$@&@ + subdirs per deployment
2. without -Xrs - on CTRL+C, the archives are gone, but:
- each start of server creates temp219e868b76af43e4 like archive
- each deployment leaves empty directory
> deploy directories not cleaned up
> ---------------------------------
>
> Key: AS7-6031
> URL: https://issues.jboss.org/browse/AS7-6031
> Project: Application Server 7
> Issue Type: Bug
> Affects Versions: 7.1.3.Final (EAP)
> Reporter: Shaun Appleton
> Assignee: Bartosz Baranowski
>
> JBoss EAP 6.0.0 (and 6.0.1.ER3) doesn't clean up it's tmp/vfs directories.
> The following reproduces this -
> i) ensure run.conf has the -Xrs set
> ii) ensure deployments has a deployable .ear in it
> iii) ./run standalone.sh and allow the deployments to deploy
> iv) stop the EAP process ie kill <process_id>
> v) observe content tmp/vfs
> (The -Xrs parameter is used to "-Xrs" to prevent possible interference when JVM is running as a service and receives CTRL_LOGOFF_EVENT or SIGHUP)
> This will eventually cause problems with lack of disk space.
> Note if the -Xrs parameter content is removed but the tmp/vfs dirs stills exist. This could potentially cause inode problems.
> It would be better if there were any additional code so the temp dirs are cleaned up on start up. That would resolve both the -Xrs problem and the excessive dir creation.
--
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
13 years, 6 months
[JBoss JIRA] (JGRP-653) Streaming API for large messages
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-653?page=com.atlassian.jira.plugin.s... ]
Bela Ban commented on JGRP-653:
-------------------------------
I guess we could revisit this when we've changed to NIO2 in the transport. A new StreamableJChannel would be a selector with 1 SelectableChannel for all multicasts and 1 SelectableChannels per unicast sender. The NIO channels would be registered with the selector automatically and de-registered, e.g. when a member leaves.
SelectionKey.attachment() would contain information about the source, e.g. whether it is a multicast or unicast channel, the sender's address etc.
Header information would have to be embedded into the stream itself by the application.
Message flags are more tricky, perhaps a seperate OOB SelectableChannel per member would be needed ? Or a flag would have to be embedded into the stream as well...
> Streaming API for large messages
> --------------------------------
>
> Key: JGRP-653
> URL: https://issues.jboss.org/browse/JGRP-653
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.x
>
> Attachments: JGroupsInputStream.java, JGroupsOutputStream.java, StreamTest.java
>
>
> For large messages, to load the entire payload into memory might be bad because the payload might be bigger than the max memory available. It would be useful to have an API which allows for use of input and output streams, so that large payloads can be read iteratively by a user and streamed out to the cluster via the underlying channel breaking the data in the input stream into chunks, which are fed into the input stream on the receivers side.
> Issues: we have to have 1 input stream per sender on the receiver side, because a stream is always defined between 2 parties (sender, receiver). Maybe something like NIO, where we register interest in a stream, are notified of new streams ('accept()') and get notified when data on any of the stream is available, would be beneficial.
> Demo is attached
--
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
13 years, 6 months
[JBoss JIRA] (AS7-6255) Memory leak caused by endless piling up of delete-on-exit hooks for JMX authentication challenges
by Taras Tielkes (JIRA)
[ https://issues.jboss.org/browse/AS7-6255?page=com.atlassian.jira.plugin.s... ]
Taras Tielkes commented on AS7-6255:
------------------------------------
Indeed, looks like a duplicate.
I was not able to reproduce this issue using JBoss 7.1.3.
> 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: Darran Lofthouse
>
> 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
13 years, 6 months
[JBoss JIRA] (AS7-5582) JDK ORB Subsystem
by Michael Musgrove (JIRA)
[ https://issues.jboss.org/browse/AS7-5582?page=com.atlassian.jira.plugin.s... ]
Michael Musgrove commented on AS7-5582:
---------------------------------------
If this task will produce a maven artifact that narayana can consume then we will also need access to orb.idl. Although most platforms make orb.idl available there are some that don't (JDK 7 for Mac OS 10.7.5 and 2012-12-16-wheezy-raspbian for example). Please can you provide this idl file in the maven module that this task will generate.
> JDK ORB Subsystem
> -----------------
>
> Key: AS7-5582
> URL: https://issues.jboss.org/browse/AS7-5582
> Project: Application Server 7
> Issue Type: Feature Request
> Components: IIOP
> Reporter: Dimitris Andreadis
> Assignee: Eduardo Martins
>
> Implement a JDK ORB subsystem that can act as a replacement for the JacORB subsystem.
> AFAIK, most/all JDK ORBs are based on the Sun ORB.
> Ideally the 2 ORBs (JDK & JacORB) would be both supported in case we need to go through a transition period, or we need to support a particular interop scenario for which interop communication has issues.
--
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
13 years, 6 months
[JBoss JIRA] (AS7-6255) Memory leak caused by endless piling up of delete-on-exit hooks for JMX authentication challenges
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/AS7-6255?page=com.atlassian.jira.plugin.s... ]
Darran Lofthouse resolved AS7-6255.
-----------------------------------
Resolution: Duplicate Issue
> 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: Darran Lofthouse
>
> 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
13 years, 6 months
[JBoss JIRA] (AS7-6255) Memory leak caused by endless piling up of delete-on-exit hooks for JMX authentication challenges
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/AS7-6255?page=com.atlassian.jira.plugin.s... ]
Darran Lofthouse reassigned AS7-6255:
-------------------------------------
Assignee: Darran Lofthouse (was: Stuart Douglas)
> 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: Darran Lofthouse
>
> 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
13 years, 6 months