[JBoss JIRA] (WFLY-4324) While starting Jboss AS getting IllegalStateException.
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-4324?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar commented on WFLY-4324:
-----------------------------------
Looking at stacktrace this is EAP 6.3
there was discussion about this on forums https://developer.jboss.org/thread/239009
on semi related note, I hope that "tools.jar" you have in your deployment is not from JDK....
> While starting Jboss AS getting IllegalStateException.
> ------------------------------------------------------
>
> Key: WFLY-4324
> URL: https://issues.jboss.org/browse/WFLY-4324
> Project: WildFly
> Issue Type: Bug
> Environment: Java with 1.8 v and JBOS 7
> Reporter: ANKUSH NIKHAR
>
> Hi,
> I am facing issue when I am trying to deploy web service on Jboss 7 and using jdk 1.8 version. Below are the sample log :
> This issue does not impact the processing of my code execution. Is this just warning or will it harm in future.
> I am migrating my project from jdk1.7 to 1.8.
> When I try to deploy WS with jdk1.7, I didn't get such error.
> 18:56:01,032 WARN [org.jboss.as.server.deployment] (MSC service thread 1-1) JBAS015852: Could not index class sun/applet/AppletPanel.class at /D:/Test Eclipse/Migration Eclipse/Mig Workspace/CDLibrary/CDLibrary-test/content/InMemory.war/WEB-INF/lib/tools.jar: java.lang.IllegalStateException: Unknown tag! pos=1006 poolCount = 1018
> at org.jboss.jandex.Indexer.processConstantPool(Indexer.java:606) [jandex-1.0.3.Final-redhat-2.jar:1.0.3.Final-redhat-2]
> at org.jboss.jandex.Indexer.index(Indexer.java:640) [jandex-1.0.3.Final-redhat-2.jar:1.0.3.Final-redhat-2]
> at org.jboss.as.server.deployment.annotation.ResourceRootIndexer.indexResourceRoot(ResourceRootIndexer.java:100) [jboss-as-server-7.4.0.Final-redhat-19.jar:7.4.0.Final-redhat-19]
> at org.jboss.as.server.deployment.annotation.AnnotationIndexProcessor.deploy(AnnotationIndexProcessor.java:51) [jboss-as-server-7.4.0.Final-redhat-19.jar:7.4.0.Final-redhat-19]
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:159) [jboss-as-server-7.4.0.Final-redhat-19.jar:7.4.0.Final-redhat-19]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1980) [jboss-msc-1.1.5.Final-redhat-1.jar:1.1.5.Final-redhat-1]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1913) [jboss-msc-1.1.5.Final-redhat-1.jar:1.1.5.Final-redhat-1]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_31]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_31]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_31]
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
8 years, 3 months
[JBoss JIRA] (DROOLS-707) NullPointer when changing order of the rules
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-707?page=com.atlassian.jira.plugin... ]
Mario Fusco commented on DROOLS-707:
------------------------------------
Francesco,
I'm giving a look at the other test cases in your pull request and for now I just have 2 comments:
1. Those test cases are totally unrelated with the issue originally reported in this ticket (that was caused by the presence of an or that wasn't correctly desugared) so I won't reopen the ticket (eventually I'll create a different one).
2. All the new test cases actually contain an invalid drl (the variable $list is always defined twice) so the expected outcome from all of them is a compilation failure saying "Duplicate declaration for variable '$list'" as at the moment happens only for the 3rd of them.
Please confirm you agree with what I wrote above, especially with point 2.
> NullPointer when changing order of the rules
> --------------------------------------------
>
> Key: DROOLS-707
> URL: https://issues.jboss.org/browse/DROOLS-707
> Project: Drools
> Issue Type: Bug
> Affects Versions: 5.5.0.Final, 5.6.0.Final, 6.0.0.Final, 6.0.1.Final, 6.1.0.Final, 6.2.0.CR4
> Reporter: Francesco Peloi
> Assignee: Mario Fusco
> Fix For: 6.2.0.Final
>
>
> Hi there,
> we are having some serious issues with some rules, they are throwing a NullPointerException and we don't understand why. I have tried to narrow down the problem to the smallest rule possible, now this rule doesn't really make much sense put like this but the real rule is more complex with more constraints. At the end the result is the same: a NPE.
> I have tried it with many Drools versions from 5.x to latest 6.3.0-SNAPSHOT.
> I tested this in isolation with the minimum amount of code possible, and attached it as well if someone wants to try it quickly.
> Note that if line 2 of the when:
> $a : Integer()
> is moved as first line, the rule runs ok.
> Please find the reproducer here: https://groups.google.com/forum/#!topic/drools-usage/-oNqu3l4cqE
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
8 years, 3 months
[JBoss JIRA] (DROOLS-726) MVEL named consequences don't get rewired
by Mario Fusco (JIRA)
Mario Fusco created DROOLS-726:
----------------------------------
Summary: MVEL named consequences don't get rewired
Key: DROOLS-726
URL: https://issues.jboss.org/browse/DROOLS-726
Project: Drools
Issue Type: Bug
Reporter: Mario Fusco
Assignee: Mario Fusco
MVEL named consequences don't get rewired, so if for example the named consequence inserts an instance of a declared type that instance will belong to an old (not rewired) class.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
8 years, 3 months
[JBoss JIRA] (DROOLS-707) NullPointer when changing order of the rules
by Francesco Peloi (JIRA)
[ https://issues.jboss.org/browse/DROOLS-707?page=com.atlassian.jira.plugin... ]
Francesco Peloi commented on DROOLS-707:
----------------------------------------
Thanks [~mfusco], I updated the lib you mentioned, I deleted the pull request on the 6.1.x branch and created one for master, I confirm it's happening also in there.
> NullPointer when changing order of the rules
> --------------------------------------------
>
> Key: DROOLS-707
> URL: https://issues.jboss.org/browse/DROOLS-707
> Project: Drools
> Issue Type: Bug
> Affects Versions: 5.5.0.Final, 5.6.0.Final, 6.0.0.Final, 6.0.1.Final, 6.1.0.Final, 6.2.0.CR4
> Reporter: Francesco Peloi
> Assignee: Mario Fusco
> Fix For: 6.2.0.Final
>
>
> Hi there,
> we are having some serious issues with some rules, they are throwing a NullPointerException and we don't understand why. I have tried to narrow down the problem to the smallest rule possible, now this rule doesn't really make much sense put like this but the real rule is more complex with more constraints. At the end the result is the same: a NPE.
> I have tried it with many Drools versions from 5.x to latest 6.3.0-SNAPSHOT.
> I tested this in isolation with the minimum amount of code possible, and attached it as well if someone wants to try it quickly.
> Note that if line 2 of the when:
> $a : Integer()
> is moved as first line, the rule runs ok.
> Please find the reproducer here: https://groups.google.com/forum/#!topic/drools-usage/-oNqu3l4cqE
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
8 years, 3 months
[JBoss JIRA] (WFCORE-230) Failure by ProcessController to launch a server vm is not logged
by ehsavoie Hugonnet (JIRA)
[ https://issues.jboss.org/browse/WFCORE-230?page=com.atlassian.jira.plugin... ]
ehsavoie Hugonnet commented on WFCORE-230:
------------------------------------------
Should we just log it at the server level or should some error message goes back to the HC so that it could log it?
> Failure by ProcessController to launch a server vm is not logged
> ----------------------------------------------------------------
>
> Key: WFCORE-230
> URL: https://issues.jboss.org/browse/WFCORE-230
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 1.0.0.Alpha11
> Reporter: Brian Stansberry
> Assignee: ehsavoie Hugonnet
> Fix For: 1.0.0.CR1
>
>
> In a domain configuration, if a server is associated with an incorrectly configurated jvm java-home (e.g. domain.xml -> server-groups -> jvm), it will fail silently (no error shown in logs). For example:
> ```
> <server-group name="mySrvrGrp" profile="full">
> <jvm name="my-default" java-home="/usr/java/wrongPath">
> <heap size="1024m" max-size="4096m"/>
> <permgen size="256m" max-size="256m"/>
> <stack size="256k"/>
> ```
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
8 years, 3 months
[JBoss JIRA] (JGRP-1915) JDBC_PING discovery fails when stale entries are found in the database
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1915?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1915:
--------------------------------
If a node was killed without invoking the shutdown hook, then this will happen, and you have to manually remove the crashed member's entry from the DB table.
This cannot be done by JGroups, as this would prevent merging from working. See the recent discussion on the jg-users mailing list.
> JDBC_PING discovery fails when stale entries are found in the database
> ----------------------------------------------------------------------
>
> Key: JGRP-1915
> URL: https://issues.jboss.org/browse/JGRP-1915
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.6.1
> Reporter: Patrick Haas
> Assignee: Bela Ban
>
> Node: "CHQ-PATRICKH-55008"
> Database contains two rows.. other node is dead but was unable to remove the JDBC entry.
> 1) JChannel.connect(...)
> 2) JChannel.down(Event[CONNECT_WITH_STATE_TRANSFER_USE_FLUSH])
> 3) STATE_TRANSFER -> FRAG2 -> MFC -> UFC -> GMS
> 4) GMS.down(...) calls out to joinWithStateTransfer -> joinInternal(...)
> JDBC pulls the node list from the database table.
> Ping Data:
> - CHQ-PATRICKH-3895, name=CHQ-PATRICKH-3895, addr=10.1.130.228:55503, server
> - CHQ-PATRICKH-55008, name=CHQ-PATRICKH-55008, addr=10.1.130.228:57489
> joinInternal is a never-terminating while loop:
> - down: Event.FIND_INITIAL_MBRS_EVT
> - inspect responses -- no valid join responses
> - responses are NOT empty -> does not become singletonMember
> - gets all coordinators (none)
> - Sorts all nodes by GUID in a TreeSet
> - Is first of all joiners?
> - No, another joiner is listed first
> ... repeat forever
> When the process is restarted and a node ID < than the existing db entry is generated, it successfully takes over as owner.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
8 years, 3 months
[JBoss JIRA] (WFCORE-544) Inconsistent handling of system properties.
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFCORE-544?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on WFCORE-544:
------------------------------------------------
Vladimir Dosoudil <dosoudil(a)redhat.com> changed the Status of [bug 1192467|https://bugzilla.redhat.com/show_bug.cgi?id=1192467] from MODIFIED to ON_QA
> Inconsistent handling of system properties.
> --------------------------------------------
>
> Key: WFCORE-544
> URL: https://issues.jboss.org/browse/WFCORE-544
> Project: WildFly Core
> Issue Type: Bug
> Reporter: ehsavoie Hugonnet
> Assignee: ehsavoie Hugonnet
> Fix For: 1.0.0.Alpha19
>
>
> Description of problem:
> Having a domain with a single server group and two eap hosts (all on localhost), following system property cause server to fail on startup:
> <property name="org.jbpm.designer.perspective" value="${org.jbpm.designer.perspective:full}"/>
> The problem occurs only in definition with possibility to override default value - <property name="X" value="${Y:default}"/>, where X = Y
> Please see the error message in attached server log excerpt.
> More interesting is the fact that the issue shows with domain mode only, standalone mode works with properties defined as above.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
8 years, 3 months
[JBoss JIRA] (WFCORE-520) Random NPE in org.jboss.as.controller.OperationContextImpl.createTargetAttribute
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFCORE-520?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on WFCORE-520:
------------------------------------------------
Vladimir Dosoudil <dosoudil(a)redhat.com> changed the Status of [bug 1192181|https://bugzilla.redhat.com/show_bug.cgi?id=1192181] from MODIFIED to ON_QA
> Random NPE in org.jboss.as.controller.OperationContextImpl.createTargetAttribute
> --------------------------------------------------------------------------------
>
> Key: WFCORE-520
> URL: https://issues.jboss.org/browse/WFCORE-520
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 1.0.0.Alpha9
> Reporter: Brad Maxwell
> Assignee: Brian Stansberry
> Fix For: 1.0.0.Alpha19
>
> Attachments: JMXTest.java, server.log
>
>
> A NullPointerException randomly occurs in org.jboss.as.controller.OperationContextImpl.createTargetAttribute(OperationContextImpl.java:1172) when getMBeanCount is called over and over.
> See attached server.log and reproducer
> {noformat}
> 00:16:01,315 ERROR [org.jboss.as.controller.management-operation] (pool-2-thread-2) WFLYCTL0013: Operation ("check-default-resource-access") failed - address: ([
> ("core-service" => "management"),
> ("service" => "management-operations"),
> ("active-operation" => "-1652526387")
> ]): java.lang.NullPointerException
> at org.jboss.as.controller.OperationContextImpl.createTargetAttribute(OperationContextImpl.java:1172) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> at org.jboss.as.controller.OperationContextImpl.authorizeResource(OperationContextImpl.java:1136) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> at org.jboss.as.controller.OperationContextImpl.authorizeResource(OperationContextImpl.java:130) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> at org.jboss.as.controller.operations.global.ReadResourceDescriptionHandler$CheckResourceAccessHandler.execute(ReadResourceDescriptionHandler.java:467) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:700) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:535) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:308) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:303) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1158) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:328) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:197) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> at org.jboss.as.jmx.model.ResourceAccessControlUtil.getResourceAccess(ResourceAccessControlUtil.java:85) [wildfly-jmx-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> at org.jboss.as.jmx.model.RootResourceIterator.doIterate(RootResourceIterator.java:51) [wildfly-jmx-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> at org.jboss.as.jmx.model.RootResourceIterator.doIterate(RootResourceIterator.java:61) [wildfly-jmx-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> at org.jboss.as.jmx.model.RootResourceIterator.doIterate(RootResourceIterator.java:61) [wildfly-jmx-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> at org.jboss.as.jmx.model.RootResourceIterator.doIterate(RootResourceIterator.java:61) [wildfly-jmx-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> at org.jboss.as.jmx.model.RootResourceIterator.iterate(RootResourceIterator.java:43) [wildfly-jmx-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> at org.jboss.as.jmx.model.ModelControllerMBeanHelper.getMBeanCount(ModelControllerMBeanHelper.java:105) [wildfly-jmx-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> at org.jboss.as.jmx.model.ModelControllerMBeanServerPlugin.getMBeanCount(ModelControllerMBeanServerPlugin.java:154) [wildfly-jmx-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> at org.jboss.as.jmx.PluggableMBeanServerImpl.getMBeanCount(PluggableMBeanServerImpl.java:561) [wildfly-jmx-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> at org.jboss.as.jmx.BlockingNotificationMBeanServer.getMBeanCount(BlockingNotificationMBeanServer.java:143) [wildfly-jmx-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> at org.jboss.remotingjmx.protocol.v2.ServerProxy$GetMBeanCountHandler.handle(ServerProxy.java:655)
> at org.jboss.remotingjmx.protocol.v2.ServerCommon$MessageReciever$1$1.run(ServerCommon.java:153)
> at org.jboss.as.jmx.ServerInterceptorFactory$Interceptor$1.run(ServerInterceptorFactory.java:75) [wildfly-jmx-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> at org.jboss.as.jmx.ServerInterceptorFactory$Interceptor$1.run(ServerInterceptorFactory.java:70) [wildfly-jmx-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_51]
> at javax.security.auth.Subject.doAs(Subject.java:415) [rt.jar:1.7.0_51]
> at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:94) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> at org.jboss.as.jmx.ServerInterceptorFactory$Interceptor.handleEvent(ServerInterceptorFactory.java:70) [wildfly-jmx-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> at org.jboss.remotingjmx.protocol.v2.ServerCommon$MessageReciever$1.run(ServerCommon.java:149)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_51]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_51]
> at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51]
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
8 years, 3 months
[JBoss JIRA] (WFLY-4362) Web container (undertow) isn't able to compile JSPs containing JDK 8 specific code (lambda expressions)
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-4362?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-4362:
-----------------------------------------------
Vladimir Dosoudil <dosoudil(a)redhat.com> changed the Status of [bug 1193553|https://bugzilla.redhat.com/show_bug.cgi?id=1193553] from MODIFIED to ON_QA
> Web container (undertow) isn't able to compile JSPs containing JDK 8 specific code (lambda expressions)
> -------------------------------------------------------------------------------------------------------
>
> Key: WFLY-4362
> URL: https://issues.jboss.org/browse/WFLY-4362
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 9.0.0.Alpha1
> Environment: jdk1.8
> Reporter: Radim Hatlapatka
> Assignee: Tomaz Cerar
> Priority: Critical
> Attachments: lambda-expression-test.war
>
>
> Accessing JSP with JDK8 specific code (namely lambda expressions) fails due compilation error [1].
> It didn't help setting
> {code}
> <jsp-config source-vm="1.8" target-vm="1.8"/> in <servlet-container name="default">
> {code}
> It is caused due ecj-4.3.1.jar supports only JDKs till 1.7.
> [1]
> {noformat}
> 09:58:44,480 ERROR [io.undertow.request] (default task-1) UT005023: Exception handling request to /lambda-expression-test/jsp-with-lambdas.jsp: org.apache.jasper.JasperException: JBWEB004062: Unable to compile class for JSP:
> JBWEB004060: An error occurred at line: 10 in the jsp file: /jsp-with-lambdas.jsp
> n cannot be resolved to a variable
> 7: // System.out.println(answerToEverything);
> 8:
> 9: List<Integer> list = Arrays.asList(1, 2, 3);
> 10: Arrays.asList(1).forEach(n-> System.out.println(n));
> 11:
> 12: list.forEach(n -> response.getWriter().write("<p>" + n + "</p>"));
> 13:
> JBWEB004060: An error occurred at line: 10 in the jsp file: /jsp-with-lambdas.jsp
> Syntax error on token "-", -- expected
> 7: // System.out.println(answerToEverything);
> 8:
> 9: List<Integer> list = Arrays.asList(1, 2, 3);
> 10: Arrays.asList(1).forEach(n-> System.out.println(n));
> 11:
> 12: list.forEach(n -> response.getWriter().write("<p>" + n + "</p>"));
> 13:
> JBWEB004060: An error occurred at line: 10 in the jsp file: /jsp-with-lambdas.jsp
> n cannot be resolved to a variable
> 7: // System.out.println(answerToEverything);
> 8:
> 9: List<Integer> list = Arrays.asList(1, 2, 3);
> 10: Arrays.asList(1).forEach(n-> System.out.println(n));
> 11:
> 12: list.forEach(n -> response.getWriter().write("<p>" + n + "</p>"));
> 13:
> JBWEB004060: An error occurred at line: 12 in the jsp file: /jsp-with-lambdas.jsp
> n cannot be resolved to a variable
> 9: List<Integer> list = Arrays.asList(1, 2, 3);
> 10: Arrays.asList(1).forEach(n-> System.out.println(n));
> 11:
> 12: list.forEach(n -> response.getWriter().write("<p>" + n + "</p>"));
> 13:
> 14: %>
> 15: </body>
> JBWEB004060: An error occurred at line: 12 in the jsp file: /jsp-with-lambdas.jsp
> Syntax error on token "-", -- expected
> 9: List<Integer> list = Arrays.asList(1, 2, 3);
> 10: Arrays.asList(1).forEach(n-> System.out.println(n));
> 11:
> 12: list.forEach(n -> response.getWriter().write("<p>" + n + "</p>"));
> 13:
> 14: %>
> 15: </body>
> JBWEB004060: An error occurred at line: 12 in the jsp file: /jsp-with-lambdas.jsp
> n cannot be resolved to a variable
> 9: List<Integer> list = Arrays.asList(1, 2, 3);
> 10: Arrays.asList(1).forEach(n-> System.out.println(n));
> 11:
> 12: list.forEach(n -> response.getWriter().write("<p>" + n + "</p>"));
> 13:
> 14: %>
> 15: </body>
> JBWEB004211: Stacktrace:
> at org.apache.jasper.compiler.DefaultErrorHandler.javacError(DefaultErrorHandler.java:85) [jastow-1.0.0.Final.jar:1.0.0.Final]
> at org.apache.jasper.compiler.ErrorDispatcher.javacError(ErrorDispatcher.java:69) [jastow-1.0.0.Final.jar:1.0.0.Final]
> at org.apache.jasper.compiler.JDTCompiler.generateClass(JDTCompiler.java:451) [jastow-1.0.0.Final.jar:1.0.0.Final]
> at org.apache.jasper.compiler.Compiler.compile(Compiler.java:361) [jastow-1.0.0.Final.jar:1.0.0.Final]
> at org.apache.jasper.compiler.Compiler.compile(Compiler.java:339) [jastow-1.0.0.Final.jar:1.0.0.Final]
> at org.apache.jasper.compiler.Compiler.compile(Compiler.java:326) [jastow-1.0.0.Final.jar:1.0.0.Final]
> at org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:604) [jastow-1.0.0.Final.jar:1.0.0.Final]
> at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:309) [jastow-1.0.0.Final.jar:1.0.0.Final]
> at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:326) [jastow-1.0.0.Final.jar:1.0.0.Final]
> at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:259) [jastow-1.0.0.Final.jar:1.0.0.Final]
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final]
> at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
> at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:56) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:63) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
> at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:261) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:247) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:76) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:166) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:197) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:759) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_75]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_75]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_75]
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
8 years, 3 months