[JBoss JIRA] (DROOLS-4684) Parser and Canonical Model Compiler error on Conditional Named Consequence
by Mario Fusco (Jira)
[ https://issues.jboss.org/browse/DROOLS-4684?page=com.atlassian.jira.plugi... ]
Mario Fusco updated DROOLS-4684:
--------------------------------
Sprint: 2019 Week 44-46 (from Okt 28)
> Parser and Canonical Model Compiler error on Conditional Named Consequence
> --------------------------------------------------------------------------
>
> Key: DROOLS-4684
> URL: https://issues.jboss.org/browse/DROOLS-4684
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 7.28.0.Final
> Environment: macOS 10.14.6, OpenJDK 1.8.0_222
> Reporter: Duncan Doyle
> Assignee: Mario Fusco
> Priority: Major
>
> See reproducer here: https://github.com/DuncanDoyle/drools-conditional-named-consequence-issue
> When you use a Conditional Named Consequence {code}if{code} definition directly after an {code}accumulate{code}, Drools gives the following error when parsing the DRL:
> {code}
> [ERROR] Failed to execute goal org.kie:kie-maven-plugin:7.28.0.Final:build (default-build) on project drools-conditional-named-consequence-issue: Execution default-build of goal org.kie:kie-maven-plugin:7.28.0.Final:build failed: Unable to get KieModule, Errors Existed: Error Messages:
> [ERROR] Message [id=1, kieBase=defaultKieBase, level=ERROR, path=rules.drl, line=19, column=0
> [ERROR] text=Unable to resolve ObjectType 'if']
> [ERROR] ---
> [ERROR] Warning Messages:
> [ERROR] ---
> [ERROR] Info Messages:
> [ERROR]
> {code}
> When you add a constraint between the {code}accumulate{code} and the {code}if{code} statement of the Conditional Named Consequence, it works fine.
> Also when you try to generate the canonical model from a DRL that contains a Conditional Named Consequence, you get the following error:
> {code}
> [ERROR] Failed to execute goal org.kie:kie-maven-plugin:7.28.0.Final:generateModel (default-generateModel) on project drools-conditional-named-consequence-issue: A type incompatibility occurred while executing org.kie:kie-maven-plugin:7.28.0.Final:generateModel: org.drools.compiler.lang.descr.NamedConsequenceDescr cannot be cast to org.drools.compiler.lang.descr.PatternDescr
> {code}
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (WFLY-12725) ajp huge header
by zai xuan (Jira)
zai xuan created WFLY-12725:
-------------------------------
Summary: ajp huge header
Key: WFLY-12725
URL: https://issues.jboss.org/browse/WFLY-12725
Project: WildFly
Issue Type: Bug
Affects Versions: 18.0.0.Final
Environment: windows7
Reporter: zai xuan
Assignee: Brian Stansberry
There are long headers in the AJP connection, resulting in errors.
++++++++++++++++++++
12:44:37,327 ERROR [io.undertow.request] (default I/O-1) UT005001: An exception
occurred processing the request: java.lang.ArrayIndexOutOfBoundsException: 16
at io.undertow.server.protocol.ajp.AjpRequestParser.headers(AjpRequestPa
rser.java:490)
at io.undertow.server.protocol.ajp.AjpRequestParser.parseString(AjpReque
stParser.java:536)
at io.undertow.server.protocol.ajp.AjpRequestParser.parse(AjpRequestPars
er.java:353)
at io.undertow.server.protocol.ajp.AjpReadListener.handleEvent(AjpReadLi
stener.java:169)
at io.undertow.server.protocol.ajp.AjpReadListener.handleEvent(AjpReadLi
stener.java:56)
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java
:92)
at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(R
eadReadyHandler.java:66)
at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:89)
at org.xnio.nio.WorkerThread.run(WorkerThread.java:591)
++++++++++++++++++++
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (WFLY-12724) Improve batch thread-pool configuration to support thread-pool core-size
by Cheng Fang (Jira)
[ https://issues.jboss.org/browse/WFLY-12724?page=com.atlassian.jira.plugin... ]
Cheng Fang updated WFLY-12724:
------------------------------
Description:
The batch subsystem thread-pool currently does not allow to configure its core size. Its core size is always the same as its max size. Upon new task submission, a new thread is created up to the max thread limit, even when there are idle thread available. And pooled threads (core threads) will stay active and will not time out. Need to improve the thead pool configuration to allow for more efficient use of thread resources.
current batch subsystem schema snippet:
{code:xml}
<xs:complexType name="thread-poolType">
<xs:annotation>
<xs:documentation>
<![CDATA[
A thread pool executor with an unbounded queue. Such a thread pool has a core size and a queue with no
upper bound. When a task is submitted, if the number of running threads is less than the core size,
a new thread is created. Otherwise, the task is placed in queue. If too many tasks are allowed to be
submitted to this type of executor, an out of memory condition may occur.
The "max-threads" attribute must be used to specify the thread pool size. The nested
"keepalive-time" element may used to specify the amount of time that pool threads should
be kept running when idle; if not specified, threads will run until the executor is shut down.
The "thread-factory" element specifies the bean name of a specific thread factory to use to create worker
threads.
]]>
</xs:documentation>
</xs:annotation>
<xs:all>
<xs:element name="max-threads" type="threads:countType"/>
<xs:element name="keepalive-time" type="threads:time" minOccurs="0"/>
<xs:element name="thread-factory" type="threads:ref" minOccurs="0"/>
</xs:all>
<xs:attribute name="name" use="required" type="xs:string"/>
</xs:complexType>
{code}
Example of batch subsystem in server configuration file:
{code:xml}
<subsystem xmlns="urn:jboss:domain:batch-jberet:2.0">
<default-job-repository name="in-memory"/>
<default-thread-pool name="batch"/>
<job-repository name="in-memory">
<in-memory/>
</job-repository>
<thread-pool name="batch">
<max-threads count="10"/>
<keepalive-time time="30" unit="seconds"/>
</thread-pool>
</subsystem>
{code}
Example of batch subsystem management resources:
{code}
[standalone@localhost:9990 /] /subsystem=batch-jberet:read-resource
{
"outcome" => "success",
"result" => {
"restart-jobs-on-resume" => true,
"security-domain" => undefined,
"default-job-repository" => "in-memory",
"default-thread-pool" => "batch",
"in-memory-job-repository" => {"in-memory" => undefined},
"jdbc-job-repository" => undefined,
"thread-factory" => undefined,
"thread-pool" => {"batch" => undefined}
}
}
{code}
was:
The batch subsystem thread-pool currently does not allow to configure its core size. Its core size is always the same as its max size. Upon new task submission, a new thread is created up to the max thread limit, even when there are idle thread available. And pooled threads (core threads) will stay active and will not time out. Need to improve the thead pool configuration to allow for more efficient use of thread resources.
current batch subsystem schema snippet:
{code:xml}
<xs:complexType name="thread-poolType">
<xs:annotation>
<xs:documentation>
<![CDATA[
A thread pool executor with an unbounded queue. Such a thread pool has a core size and a queue with no
upper bound. When a task is submitted, if the number of running threads is less than the core size,
a new thread is created. Otherwise, the task is placed in queue. If too many tasks are allowed to be
submitted to this type of executor, an out of memory condition may occur.
The "max-threads" attribute must be used to specify the thread pool size. The nested
"keepalive-time" element may used to specify the amount of time that pool threads should
be kept running when idle; if not specified, threads will run until the executor is shut down.
The "thread-factory" element specifies the bean name of a specific thread factory to use to create worker
threads.
]]>
</xs:documentation>
</xs:annotation>
<xs:all>
<xs:element name="max-threads" type="threads:countType"/>
<xs:element name="keepalive-time" type="threads:time" minOccurs="0"/>
<xs:element name="thread-factory" type="threads:ref" minOccurs="0"/>
</xs:all>
<xs:attribute name="name" use="required" type="xs:string"/>
</xs:complexType>
{code}
Example of batch subsystem in server configuration file:
{code:xml}
<subsystem xmlns="urn:jboss:domain:batch-jberet:2.0">
<default-job-repository name="in-memory"/>
<default-thread-pool name="batch"/>
<job-repository name="in-memory">
<in-memory/>
</job-repository>
<thread-pool name="batch">
<max-threads count="10"/>
<keepalive-time time="30" unit="seconds"/>
</thread-pool>
</subsystem>
{code}
Example of batch subsystem management resources:
{code}
[standalone@localhost:9990 /] /subsystem=batch-jberet:read-resource
{
"outcome" => "success",
"result" => {
"restart-jobs-on-resume" => true,
"security-domain" => undefined,
"default-job-repository" => "in-memory",
"default-thread-pool" => "batch",
"in-memory-job-repository" => {"in-memory" => undefined},
"jdbc-job-repository" => undefined,
"thread-factory" => undefined,
"thread-pool" => {"batch" => undefined}
}
}
{code}
> Improve batch thread-pool configuration to support thread-pool core-size
> ------------------------------------------------------------------------
>
> Key: WFLY-12724
> URL: https://issues.jboss.org/browse/WFLY-12724
> Project: WildFly
> Issue Type: Feature Request
> Components: Batch
> Reporter: Cheng Fang
> Assignee: Cheng Fang
> Priority: Major
>
> The batch subsystem thread-pool currently does not allow to configure its core size. Its core size is always the same as its max size. Upon new task submission, a new thread is created up to the max thread limit, even when there are idle thread available. And pooled threads (core threads) will stay active and will not time out. Need to improve the thead pool configuration to allow for more efficient use of thread resources.
> current batch subsystem schema snippet:
> {code:xml}
> <xs:complexType name="thread-poolType">
> <xs:annotation>
> <xs:documentation>
> <![CDATA[
> A thread pool executor with an unbounded queue. Such a thread pool has a core size and a queue with no
> upper bound. When a task is submitted, if the number of running threads is less than the core size,
> a new thread is created. Otherwise, the task is placed in queue. If too many tasks are allowed to be
> submitted to this type of executor, an out of memory condition may occur.
> The "max-threads" attribute must be used to specify the thread pool size. The nested
> "keepalive-time" element may used to specify the amount of time that pool threads should
> be kept running when idle; if not specified, threads will run until the executor is shut down.
> The "thread-factory" element specifies the bean name of a specific thread factory to use to create worker
> threads.
> ]]>
> </xs:documentation>
> </xs:annotation>
> <xs:all>
> <xs:element name="max-threads" type="threads:countType"/>
> <xs:element name="keepalive-time" type="threads:time" minOccurs="0"/>
> <xs:element name="thread-factory" type="threads:ref" minOccurs="0"/>
> </xs:all>
> <xs:attribute name="name" use="required" type="xs:string"/>
> </xs:complexType>
> {code}
> Example of batch subsystem in server configuration file:
> {code:xml}
> <subsystem xmlns="urn:jboss:domain:batch-jberet:2.0">
> <default-job-repository name="in-memory"/>
> <default-thread-pool name="batch"/>
> <job-repository name="in-memory">
> <in-memory/>
> </job-repository>
> <thread-pool name="batch">
> <max-threads count="10"/>
> <keepalive-time time="30" unit="seconds"/>
> </thread-pool>
> </subsystem>
> {code}
> Example of batch subsystem management resources:
> {code}
> [standalone@localhost:9990 /] /subsystem=batch-jberet:read-resource
> {
> "outcome" => "success",
> "result" => {
> "restart-jobs-on-resume" => true,
> "security-domain" => undefined,
> "default-job-repository" => "in-memory",
> "default-thread-pool" => "batch",
> "in-memory-job-repository" => {"in-memory" => undefined},
> "jdbc-job-repository" => undefined,
> "thread-factory" => undefined,
> "thread-pool" => {"batch" => undefined}
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (WFLY-12724) Improve batch thread-pool configuration to support thread-pool core-size
by Cheng Fang (Jira)
[ https://issues.jboss.org/browse/WFLY-12724?page=com.atlassian.jira.plugin... ]
Cheng Fang updated WFLY-12724:
------------------------------
Description:
The batch subsystem thread-pool currently does not allow to configure its core size. Its core size is always the same as its max size. Upon new task submission, a new thread is created up to the max thread limit, even when there are idle thread available. And pooled threads (core threads) will stay active and will not time out. Need to improve the thead pool configuration to allow for more efficient use of thread resources.
current batch subsystem schema snippet:
{code:xml}
<xs:complexType name="thread-poolType">
<xs:annotation>
<xs:documentation>
<![CDATA[
A thread pool executor with an unbounded queue. Such a thread pool has a core size and a queue with no
upper bound. When a task is submitted, if the number of running threads is less than the core size,
a new thread is created. Otherwise, the task is placed in queue. If too many tasks are allowed to be
submitted to this type of executor, an out of memory condition may occur.
The "max-threads" attribute must be used to specify the thread pool size. The nested
"keepalive-time" element may used to specify the amount of time that pool threads should
be kept running when idle; if not specified, threads will run until the executor is shut down.
The "thread-factory" element specifies the bean name of a specific thread factory to use to create worker
threads.
]]>
</xs:documentation>
</xs:annotation>
<xs:all>
<xs:element name="max-threads" type="threads:countType"/>
<xs:element name="keepalive-time" type="threads:time" minOccurs="0"/>
<xs:element name="thread-factory" type="threads:ref" minOccurs="0"/>
</xs:all>
<xs:attribute name="name" use="required" type="xs:string"/>
</xs:complexType>
{code}
Example of batch subsystem in server configuration file:
{code:xml}
<subsystem xmlns="urn:jboss:domain:batch-jberet:2.0">
<default-job-repository name="in-memory"/>
<default-thread-pool name="batch"/>
<job-repository name="in-memory">
<in-memory/>
</job-repository>
<thread-pool name="batch">
<max-threads count="10"/>
<keepalive-time time="30" unit="seconds"/>
</thread-pool>
</subsystem>
{code}
Example of batch subsystem management resources:
{code}
[standalone@localhost:9990 /] /subsystem=batch-jberet:read-resource
{
"outcome" => "success",
"result" => {
"restart-jobs-on-resume" => true,
"security-domain" => undefined,
"default-job-repository" => "in-memory",
"default-thread-pool" => "batch",
"in-memory-job-repository" => {"in-memory" => undefined},
"jdbc-job-repository" => undefined,
"thread-factory" => undefined,
"thread-pool" => {"batch" => undefined}
}
}
{code}
> Improve batch thread-pool configuration to support thread-pool core-size
> ------------------------------------------------------------------------
>
> Key: WFLY-12724
> URL: https://issues.jboss.org/browse/WFLY-12724
> Project: WildFly
> Issue Type: Feature Request
> Components: Batch
> Reporter: Cheng Fang
> Assignee: Cheng Fang
> Priority: Major
>
> The batch subsystem thread-pool currently does not allow to configure its core size. Its core size is always the same as its max size. Upon new task submission, a new thread is created up to the max thread limit, even when there are idle thread available. And pooled threads (core threads) will stay active and will not time out. Need to improve the thead pool configuration to allow for more efficient use of thread resources.
> current batch subsystem schema snippet:
> {code:xml}
> <xs:complexType name="thread-poolType">
> <xs:annotation>
> <xs:documentation>
> <![CDATA[
> A thread pool executor with an unbounded queue. Such a thread pool has a core size and a queue with no
> upper bound. When a task is submitted, if the number of running threads is less than the core size,
> a new thread is created. Otherwise, the task is placed in queue. If too many tasks are allowed to be
> submitted to this type of executor, an out of memory condition may occur.
> The "max-threads" attribute must be used to specify the thread pool size. The nested
> "keepalive-time" element may used to specify the amount of time that pool threads should
> be kept running when idle; if not specified, threads will run until the executor is shut down.
> The "thread-factory" element specifies the bean name of a specific thread factory to use to create worker
> threads.
> ]]>
> </xs:documentation>
> </xs:annotation>
> <xs:all>
> <xs:element name="max-threads" type="threads:countType"/>
> <xs:element name="keepalive-time" type="threads:time" minOccurs="0"/>
> <xs:element name="thread-factory" type="threads:ref" minOccurs="0"/>
> </xs:all>
> <xs:attribute name="name" use="required" type="xs:string"/>
> </xs:complexType>
> {code}
> Example of batch subsystem in server configuration file:
> {code:xml}
> <subsystem xmlns="urn:jboss:domain:batch-jberet:2.0">
> <default-job-repository name="in-memory"/>
> <default-thread-pool name="batch"/>
> <job-repository name="in-memory">
> <in-memory/>
> </job-repository>
> <thread-pool name="batch">
> <max-threads count="10"/>
> <keepalive-time time="30" unit="seconds"/>
> </thread-pool>
> </subsystem>
> {code}
> Example of batch subsystem management resources:
> {code}
> [standalone@localhost:9990 /] /subsystem=batch-jberet:read-resource
> {
> "outcome" => "success",
> "result" => {
> "restart-jobs-on-resume" => true,
> "security-domain" => undefined,
> "default-job-repository" => "in-memory",
> "default-thread-pool" => "batch",
> "in-memory-job-repository" => {"in-memory" => undefined},
> "jdbc-job-repository" => undefined,
> "thread-factory" => undefined,
> "thread-pool" => {"batch" => undefined}
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (WFLY-12723) Add a mp-config Galleon layer
by Brian Stansberry (Jira)
Brian Stansberry created WFLY-12723:
---------------------------------------
Summary: Add a mp-config Galleon layer
Key: WFLY-12723
URL: https://issues.jboss.org/browse/WFLY-12723
Project: WildFly
Issue Type: Enhancement
Components: MP Config
Reporter: Brian Stansberry
Assignee: Brian Stansberry
As we work on adding MP OpenAPI, MP JWT and MP FT, we're going to want to add a Galleon layer for each in order to allow customization of the precise set of functionality a user wants.
Each of these has a dependency on MP Config, so we should add a layer independent of the current 'observability' layer so the other layers can depend on config without provisioning health/metrics/opentracing.
The 'observability' layer itself would depend on mp-config.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (WFLY-12701) JSTL EL Evulation not working properly throwing NoClassDefFoundError
by Brian Stansberry (Jira)
[ https://issues.jboss.org/browse/WFLY-12701?page=com.atlassian.jira.plugin... ]
Brian Stansberry updated WFLY-12701:
------------------------------------
Fix Version/s: (was: No Release)
> JSTL EL Evulation not working properly throwing NoClassDefFoundError
> ---------------------------------------------------------------------
>
> Key: WFLY-12701
> URL: https://issues.jboss.org/browse/WFLY-12701
> Project: WildFly
> Issue Type: Bug
> Components: EE
> Affects Versions: 16.0.0.Final
> Environment: Windows
> Reporter: Akash Gupta
> Priority: Major
> Attachments: simple-servlet.war
>
>
> Following is the stacktrace of server running on wildlfy
> {code}
> 2019/10/21 17:02:09 WARN [org.jboss.modules.define] Failed to define class com.akash.web.beans.deviceBean in Module "deployment.sample.ear.sample1.war" from Service Module Loader: java.lang.NoClassDefFoundError: Failed to link com/akash/web/beans/deviceBean (Module "deployment.sample.ear.sample1.war" from Service Module Loader): com/akash/web/beans/deviceBean (wrong name: com/akash/web/beans/DeviceBean)
> at java.lang.ClassLoader.defineClass1(Native Method) [rt.jar:1.8.0_212]
> at java.lang.ClassLoader.defineClass(ClassLoader.java:763) [rt.jar:1.8.0_212]
> at java.lang.ClassLoader.defineClass(ClassLoader.java:839) [rt.jar:1.8.0_212]
> at org.jboss.modules.ModuleClassLoader.doDefineOrLoadClass(ModuleClassLoader.java:424) [jboss-modules.jar:1.9.0.Final]
> at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:555) [jboss-modules.jar:1.9.0.Final]
> at org.jboss.modules.ModuleClassLoader.loadClassLocal(ModuleClassLoader.java:339) [jboss-modules.jar:1.9.0.Final]
> at org.jboss.modules.ModuleClassLoader$1.loadClassLocal(ModuleClassLoader.java:126) [jboss-modules.jar:1.9.0.Final]
> at org.jboss.modules.Module.loadModuleClass(Module.java:731) [jboss-modules.jar:1.9.0.Final]
> at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:247) [jboss-modules.jar:1.9.0.Final]
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:410) [jboss-modules.jar:1.9.0.Final]
> at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:398) [jboss-modules.jar:1.9.0.Final]
> at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:116) [jboss-modules.jar:1.9.0.Final]
> at java.lang.Class.forName0(Native Method) [rt.jar:1.8.0_212]
> at java.lang.Class.forName(Class.java:348) [rt.jar:1.8.0_212]
> at javax.el.ImportHandler.getClassFor(ImportHandler.java:176) [jboss-el-api_3.0_spec-1.0.13.Final.jar:1.0.13.Final]
> at javax.el.ImportHandler.resolveClassFor(ImportHandler.java:165) [jboss-el-api_3.0_spec-1.0.13.Final.jar:1.0.13.Final]
> at javax.el.ImportHandler.resolveClass(ImportHandler.java:128) [jboss-el-api_3.0_spec-1.0.13.Final.jar:1.0.13.Final]
> at org.wildfly.extension.undertow.ImportedClassELResolver.getValue(ImportedClassELResolver.java:83)
> at org.apache.jasper.el.JasperELResolver.getValue(JasperELResolver.java:96) [jastow-2.0.7.Final.jar:2.0.7.Final]
> at com.sun.el.parser.AstIdentifier.getValue(AstIdentifier.java:116) [javax.el-impl-3.0.1-b08-jbossorg-1.jar:3.0.1-b08-jbossorg-1]
> at com.sun.el.parser.AstValue.getBase(AstValue.java:150) [javax.el-impl-3.0.1-b08-jbossorg-1.jar:3.0.1-b08-jbossorg-1]
> at com.sun.el.parser.AstValue.getValue(AstValue.java:199) [javax.el-impl-3.0.1-b08-jbossorg-1.jar:3.0.1-b08-jbossorg-1]
> at javax.el.ImportHandler.resolveClassFor(ImportHandler.java:161) [jboss-el-api_3.0_spec-1.0.13.Final.jar:1.0.13.Final]
> at javax.el.ImportHandler.resolveClass(ImportHandler.java:128) [jboss-el-api_3.0_spec-1.0.13.Final.jar:1.0.13.Final]
> at org.wildfly.extension.undertow.ImportedClassELResolver.getValue(ImportedClassELResolver.java:83)
> at org.apache.jasper.el.JasperELResolver.getValue(JasperELResolver.java:96) [jastow-2.0.7.Final.jar:2.0.7.Final]
> at com.sun.el.parser.AstIdentifier.getValue(AstIdentifier.java:116) [javax.el-impl-3.0.1-b08-jbossorg-1.jar:3.0.1-b08-jbossorg-1]
> at com.sun.el.parser.AstValue.getBase(AstValue.java:150) [javax.el-impl-3.0.1-b08-jbossorg-1.jar:3.0.1-b08-jbossorg-1]
> at com.sun.el.parser.AstValue.getValue(AstValue.java:199) [javax.el-impl-3.0.1-b08-jbossorg-1.jar:3.0.1-b08-jbossorg-1]
> at com.sun.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:226) [javax.el-impl-3.0.1-b08-jbossorg-1.jar:3.0.1-b08-jbossorg-1]
> at org.apache.jasper.runtime.PageContextImpl.proprietaryEvaluate(PageContextImpl.java:917) [jastow-2.0.7.Final.jar:2.0.7.Final]
> at org.apache.jsp.task_frames_jsp._jspService(task_frames_jsp.java:2641)
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (WFLY-12702) JSTL EL Evulation not working properly throwing PropertyNotFoundException
by Brian Stansberry (Jira)
[ https://issues.jboss.org/browse/WFLY-12702?page=com.atlassian.jira.plugin... ]
Brian Stansberry updated WFLY-12702:
------------------------------------
Fix Version/s: (was: No Release)
> JSTL EL Evulation not working properly throwing PropertyNotFoundException
> -------------------------------------------------------------------------
>
> Key: WFLY-12702
> URL: https://issues.jboss.org/browse/WFLY-12702
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 16.0.0.Final
> Environment: can be produced in all the enviroment
> Reporter: Akash Gupta
> Assignee: Flavia Rainone
> Priority: Major
>
> Following is the stacktrace
> 2019/10/23 16:43:33 INFO [stdout] {webui} [default task-24] 75 exception_jsp: Error in web. UUID:41f0fb82-fd7a-42bc-8df6-61f40e3aa989 User: ID:1 UserName:akash - org.apache.jasper.JasperException: javax.el.PropertyNotFoundException: Either 'name' is not a public static field of the class 'com.akash.nas.web.query.Person' or field is inacessable
> 2019/10/23 16:43:33 INFO [stdout] at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:473)
> 2019/10/23 16:43:33 INFO [stdout] at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:403)
> 2019/10/23 16:43:33 INFO [stdout] at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:347)
> 2019/10/23 16:43:33 INFO [stdout] at javax.servlet.http.HttpServlet.service(HttpServlet.java:791)
> 2019/10/23 16:43:33 INFO [stdout] at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:74)
> 2019/10/23 16:43:33 INFO [stdout] at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:81)
> 2019/10/23 16:43:33 INFO [stdout] at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
> 2019/10/23 16:43:33 INFO [stdout] at io.undertow.jsp.JspFileHandler.handleRequest(JspFileHandler.java:32)
> 2019/10/23 16:43:33 INFO [stdout] at io.undertow.servlet.handlers.ServletChain$1.handleRequest(ServletChain.java:68)
> 2019/10/23 16:43:33 INFO [stdout] at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
> 2019/10/23 16:43:33 INFO [stdout] at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 2019/10/23 16:43:33 INFO [stdout] at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 2019/10/23 16:43:33 INFO [stdout] at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 2019/10/23 16:43:33 INFO [stdout] at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:274)
> 2019/10/23 16:43:33 INFO [stdout] at io.undertow.servlet.handlers.ServletInitialHandler.dispatchToServlet(ServletInitialHandler.java:219)
> 2019/10/23 16:43:33 INFO [stdout] at io.undertow.servlet.spec.RequestDispatcherImpl.includeImpl(RequestDispatcherImpl.java:392)
> 2019/10/23 16:43:33 INFO [stdout] at io.undertow.servlet.spec.RequestDispatcherImpl.setupIncludeImpl(RequestDispatcherImpl.java:327)
> 2019/10/23 16:43:33 INFO [stdout] at io.undertow.servlet.spec.RequestDispatcherImpl.include(RequestDispatcherImpl.java:291)
> 2019/10/23 16:43:33 INFO [stdout] at org.apache.jasper.runtime.JspRuntimeLibrary.include(JspRuntimeLibrary.java:907)
> 2019/10/23 16:43:33 INFO [stdout] at org.apache.jsp.query.generic.query_resultpage_jsp._jspService(query_resultpage_jsp.java:96)
> 2019/10/23 16:43:33 INFO [stdout] at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70)
> 2019/10/23 16:43:33 INFO [stdout] at javax.servlet.http.HttpServlet.service(HttpServlet.java:791)
> 2019/10/23 16:43:33 INFO [stdout] at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:433)
> 2019/10/23 16:43:33 INFO [stdout] at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:403)
> 2019/10/23 16:43:33 INFO [stdout] at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:347)
> 2019/10/23 16:43:33 INFO [stdout] at javax.servlet.http.HttpServlet.service(HttpServlet.java:791)
> 2019/10/23 16:43:33 INFO [stdout] at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:74)
> 2019/10/23 16:43:33 INFO [stdout] at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:81)
> 2019/10/23 16:43:33 INFO [stdout] at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
> 2019/10/23 16:43:33 INFO [stdout] at io.undertow.jsp.JspFileHandler.handleRequest(JspFileHandler.java:32)
> 2019/10/23 16:43:33 INFO [stdout] at io.undertow.servlet.handlers.ServletChain$1.handleRequest(ServletChain.java:68)
> 2019/10/23 16:43:33 INFO [stdout] at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
> 2019/10/23 16:43:33 INFO [stdout] at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 2019/10/23 16:43:33 INFO [stdout] at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 2019/10/23 16:43:33 INFO [stdout] at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 2019/10/23 16:43:33 INFO [stdout] at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:274)
> 2019/10/23 16:43:33 INFO [stdout] at io.undertow.servlet.handlers.ServletInitialHandler.dispatchToServlet(ServletInitialHandler.java:219)
> 2019/10/23 16:43:33 INFO [stdout] at io.undertow.servlet.spec.RequestDispatcherImpl.includeImpl(RequestDispatcherImpl.java:392)
> 2019/10/23 16:43:33 INFO [stdout] at io.undertow.servlet.spec.RequestDispatcherImpl.setupIncludeImpl(RequestDispatcherImpl.java:327)
> 2019/10/23 16:43:33 INFO [stdout] at io.undertow.servlet.spec.RequestDispatcherImpl.include(RequestDispatcherImpl.java:291)
> 2019/10/23 16:43:33 INFO [stdout] at org.apache.jasper.runtime.JspRuntimeLibrary.include(JspRuntimeLibrary.java:907)
> 2019/10/23 16:43:33 INFO [stdout] at org.apache.jsp.policy_list_jsp._jspService(policy_list_jsp.java:188)
> 2019/10/23 16:43:33 INFO [stdout] at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70)
> 2019/10/23 16:43:33 INFO [stdout] at javax.servlet.http.HttpServlet.service(HttpServlet.java:791)
> 2019/10/23 16:43:33 INFO [stdout] at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:433)
> 2019/10/23 16:43:33 INFO [stdout] at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:403)
> 2019/10/23 16:43:33 INFO [stdout] at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:347)
> 2019/10/23 16:43:33 INFO [stdout] at javax.servlet.http.HttpServlet.service(HttpServlet.java:791)
> 2019/10/23 16:43:33 INFO [stdout] at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:74)
> 2019/10/23 16:43:33 INFO [stdout] at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:81)
> 2019/10/23 16:43:33 INFO [stdout] at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
> 2019/10/23 16:43:33 INFO [stdout] at io.undertow.jsp.JspFileHandler.handleRequest(JspFileHandler.java:32)
> 2019/10/23 16:43:33 INFO [stdout] at io.undertow.servlet.handlers.ServletChain$1.handleRequest(ServletChain.java:68)
> 2019/10/23 16:43:33 INFO [stdout] at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
> 2019/10/23 16:43:33 INFO [stdout] at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 2019/10/23 16:43:33 INFO [stdout] at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 2019/10/23 16:43:33 INFO [stdout] at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 2019/10/23 16:43:33 INFO [stdout] at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:274)
> 2019/10/23 16:43:33 INFO [stdout] at io.undertow.servlet.handlers.ServletInitialHandler.dispatchToServlet(ServletInitialHandler.java:219)
> 2019/10/23 16:43:33 INFO [stdout] at io.undertow.servlet.spec.RequestDispatcherImpl.includeImpl(RequestDispatcherImpl.java:392)
> 2019/10/23 16:43:33 INFO [stdout] at io.undertow.servlet.spec.RequestDispatcherImpl.setupIncludeImpl(RequestDispatcherImpl.java:327)
> 2019/10/23 16:43:33 INFO [stdout] at io.undertow.servlet.spec.RequestDispatcherImpl.include(RequestDispatcherImpl.java:291)
> 2019/10/23 16:43:33 INFO [stdout] at org.apache.jasper.runtime.JspRuntimeLibrary.include(JspRuntimeLibrary.java:907)
> 2019/10/23 16:43:33 INFO [stdout] at org.apache.jsp.index_jsp._jspService(index_jsp.java:402)
> 2019/10/23 16:43:33 INFO [stdout] at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70)
> 2019/10/23 16:43:33 INFO [stdout] at javax.servlet.http.HttpServlet.service(HttpServlet.java:791)
> 2019/10/23 16:43:33 INFO [stdout] at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:433)
> 2019/10/23 16:43:33 INFO [stdout] at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:403)
> 2019/10/23 16:43:33 INFO [stdout] at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:347)
> 2019/10/23 16:43:33 INFO [stdout] at javax.servlet.http.HttpServlet.service(HttpServlet.java:791)
> 2019/10/23 16:43:33 INFO [stdout] at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:74)
> 2019/10/23 16:43:33 INFO [stdout] at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:81)
> 2019/10/23 16:43:33 INFO [stdout] at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
> 2019/10/23 16:43:33 INFO [stdout] at io.undertow.jsp.JspFileHandler.handleRequest(JspFileHandler.java:32)
> 2019/10/23 16:43:33 INFO [stdout] at io.undertow.servlet.handlers.ServletChain$1.handleRequest(ServletChain.java:68)
> 2019/10/23 16:43:33 INFO [stdout] at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
> 2019/10/23 16:43:33 INFO [stdout] at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 2019/10/23 16:43:33 INFO [stdout] at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 2019/10/23 16:43:33 INFO [stdout] at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 2019/10/23 16:43:33 INFO [stdout] at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:274)
> 2019/10/23 16:43:33 INFO [stdout] at io.undertow.servlet.handlers.ServletInitialHandler.dispatchToPath(ServletInitialHandler.java:209)
> 2019/10/23 16:43:33 INFO [stdout] at io.undertow.servlet.spec.RequestDispatcherImpl.forwardImpl(RequestDispatcherImpl.java:228)
> 2019/10/23 16:43:33 INFO [stdout] at io.undertow.servlet.spec.RequestDispatcherImpl.forwardImplSetup(RequestDispatcherImpl.java:150)
> 2019/10/23 16:43:33 INFO [stdout] at io.undertow.servlet.spec.RequestDispatcherImpl.forward(RequestDispatcherImpl.java:112)
> 2019/10/23 16:43:33 INFO [stdout] at org.apache.struts.action.RequestProcessor.doForward(RequestProcessor.java:1069)
> 2019/10/23 16:43:33 INFO [stdout] at org.apache.struts.action.RequestProcessor.processForwardConfig(RequestProcessor.java:455)
> 2019/10/23 16:43:33 INFO [stdout] at org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:279)
> 2019/10/23 16:43:33 INFO [stdout] at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1487)
> 2019/10/23 16:43:33 INFO [stdout] at com.rendition.web.SentinelActionServlet.process(SentinelActionServlet.java:39)
> 2019/10/23 16:43:33 INFO [stdout] at org.apache.struts.action.ActionServlet.doGet(ActionServlet.java:505)
> 2019/10/23 16:43:33 INFO [stdout] at javax.servlet.http.HttpServlet.service(HttpServlet.java:686)
> 2019/10/23 16:43:33 INFO [stdout] at javax.servlet.http.HttpServlet.service(HttpServlet.java:791)
> 2019/10/23 16:43:33 INFO [stdout] at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:74)
> 2019/10/23 16:43:33 INFO [stdout] at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:129)
> 2019/10/23 16:43:33 INFO [stdout] at com.rendition.web.ParamFilter.doFilter(ParamFilter.java:47)
> 2019/10/23 16:43:33 INFO [stdout] at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61)
> 2019/10/23 16:43:33 INFO [stdout] at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
> 2019/10/23 16:43:33 INFO [stdout] at com.rendition.web.servlets.ResponseFilter.doFilterInternal(ResponseFilter.java:188)
> 2019/10/23 16:43:33 INFO [stdout] at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:76)
> 2019/10/23 16:43:33 INFO [stdout] at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61)
> 2019/10/23 16:43:33 INFO [stdout] at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
> 2019/10/23 16:43:33 INFO [stdout] at com.rendition.web.PermissionFilter.doFilterInternal(PermissionFilter.java:424)
> 2019/10/23 16:43:33 INFO [stdout] at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:76)
> 2019/10/23 16:43:33 INFO [stdout] at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61)
> 2019/10/23 16:43:33 INFO [stdout] at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
> 2019/10/23 16:43:33 INFO [stdout] at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:70)
> 2019/10/23 16:43:33 INFO [stdout] at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61)
> 2019/10/23 16:43:33 INFO [stdout] at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
> 2019/10/23 16:43:33 INFO [stdout] at com.rendition.web.PremiumLicenseGeneralFilter.doFilterInternal(PremiumLicenseGeneralFilter.java:38)
> 2019/10/23 16:43:33 INFO [stdout] at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:76)
> 2019/10/23 16:43:33 INFO [stdout] at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61)
> 2019/10/23 16:43:33 INFO [stdout] at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
> 2019/10/23 16:43:33 INFO [stdout] at com.akash.sw.bto.ast.security.lwsso.LWSSOFilter.doFilter(LWSSOFilter.java:99)
> 2019/10/23 16:43:33 INFO [stdout] at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61)
> 2019/10/23 16:43:33 INFO [stdout] at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
> 2019/10/23 16:43:33 INFO [stdout] at com.rendition.web.CsrfValidatorFilter.doFilter(CsrfValidatorFilter.java:49)
> 2019/10/23 16:43:33 INFO [stdout] at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61)
> 2019/10/23 16:43:33 INFO [stdout] at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
> 2019/10/23 16:43:33 INFO [stdout] at com.rendition.web.CsrfGuardFilter.doFilter(CsrfGuardFilter.java:45)
> 2019/10/23 16:43:33 INFO [stdout] at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61)
> 2019/10/23 16:43:33 INFO [stdout] at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
> 2019/10/23 16:43:33 INFO [stdout] at com.rendition.web.SecurityFilter.doFilterInternal(SecurityFilter.java:280)
> 2019/10/23 16:43:33 INFO [stdout] at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:76)
> 2019/10/23 16:43:33 INFO [stdout] at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61)
> 2019/10/23 16:43:33 INFO [stdout] at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
> 2019/10/23 16:43:33 INFO [stdout] at com.akash.ov.nms.as.owasp.NmsOwaspServletFilter.doFilter(NmsOwaspServletFilter.java:581)
> 2019/10/23 16:43:33 INFO [stdout] at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61)
> 2019/10/23 16:43:33 INFO [stdout] at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
> 2019/10/23 16:43:33 INFO [stdout] at com.rendition.web.CustomSamlFilter.doFilter(CustomSamlFilter.java:42)
> 2019/10/23 16:43:33 INFO [stdout] at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61)
> 2019/10/23 16:43:33 INFO [stdout] at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
> 2019/10/23 16:43:33 INFO [stdout] at com.rendition.web.HTTPSRedirectFilter.doFilterInternal(HTTPSRedirectFilter.java:75)
> 2019/10/23 16:43:33 INFO [stdout] at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:76)
> 2019/10/23 16:43:33 INFO [stdout] at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61)
> 2019/10/23 16:43:33 INFO [stdout] at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
> 2019/10/23 16:43:33 INFO [stdout] at org.tuckey.web.filters.urlrewrite.UrlRewriteFilter.doFilter(UrlRewriteFilter.java:404)
> 2019/10/23 16:43:33 INFO [stdout] at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61)
> 2019/10/23 16:43:33 INFO [stdout] at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
> 2019/10/23 16:43:33 INFO [stdout] at io.opentracing.contrib.jaxrs2.server.SpanFinishingFilter.doFilter(SpanFinishingFilter.java:55)
> 2019/10/23 16:43:33 INFO [stdout] at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61)
> 2019/10/23 16:43:33 INFO [stdout] at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
> 2019/10/23 16:43:33 INFO [stdout] at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:84)
> 2019/10/23 16:43:33 INFO [stdout] at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
> 2019/10/23 16:43:33 INFO [stdout] at io.undertow.servlet.handlers.ServletChain$1.handleRequest(ServletChain.java:68)
> 2019/10/23 16:43:33 INFO [stdout] at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
> 2019/10/23 16:43:33 INFO [stdout] at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> 2019/10/23 16:43:33 INFO [stdout] at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 2019/10/23 16:43:33 INFO [stdout] at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:132)
> 2019/10/23 16:43:33 INFO [stdout] at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
> 2019/10/23 16:43:33 INFO [stdout] at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 2019/10/23 16:43:33 INFO [stdout] at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:53)
> 2019/10/23 16:43:33 INFO [stdout] at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> 2019/10/23 16:43:33 INFO [stdout] at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> 2019/10/23 16:43:33 INFO [stdout] at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:59)
> 2019/10/23 16:43:33 INFO [stdout] at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
> 2019/10/23 16:43:33 INFO [stdout] at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
> 2019/10/23 16:43:33 INFO [stdout] at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
> 2019/10/23 16:43:33 INFO [stdout] at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
> 2019/10/23 16:43:33 INFO [stdout] at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 2019/10/23 16:43:33 INFO [stdout] at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> 2019/10/23 16:43:33 INFO [stdout] at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 2019/10/23 16:43:33 INFO [stdout] at org.wildfly.extension.undertow.deployment.GlobalRequestControllerHandler.handleRequest(GlobalRequestControllerHandler.java:68)
> 2019/10/23 16:43:33 INFO [stdout] at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 2019/10/23 16:43:33 INFO [stdout] at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292)
> 2019/10/23 16:43:33 INFO [stdout] at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
> 2019/10/23 16:43:33 INFO [stdout] at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
> 2019/10/23 16:43:33 INFO [stdout] at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
> 2019/10/23 16:43:33 INFO [stdout] at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
> 2019/10/23 16:43:33 INFO [stdout] at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
> 2019/10/23 16:43:33 INFO [stdout] at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105)
> 2019/10/23 16:43:33 INFO [stdout] at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
> 2019/10/23 16:43:33 INFO [stdout] at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
> 2019/10/23 16:43:33 INFO [stdout] at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
> 2019/10/23 16:43:33 INFO [stdout] at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
> 2019/10/23 16:43:33 INFO [stdout] at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
> 2019/10/23 16:43:33 INFO [stdout] at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> 2019/10/23 16:43:33 INFO [stdout] at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104)
> 2019/10/23 16:43:33 INFO [stdout] at io.undertow.server.Connectors.executeRootHandler(Connectors.java:364)
> 2019/10/23 16:43:33 INFO [stdout] at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:830)
> 2019/10/23 16:43:33 INFO [stdout] at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> 2019/10/23 16:43:33 INFO [stdout] at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982)
> 2019/10/23 16:43:33 INFO [stdout] at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
> 2019/10/23 16:43:33 INFO [stdout] at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1377)
> 2019/10/23 16:43:33 INFO [stdout] at java.lang.Thread.run(Thread.java:748)
> 2019/10/23 16:43:33 INFO [stdout] Caused by: javax.el.PropertyNotFoundException: Either 'name' is not a public static field of the class 'com.akash.nas.web.query.Person' or field is inacessable
> 2019/10/23 16:43:33 INFO [stdout] at javax.el.StaticFieldELResolver.getValue(StaticFieldELResolver.java:107)
> 2019/10/23 16:43:33 INFO [stdout] at org.apache.jasper.el.JasperELResolver.getValue(JasperELResolver.java:110)
> 2019/10/23 16:43:33 INFO [stdout] at com.sun.el.parser.AstValue.getValue(AstValue.java:139)
> 2019/10/23 16:43:33 INFO [stdout] at com.sun.el.parser.AstValue.getValue(AstValue.java:203)
> 2019/10/23 16:43:33 INFO [stdout] at com.sun.el.parser.AstGreaterThan.getValue(AstGreaterThan.java:58)
> 2019/10/23 16:43:33 INFO [stdout] at com.sun.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:226)
> 2019/10/23 16:43:33 INFO [stdout] at org.apache.jasper.runtime.PageContextImpl.proprietaryEvaluate(PageContextImpl.java:917)
> 2019/10/23 16:43:33 INFO [stdout] at org.apache.jsp.query.generic.query_navbar_jsp._jspService(query_navbar_jsp.java:139)
> 2019/10/23 16:43:33 INFO [stdout] at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70)
> 2019/10/23 16:43:33 INFO [stdout] at javax.servlet.http.HttpServlet.service(HttpServlet.java:791)
> 2019/10/23 16:43:33 INFO [stdout] at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:433)
> 2019/10/23 16:43:33 INFO [stdout] ... 183 more
> 2019/10/23 16:43:33 INFO [stdout]
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (WFLY-12486) Memory leak in OpenTracing when deployment is redeployed multiple times
by Brian Stansberry (Jira)
[ https://issues.jboss.org/browse/WFLY-12486?page=com.atlassian.jira.plugin... ]
Brian Stansberry commented on WFLY-12486:
-----------------------------------------
[~ehugonnet] FYI.
> Memory leak in OpenTracing when deployment is redeployed multiple times
> -----------------------------------------------------------------------
>
> Key: WFLY-12486
> URL: https://issues.jboss.org/browse/WFLY-12486
> Project: WildFly
> Issue Type: Bug
> Components: MP OpenTracing
> Affects Versions: 17.0.0.Final, 17.0.1.Final
> Reporter: Jan Stourac
> Assignee: Jeff Mesnil
> Priority: Critical
> Attachments: memory-leak-bad.png, memory-leak-good.png
>
>
> There seems to be a memory leak when a deployment is redeployed multiple times (100 times in our test). This is very similar to what has been described in WFLY-10991. Also first commit this started to happen is [this one|https://github.com/wildfly/wildfly/commit/74170b5f49dd83f6b9ebd489f85...] - JaegerTracing and Apache Thrift dependencies update. Thus I selected MP OpenTracing component for this issue.
> Test and deployment is same as is described in WFLY-10991.
> Size of the extra heap in use is about 27MB plus when compared to the initial size before multiple redeploy operations.
> I've tried to check manually via [visualVM|https://visualvm.github.io/] tool. Screenshot with suspicious jaegertracing instances are attached - there are much more jaegertracing class instances with new version of Jager Tracing and Apache Thrift dependencies, which is suspicious.
> Interesting thing is that when microprofile-opentracing-smallrye subsystem is removed via:
> {code}
> /subsystem=microprofile-opentracing-smallrye:remove()
> {code}
> the memory leak is still present. This is kind of confusing to me.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months