May 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (DROOLS-1190) Drool Modify operator causing ClassCastException

by Mario Fusco (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1190?page=com.atlassian.jira.plugi... ] Mario Fusco closed DROOLS-1190. ------------------------------- Resolution: Duplicate Issue > Drool Modify operator causing ClassCastException > ------------------------------------------------ > > Key: DROOLS-1190 > URL: https://issues.jboss.org/browse/DROOLS-1190 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 6.4.0.Final > Environment: JBoss BRMS 6.3 on EAP 6.4.6 > Reporter: gravity Blast! > Assignee: Mario Fusco > Priority: Blocker > Attachments: modify-issues.zip > > > When using the modify operator in Drools I am getting a java.lang.ClassCastException: org.adcb.finance.ResponseFact cannot be cast to org.drools.core.common.InternalFactHandle. > This seems to happen in rules that contain Arrays & using the in/not in operator on them. I have other rules using the matches regex expression and I dont get this issue. > This is a critical issue for us as we're using the RulesExecutionService in 6.4.0 to extend the KIE Execution service and are due to go live very soon so there is no chance of rolling back to 6.3.x without some heavy rework. > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6647) JNDI access control problem stack traces are excessive

by David Lloyd (JIRA)

David Lloyd created WFLY-6647: --------------------------------- Summary: JNDI access control problem stack traces are excessive Key: WFLY-6647 URL: https://issues.jboss.org/browse/WFLY-6647 Project: WildFly Issue Type: Bug Components: Naming Reporter: David Lloyd Assignee: David Lloyd Priority: Trivial Fix For: 10.1.0.Final, 11.0.0.Alpha1 JNDI lookups which trip access control issues can result in massive "Caused by" chains. A simple fix can stop this. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6173) Classes not unloaded after undeployment

by Martin Kouba (JIRA)

[ https://issues.jboss.org/browse/WFLY-6173?page=com.atlassian.jira.plugin.... ] Martin Kouba edited comment on WFLY-6173 at 5/24/16 9:47 AM: ------------------------------------------------------------- To sum it up: * undeploy does not necessarily mean class unloading - it depends on JVM settings ({{-XX:MaxMetaspaceSize}} and friends for Java8) * I've verified that after 50 deploy/undeploy cycles of the attached reproducer (and using {{-XX:MaxMetaspaceSize=128m}}): ** for WildFly 10.0.0.Final "java.lang.OutOfMemoryError: Metaspace" occurs ** for WildFly 10.1.0-SNAPSHOT (fix for WFLY-6347 merged) no OOM error occurs (metaspace is garbage collected) After examining the heap dump I've identified the {{org.jboss.el.cache.BeanPropertiesCache}} as *the root cause*. In this case, it keeps a hard reference to the {{person.joey.test.TestClientBean}} class, thus effectively blocking the relevant {{ModuleClassLoader}} from GC. Enum values are treated similarly to static constants - i.e. it's not garbage collected unless the class loader of the owner class is. That's why {{person.joey.test.RequestType}} values remain in memory. OmniFaces only amplifies the impact - as mentioned above, it holds a reference to a BeanManager. I think we can resolve/close this issue. was (Author: mkouba): To sum it up: * undeploy does not necessarily means class unloading - it depends on JVM settings ({{-XX:MaxMetaspaceSize}} and friends for Java8) * I've verified that after 50 deploy/undeploy cycles of the attached reproducer (and using {{-XX:MaxMetaspaceSize=128m}}): ** for WildFly 10.0.0.Final "java.lang.OutOfMemoryError: Metaspace" occurs ** for WildFly 10.1.0-SNAPSHOT (fix for WFLY-6347 merged) no OOM error occurs (metaspace is garbage collected) After examining the heap dump I've identified the {{org.jboss.el.cache.BeanPropertiesCache}} as *the root cause*. In this case, it keeps a hard reference to the {{person.joey.test.TestClientBean}} class, thus effectively blocking the relevant {{ModuleClassLoader}} from GC. Enum values are treated similarly to static constants - i.e. it's not garbage collected unless the class loader of the owner class is. That's why {{person.joey.test.RequestType}} values remain in memory. OmniFaces only amplifies the impact - as mentioned above, it holds a reference to a BeanManager. I think we can resolve this issue. > Classes not unloaded after undeployment > --------------------------------------- > > Key: WFLY-6173 > URL: https://issues.jboss.org/browse/WFLY-6173 > Project: WildFly > Issue Type: Bug > Components: CDI / Weld > Affects Versions: 8.2.0.Final, 10.0.0.Final > Reporter: Joey Wang > Assignee: Martin Kouba > Priority: Blocker > Fix For: 10.1.0.Final > > Attachments: memory-leak.zip > > > I deployed a small web application with one single JSF and one managed bean, accessed the page and then undeployed the application. I found the classes of this application had never been unloaded via monitoring with Java VistualVM, also using '-XX:+TraceClassUnloading' JVM option proved the classes not unloaded. > Then checking the heap dump of it, I found there were instance for each enum item (the managed bean has one enum type field, which is always initialized when the managed bean constructed) and one array instance including these enum instances. > Please refer to the attachment for the same application. I started to verify the classloader memory leak issue because we found hot redeployment of our real application swallow some memory each time, then after lots of redeployment the server was short of memories. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6646) Incorrect implementation and specification version in Manifest for wildfly-client-all-10.0.0.CR2-redhat-1-sources.jar

by Filip Kujikis (JIRA)

[ https://issues.jboss.org/browse/WFLY-6646?page=com.atlassian.jira.plugin.... ] Filip Kujikis reassigned WFLY-6646: ----------------------------------- Assignee: Filip Kujikis (was: Paul Gier) > Incorrect implementation and specification version in Manifest for wildfly-client-all-10.0.0.CR2-redhat-1-sources.jar > --------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-6646 > URL: https://issues.jboss.org/browse/WFLY-6646 > Project: WildFly > Issue Type: Enhancement > Components: Build System > Affects Versions: 10.0.0.CR2 > Reporter: Filip Kujikis > Assignee: Filip Kujikis > Priority: Minor > > Implementation and specification version in Manifest do not correspond to the JAR: wildfly-client-all-10.0.0.CR2-redhat-1-sources.jar > Corrected in Jboss EAP: https://issues.jboss.org/browse/JBEAP-1185 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6646) Incorrect implementation and specification version in Manifest for wildfly-client-all-10.0.0.CR2-redhat-1-sources.jar

by Filip Kujikis (JIRA)

[ https://issues.jboss.org/browse/WFLY-6646?page=com.atlassian.jira.plugin.... ] Filip Kujikis updated WFLY-6646: -------------------------------- Affects Version/s: 10.0.0.CR2 > Incorrect implementation and specification version in Manifest for wildfly-client-all-10.0.0.CR2-redhat-1-sources.jar > --------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-6646 > URL: https://issues.jboss.org/browse/WFLY-6646 > Project: WildFly > Issue Type: Enhancement > Components: Build System > Affects Versions: 10.0.0.CR2 > Reporter: Filip Kujikis > Assignee: Paul Gier > Priority: Minor > > Implementation and specification version in Manifest do not correspond to the JAR: wildfly-client-all-10.0.0.CR2-redhat-1-sources.jar > Corrected in Jboss EAP: https://issues.jboss.org/browse/JBEAP-1185 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6646) Incorrect implementation and specification version in Manifest for wildfly-client-all-10.0.0.CR2-redhat-1-sources.jar

by Filip Kujikis (JIRA)

Filip Kujikis created WFLY-6646: ----------------------------------- Summary: Incorrect implementation and specification version in Manifest for wildfly-client-all-10.0.0.CR2-redhat-1-sources.jar Key: WFLY-6646 URL: https://issues.jboss.org/browse/WFLY-6646 Project: WildFly Issue Type: Enhancement Components: Build System Reporter: Filip Kujikis Assignee: Paul Gier Priority: Minor Implementation and specification version in Manifest do not correspond to the JAR: wildfly-client-all-10.0.0.CR2-redhat-1-sources.jar Corrected in Jboss EAP: https://issues.jboss.org/browse/JBEAP-1185 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3149) Windows service on 64 bit systems cannot be stopped

by Nicklas Karlsson (JIRA)

[ https://issues.jboss.org/browse/WFLY-3149?page=com.atlassian.jira.plugin.... ] Nicklas Karlsson edited comment on WFLY-3149 at 5/24/16 6:58 AM: ----------------------------------------------------------------- I had a similar issue but it turned out I needed a JAVA_HOME in jboss-cli.bat since the system-wide env value wasn't working (spaces in path?) was (Author: nickarls): I'm still seeing this issue on a WF10/JDK8/64b Windows Server 2008 (working on my Win8 64/JDK dev machine, though) It installs as localservice with "C:\WF\bin\service\amd64\wildfly-service" install WF --DisplayName="WF" --Description "WF" --LogLevel=DEBUG --LogPath="C:\WF\standalone\log" --LogPrefix=service -- StdOutput=auto --StdError=auto --StartMode=exe --StartImage=cmd.exe --StartPath="C:\WF\bin" ++StartParams="/c \"set NOPAUSE=Y && standalone.bat\"" --StopMode=exe --StopImage=cmd.exe --StopPath="C:\WF\bin" ++StopParams="/c \"set NOPAUSE=Y && jboss-cli.bat --connect --controller=localhost:9939 --command=:shutdown\"" And starts just fine with "service start" but doesn't stop with "service stop". If I run the jboss-cli command manually, it stops fine. If I try the new service.bat from https://github.com/wildfly/wildfly-core/blob/master/core-feature-pack/src... I get a The data area passed to a system call is too small. and the starting fails. > Windows service on 64 bit systems cannot be stopped > --------------------------------------------------- > > Key: WFLY-3149 > URL: https://issues.jboss.org/browse/WFLY-3149 > Project: WildFly > Issue Type: Bug > Components: Scripts > Affects Versions: 8.0.0.Final > Environment: Windows 2008 Server, Windows 7 professional - both 64 bit systems using JDK 1.7.0_09 > Reporter: Mohan Potturi > Assignee: Mladen Turk > > The Windows service cannot be stopped. It says 'stopping' in the windows service user interface window. The only way to stop it is ti actually kill the java process. It works flawlessly on 32 bit systems though. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1495) server instances cannot find keytab during domain startup

by Vlado Pakan (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1495?page=com.atlassian.jira.plugi... ] Vlado Pakan updated WFCORE-1495: -------------------------------- Original Estimate: 4 days Remaining Estimate: 4 days > server instances cannot find keytab during domain startup > --------------------------------------------------------- > > Key: WFCORE-1495 > URL: https://issues.jboss.org/browse/WFCORE-1495 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management, Security > Reporter: Derek Horton > Assignee: Vlado Pakan > Original Estimate: 4 days > Remaining Estimate: 4 days > > In domain mode, the server instances cannot find the keytab if the ApplicationRealm is configured to use kerberos as the server-identity: > {code} > <security-realm name="ApplicationRealm"> > <server-identities> > <kerberos> > <keytab principal="remote/imahost.imadomain.net@VM29" path="/path/to/keytab"/> > </kerberos> > </server-identities> > <authentication> > <kerberos remove-realm="true"/> > </authentication> > <authorization> > <properties path="application-roles.properties" relative-to="jboss.domain.config.dir"/> > </authorization> > </security-realm> > {code} > This results in the following error and the server instances fail to start: > [Server:server-one] 15:10:35,360 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("validate-authentication") failed - address: ([ > [Server:server-one] ("core-service" => "management"), > [Server:server-one] ("security-realm" => "ApplicationRealm") > [Server:server-one] ]) - failure description: "WFLYDM0094: Kerberos is enabled for authentication on security realm 'ApplicationRealm' but no Keytab has been added to the server-identity." > [Server:server-one] 15:10:35,376 FATAL [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0056: Server boot has failed in an unrecoverable manner; exiting. See previous messages for details. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3149) Windows service on 64 bit systems cannot be stopped

by Nicklas Karlsson (JIRA)

[ https://issues.jboss.org/browse/WFLY-3149?page=com.atlassian.jira.plugin.... ] Nicklas Karlsson commented on WFLY-3149: ---------------------------------------- I'm still seeing this issue on a WF10/JDK8/64b Windows Server 2008 (working on my Win8 64/JDK dev machine, though) It installs as localservice with "C:\WF\bin\service\amd64\wildfly-service" install WF --DisplayName="WF" --Description "WF" --LogLevel=DEBUG --LogPath="C:\WF\standalone\log" --LogPrefix=service -- StdOutput=auto --StdError=auto --StartMode=exe --StartImage=cmd.exe --StartPath="C:\WF\bin" ++StartParams="/c \"set NOPAUSE=Y && standalone.bat\"" --StopMode=exe --StopImage=cmd.exe --StopPath="C:\WF\bin" ++StopParams="/c \"set NOPAUSE=Y && jboss-cli.bat --connect --controller=localhost:9939 --command=:shutdown\"" And starts just fine with "service start" but doesn't stop with "service stop". If I run the jboss-cli command manually, it stops fine. If I try the new service.bat from https://github.com/wildfly/wildfly-core/blob/master/core-feature-pack/src... I get a The data area passed to a system call is too small. and the starting fails. > Windows service on 64 bit systems cannot be stopped > --------------------------------------------------- > > Key: WFLY-3149 > URL: https://issues.jboss.org/browse/WFLY-3149 > Project: WildFly > Issue Type: Bug > Components: Scripts > Affects Versions: 8.0.0.Final > Environment: Windows 2008 Server, Windows 7 professional - both 64 bit systems using JDK 1.7.0_09 > Reporter: Mohan Potturi > Assignee: Mladen Turk > > The Windows service cannot be stopped. It says 'stopping' in the windows service user interface window. The only way to stop it is ti actually kill the java process. It works flawlessly on 32 bit systems though. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6639) Upgrade IronJacamar from 1.3.3.Final to 1.3.4.Final

by Carlo de Wolf (JIRA)

[ https://issues.jboss.org/browse/WFLY-6639?page=com.atlassian.jira.plugin.... ] Carlo de Wolf updated WFLY-6639: -------------------------------- Labels: downstream_dependency (was: ) > Upgrade IronJacamar from 1.3.3.Final to 1.3.4.Final > --------------------------------------------------- > > Key: WFLY-6639 > URL: https://issues.jboss.org/browse/WFLY-6639 > Project: WildFly > Issue Type: Component Upgrade > Components: JCA > Reporter: Lin Gao > Assignee: Lin Gao > Labels: downstream_dependency > > If the password for any datasource is invalid, and there are multiple datasources defined, it is difficult to identify the problematic datasource from the the console log. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira May 2016