[JBoss JIRA] (WFCORE-1093) TempFileProviderService threads consume high CPU
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1093?page=com.atlassian.jira.plugi... ]
RH Bugzilla Integration commented on WFCORE-1093:
-------------------------------------------------
Mike McCune <mmccune(a)redhat.com> changed the Status of [bug 1277699|https://bugzilla.redhat.com/show_bug.cgi?id=1277699] from MODIFIED to POST
> TempFileProviderService threads consume high CPU
> ------------------------------------------------
>
> Key: WFCORE-1093
> URL: https://issues.jboss.org/browse/WFCORE-1093
> Project: WildFly Core
> Issue Type: Bug
> Components: Server
> Reporter: Aaron Ogburn
> Assignee: Jason Greene
> Fix For: 2.0.3.Final
>
>
> TempFileProviderService threads consume high CPU as they poll their non empty task queue. This is ultimately due to a flaw in the JDK ThreadPoolExecutor code (https://bugs.openjdk.java.net/browse/JDK-8129861), impacting ScheduledThreadPoolExecutors that use a core size of 0 and a default 0 keepalive timeout.
> While the executor queue is not empty, the executor does not allow the pool to go below 1 thread. So the one remaining work thread keeps looping over its poll call with a 0 timeout. Options to protect JBoss from this are:
> 1) Set a keepalive timeout on the executor so the poll has a duration and the worker run loop isn't so busy
> 2) Or set the Executor core pool size to >0. The worker thread would then use a blocking take() call on its queue instead of a constant 0 second poll calls. The side effect of this change is that the thread pool wouldn't ever drop back down to 0.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (WFLY-6152) EJB timer scheduler log an Exception for an already canceled timer
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-6152?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-6152:
-----------------------------------------------
Sat6QE Jenkins <sat6-jenkins(a)redhat.com> changed the Status of [bug 1305960|https://bugzilla.redhat.com/show_bug.cgi?id=1305960] from POST to MODIFIED
> EJB timer scheduler log an Exception for an already canceled timer
> ------------------------------------------------------------------
>
> Key: WFLY-6152
> URL: https://issues.jboss.org/browse/WFLY-6152
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 8.0.0.Final
> Reporter: Wolf-Dieter Fink
> Assignee: Wolf-Dieter Fink
> Priority: Minor
> Labels: timer, timers, timerservice
>
> If a timer is canceled inside of the @timeout method the scheduler will log an ERROR if the timer duration is longer than the intervall and an overlapping execution should be fired.
> This is due to internal validatons.
> This will not happen if the timer is canceled by an external process, here the scheduler is removed.
> The log message is like this:
> ERROR [org.jboss.as.ejb3] (EJB default - 3) WFLYEJB0164: Exception running timer task for timer [id=0bd9870b-568b-42f5-9bda-e1525c3500aa timedObjectId=ejb30-timer.ejb30-timer.SimpleTimerBean auto-timer?:false persistent?:true timerService=org.jboss.as.ejb3.timerservice.TimerServiceImpl@53ba1a7f initialExpiration=Tue Feb 09 17:19:32 CET 2016 intervalDuration(in milli sec)=5000 nextExpiration=Tue Feb 09 17:19:37 CET 2016 timerState=CANCELED info=SimpleTimerInfo description=A timer started every 5 seconds] on EJB ejb30-timer.ejb30-timer.SimpleTimerBean: javax.ejb.NoSuchObjectLocalException: WFLYEJB0331: Timer was canceled
> at org.jboss.as.ejb3.timerservice.TimerImpl.assertTimerState(TimerImpl.java:459)
> at org.jboss.as.ejb3.timerservice.TimerImpl.isPersistent(TimerImpl.java:215)
> at org.jboss.as.ejb3.timerservice.TimerServiceImpl.shouldRun(TimerServiceImpl.java:1117)
> at org.jboss.as.ejb3.timerservice.TimerTask.run(TimerTask.java:124)
> at org.jboss.as.ejb3.timerservice.TimerServiceImpl$Task$1.run(TimerServiceImpl.java:1221)
> at org.wildfly.extension.requestcontroller.RequestController$QueuedTask$1.run(RequestController.java:497)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (WFCORE-273) ServerInventory#reconnectServer should take auto-start into account
by Ken Wills (JIRA)
[ https://issues.jboss.org/browse/WFCORE-273?page=com.atlassian.jira.plugin... ]
Ken Wills edited comment on WFCORE-273 at 3/28/16 6:25 PM:
-----------------------------------------------------------
Here are the oucomes with --restart-servers
|| || auto-start || reload --restart-servers= || Current Status || Outcome || Existing Config / add with CLI || Comments ||
|| 1 || default (true)|| not specified || running || stopped & started || (existing config) ||
|| 2 || default (true)|| not specified || not running || started || (existing config) ||
|| 3 || default (true)|| false || not running || started || (existing config) || Should this be started with --restart-servers=false? ||
|| 4 || default (true)|| true || running || stopped & started || (existing config) ||
|| 5 || false || not specified || running || stopped & not started || (existing config) ||
|| 6 || false || true || running || stopped & not started || (existing config) ||
|| 7 || false || false || running || not stopped & still running || (existing config) ||
|| 8 || true || false || not running || started || (added new server) || Should this be started with --restart-servers=false? (same as 3) ||
|| 9 || false || false || not running || not started || (added new server) ||
|| 10 || false || false || running || running || (added new server & started manually) ||
|| 11 || false || true || running || stopped & not started || (added new server & started manually) ||
So I think we'd want to think about 3 and 11
(3) If an auto-start server has been stopped, and restart-servers=false, should it restart the stopped server? (I think no.)
(11) for a new auto-start=false server, restart-servers=true doesn't start the server if it is currently running (it is stopped though). This might be ok though, as it was explicitly added with auto-start = false. (Edit, never mind 11, this behavior makes sense.)
was (Author: luck3y):
Here are the oucomes with --restart-servers
|| || auto-start || reload --restart-servers= || Current Status || Outcome || Existing Config / add with CLI || Comments ||
|| 1 || default (true)|| not specified || running || stopped & started || (existing config) ||
|| 2 || default (true)|| not specified || not running || started || (existing config) ||
|| 3 || default (true)|| false || not running || started || (existing config) || Should this be started with --restart-servers=false? ||
|| 4 || default (true)|| true || running || stopped & started || (existing config) ||
|| 5 || false || not specified || running || stopped & not started || (existing config) ||
|| 6 || false || true || running || stopped & not started || (existing config) ||
|| 7 || false || false || running || not stopped & still running || (existing config) ||
|| 8 || true || false || not running || started || (added new server) || Should this be started with --restart-servers=false? (same as 3) ||
|| 9 || false || false || not running || not started || (added new server) ||
|| 10 || false || false || running || running || (added new server & started manually) ||
|| 11 || false || true || running || stopped & not started || (added new server & started manually) ||
So I think we'd want to think about 3 and 11
(3) If an auto-start server has been stopped, and restart-servers=false, should it restart the stopped server? (I think no.)
(11) for a new auto-start=true server, restart-servers=true doesn't start the server. This might be ok though, as it was explicitly added with auto-start = false. (Edit, never mind 11, this behaviour makes sense.)
> ServerInventory#reconnectServer should take auto-start into account
> -------------------------------------------------------------------
>
> Key: WFCORE-273
> URL: https://issues.jboss.org/browse/WFCORE-273
> Project: WildFly Core
> Issue Type: Task
> Components: Domain Management
> Reporter: Emanuel Muckenhuber
> Assignee: Ken Wills
> Fix For: 3.0.0.Alpha1
>
>
> When reconnecting to stopped (but not removed) servers, the ServerInventory should take the auto-start property into account. Otherwise the process will just get removed, however started with the next :reload of the HC.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (WFCORE-273) ServerInventory#reconnectServer should take auto-start into account
by Ken Wills (JIRA)
[ https://issues.jboss.org/browse/WFCORE-273?page=com.atlassian.jira.plugin... ]
Ken Wills edited comment on WFCORE-273 at 3/28/16 6:24 PM:
-----------------------------------------------------------
Actually, I think I may have been able to figure out how to cause this (well, I mean "this" as in there are probably other states like this):
(1) Start master & slave HCs
(2) kill master HC
(3) connect to slave HC and start a non-auto-start server
(4) restart master HC
(5) server shows up in master as disabled, but is running.
*edit*, never mind, now it seems to be working, was just the registration retry delay I think.
was (Author: luck3y):
Actually, I think I may have been able to figure out how to cause this (well, I mean "this" as in there are probably other states like this):
(1) Start master & slave HCs
(2) kill master HC
(3) connect to slave HC and start a non-auto-start server
(4) restart master HC
(5) server shows up in master as disabled, but is running.
*edit*, never mind, now it seems to be working.
> ServerInventory#reconnectServer should take auto-start into account
> -------------------------------------------------------------------
>
> Key: WFCORE-273
> URL: https://issues.jboss.org/browse/WFCORE-273
> Project: WildFly Core
> Issue Type: Task
> Components: Domain Management
> Reporter: Emanuel Muckenhuber
> Assignee: Ken Wills
> Fix For: 3.0.0.Alpha1
>
>
> When reconnecting to stopped (but not removed) servers, the ServerInventory should take the auto-start property into account. Otherwise the process will just get removed, however started with the next :reload of the HC.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (WFCORE-273) ServerInventory#reconnectServer should take auto-start into account
by Ken Wills (JIRA)
[ https://issues.jboss.org/browse/WFCORE-273?page=com.atlassian.jira.plugin... ]
Ken Wills edited comment on WFCORE-273 at 3/28/16 6:23 PM:
-----------------------------------------------------------
Here are the oucomes with --restart-servers
|| || auto-start || reload --restart-servers= || Current Status || Outcome || Existing Config / add with CLI || Comments ||
|| 1 || default (true)|| not specified || running || stopped & started || (existing config) ||
|| 2 || default (true)|| not specified || not running || started || (existing config) ||
|| 3 || default (true)|| false || not running || started || (existing config) || Should this be started with --restart-servers=false? ||
|| 4 || default (true)|| true || running || stopped & started || (existing config) ||
|| 5 || false || not specified || running || stopped & not started || (existing config) ||
|| 6 || false || true || running || stopped & not started || (existing config) ||
|| 7 || false || false || running || not stopped & still running || (existing config) ||
|| 8 || true || false || not running || started || (added new server) || Should this be started with --restart-servers=false? (same as 3) ||
|| 9 || false || false || not running || not started || (added new server) ||
|| 10 || false || false || running || running || (added new server & started manually) ||
|| 11 || false || true || running || stopped & not started || (added new server & started manually) ||
So I think we'd want to think about 3 and 11
(3) If an auto-start server has been stopped, and restart-servers=false, should it restart the stopped server? (I think no.)
(11) for a new auto-start=true server, restart-servers=true doesn't start the server. This might be ok though, as it was explicitly added with auto-start = false. (Edit, never mind 11, this behaviour makes sense.)
was (Author: luck3y):
Here are the oucomes with --restart-servers
|| || auto-start || reload --restart-servers= || Current Status || Outcome || Existing Config / add with CLI || Comments ||
|| 1 || default (true)|| not specified || running || stopped & started || (existing config) ||
|| 2 || default (true)|| not specified || not running || started || (existing config) ||
|| 3 || default (true)|| false || not running || started || (existing config) || Should this be started with --restart-servers=false? ||
|| 4 || default (true)|| true || running || stopped & started || (existing config) ||
|| 5 || false || not specified || running || stopped & not started || (existing config) ||
|| 6 || false || true || running || stopped & not started || (existing config) ||
|| 7 || false || false || running || not stopped & still running || (existing config) ||
|| 8 || true || false || not running || started || (added new server) || Should this be started with --restart-servers=false? (same as 3) ||
|| 9 || false || false || not running || not started || (added new server) ||
|| 10 || false || false || running || running || (added new server & started manually) ||
|| 11 || false || true || running || stopped & not started || (added new server & started manually) ||
So I think we'd want to think about 3 and 11
(3) If an auto-start server has been stopped, and restart-servers=false, should it restart the stopped server? (I think no.)
(11) for a new auto-start=true server, restart-servers=true doesn't start the server. This might be ok though, as it was explicitly added with auto-start = false.
> ServerInventory#reconnectServer should take auto-start into account
> -------------------------------------------------------------------
>
> Key: WFCORE-273
> URL: https://issues.jboss.org/browse/WFCORE-273
> Project: WildFly Core
> Issue Type: Task
> Components: Domain Management
> Reporter: Emanuel Muckenhuber
> Assignee: Ken Wills
> Fix For: 3.0.0.Alpha1
>
>
> When reconnecting to stopped (but not removed) servers, the ServerInventory should take the auto-start property into account. Otherwise the process will just get removed, however started with the next :reload of the HC.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (WFCORE-1304) WFLYCTL0013: Operation ("clean-obsolete-content") failed .. StringIndexOutOfBoundsException when OS puts metadata files in content repo
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1304?page=com.atlassian.jira.plugi... ]
RH Bugzilla Integration commented on WFCORE-1304:
-------------------------------------------------
Sat6QE Jenkins <sat6-jenkins(a)redhat.com> changed the Status of [bug 1299189|https://bugzilla.redhat.com/show_bug.cgi?id=1299189] from POST to MODIFIED
> WFLYCTL0013: Operation ("clean-obsolete-content") failed .. StringIndexOutOfBoundsException when OS puts metadata files in content repo
> ---------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-1304
> URL: https://issues.jboss.org/browse/WFCORE-1304
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Reporter: Brad Maxwell
> Assignee: Chao Wang
> Fix For: 2.0.8.Final
>
>
> Mac OS can put .DS_Store files into the content repo directory. This can also be reproduced on Linux by creating a file under the content dir and when clean-obsolete-content() runs it will log this error. It seems it runs every 10 minutes.
> {code}
> 22:59:48,289 INFO [org.jboss.as.repository] (ServerService Thread Pool -- 1) WFLYDR0009: Content /Users/bradley/Desktop/wildfly-10.0.0.CR5/standalone/data/content/9b/.DS_Store is obsolete and will be removed
> 22:59:48,290 ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 1) WFLYCTL0013: Operation ("clean-obsolete-content") failed - address: ([]): java.lang.StringIndexOutOfBoundsException: String index out of range: 11
> at java.lang.String.charAt(String.java:658)
> at org.jboss.as.repository.HashUtil.hexStringToByteArray(HashUtil.java:62)
> at org.jboss.as.repository.ContentReference.getHash(ContentReference.java:68)
> at org.jboss.as.repository.ContentRepository$Factory$ContentRepositoryImpl.removeContent(ContentRepository.java:365)
> at org.jboss.as.repository.ContentRepository$Factory$ContentRepositoryImpl.markAsObsolete(ContentRepository.java:427)
> at org.jboss.as.repository.ContentRepository$Factory$ContentRepositoryImpl.cleanObsoleteContent(ContentRepository.java:403)
> at org.jboss.as.server.operations.CleanObsoleteContentHandler.execute(CleanObsoleteContentHandler.java:76)
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:890)
> at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:659)
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:370)
> at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1344)
> at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:392)
> at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:204)
> at org.jboss.as.controller.ModelControllerImpl$3.execute(ModelControllerImpl.java:659)
> at org.jboss.as.controller.ModelControllerImpl$3.execute(ModelControllerImpl.java:649)
> at org.jboss.as.server.deployment.ContentRepositoryCleaner.cleanObsoleteContent(ContentRepositoryCleaner.java:132)
> at org.jboss.as.server.deployment.ContentRepositoryCleaner$ContentRepositoryCleanerTask.run(ContentRepositoryCleaner.java:67)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> 22:59:48,292 ERROR [org.jboss.as.server] (ServerService Thread Pool -- 1) WFLYSRV0216: Error cleaning obsolete content WFLYCTL0158: Operation handler failed: java.lang.StringIndexOutOfBoundsException: String index out of range: 11
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (WFCORE-591) revertReloadRequired() throws a NPE is reloadRequired has not been called
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFCORE-591?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on WFCORE-591:
------------------------------------------------
Sat6QE Jenkins <sat6-jenkins(a)redhat.com> changed the Status of [bug 1294591|https://bugzilla.redhat.com/show_bug.cgi?id=1294591] from POST to MODIFIED
> revertReloadRequired() throws a NPE is reloadRequired has not been called
> -------------------------------------------------------------------------
>
> Key: WFCORE-591
> URL: https://issues.jboss.org/browse/WFCORE-591
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 1.0.0.Alpha19
> Reporter: Jeff Mesnil
> Assignee: Jeff Mesnil
> Fix For: 1.0.0.Beta1
>
>
> If an operation step handler calls org.jboss.as.controller.OperationContext#revertReloadRequired() when org.jboss.as.controller.OperationContext#reloadRequired() has not been called, it throws a NPE:
> {noformat}
> java.lang.NullPointerException
> at org.jboss.as.controller.ControlledProcessState.revertReloadRequired(ControlledProcessState.java:181)
> at org.jboss.as.controller.AbstractOperationContext.revertReloadRequired(AbstractOperationContext.java:1037)
> at org.jboss.as.controller.test.RevertReloadRequiredTestCase$TestResourceAddHandler.rollbackRuntime(RevertReloadRequiredTestCase.java:98)
> at org.jboss.as.controller.AbstractAddStepHandler$1$1.handleRollback(AbstractAddStepHandler.java:133)
> at org.jboss.as.controller.AbstractOperationContext$RollbackDelegatingResultHandler.handleResult(AbstractOperationContext.java:1419)
> at org.jboss.as.controller.AbstractOperationContext$Step.invokeResultHandler(AbstractOperationContext.java:1385)
> at org.jboss.as.controller.AbstractOperationContext$Step.handleResult(AbstractOperationContext.java:1367)
> at org.jboss.as.controller.AbstractOperationContext$Step.finalizeInternal(AbstractOperationContext.java:1323)
> at org.jboss.as.controller.AbstractOperationContext$Step.finalizeStep(AbstractOperationContext.java:1283)
> at org.jboss.as.controller.AbstractOperationContext$Step.access$300(AbstractOperationContext.java:1172)
> at org.jboss.as.controller.AbstractOperationContext.finishStep(AbstractOperationContext.java:929)
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:877)
> at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:601)
> at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:354)
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:330)
> at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1182)
> at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:362)
> at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:205)
> {noformat}
> The NPE is caused by this.activeStep.restartStamp field which is set only when reloadRequired() (or restartRequired()) is called.
> My OSH may call reloadRequired() or not depending on some runtime state and I could add some logic to make sure I call
> I can fix my handle to check that I call context.revertReloadRequired() only I had previously called reloadRequired () first.
> However, in order to make the OperationContext more robust, I think that the revertReloadRequired() method should instead be a no-op if there is no reload required.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (WFCORE-1257) support query filter implementation in MBeanServerConnection
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1257?page=com.atlassian.jira.plugi... ]
RH Bugzilla Integration commented on WFCORE-1257:
-------------------------------------------------
Sat6QE Jenkins <sat6-jenkins(a)redhat.com> changed the Status of [bug 1294010|https://bugzilla.redhat.com/show_bug.cgi?id=1294010] from POST to MODIFIED
> support query filter implementation in MBeanServerConnection
> ------------------------------------------------------------
>
> Key: WFCORE-1257
> URL: https://issues.jboss.org/browse/WFCORE-1257
> Project: WildFly Core
> Issue Type: Bug
> Components: JMX
> Affects Versions: 2.0.5.Final
> Reporter: Chao Wang
> Assignee: Brian Stansberry
> Fix For: 2.0.8.Final
>
>
> There is no implementation for query filter in MBeanServerConnection, marked as TODO
> {code:title=ModelControllerMBeanHelper.java|borderStyle=solid}
> Set<ObjectName> queryNames(final ObjectName name, final QueryExp query) {
> return new RootResourceIterator<Set<ObjectName>>(accessControlUtil, getRootResourceAndRegistration().getResource(),
> new ObjectNameMatchResourceAction<Set<ObjectName>>(name) {
> Set<ObjectName> set = new HashSet<ObjectName>();
> @Override
> public boolean onResource(ObjectName resourceName) {
> if (name == null || name.apply(resourceName)) {
> //TODO check query
> set.add(resourceName);
> }
> return true;
> }
> @Override
> public Set<ObjectName> getResult() {
> if (set.size() == 1 && set.contains(ModelControllerMBeanHelper.createRootObjectName(domain))) {
> return Collections.emptySet();
> }
> return set;
> }
> }).iterate();
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (JBEE-161) BeanELResolver does not support methods that use varargs
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/JBEE-161?page=com.atlassian.jira.plugin.s... ]
RH Bugzilla Integration commented on JBEE-161:
----------------------------------------------
Sat6QE Jenkins <sat6-jenkins(a)redhat.com> changed the Status of [bug 1292891|https://bugzilla.redhat.com/show_bug.cgi?id=1292891] from POST to MODIFIED
> BeanELResolver does not support methods that use varargs
> --------------------------------------------------------
>
> Key: JBEE-161
> URL: https://issues.jboss.org/browse/JBEE-161
> Project: JBoss JavaEE Spec APIs
> Issue Type: Bug
> Components: jboss-el-api
> Environment: jboss-el-api_2.2_spec-1.0.4.Final-redhat-1
> Reporter: Ingo Weiss
> Assignee: Scott Marlow
> Labels: el
> Fix For: jboss-el-api_3.0_spec-1.0.6.Final
>
> Attachments: beanELResolver4VarArgs.zip
>
>
> When passing BeanELResolver a method that uses varargs, BeanELResolver throws the following exception:
> {code}
> java.lang.IllegalArgumentException: wrong number of arguments
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at javax.el.BeanELResolver.invokeMethod(BeanELResolver.java:834)
> at javax.el.BeanELResolver.invoke(BeanELResolver.java:527)
> at org.apache.el.parser.AstValue.getValue(AstValue.java:156)
> at BeanELResolverTest.readExpressionValue(BeanELResolverTest.java:32)
> at BeanELResolverTest.testMethodWithFixArgumentList(BeanELResolverTest.java:21)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years