August 2012 - jboss-jira - Jboss List Archives

[JBoss JIRA] (AS7-5038) org.jboss.as.jpa module missing javax.servlet.api dependency

by Brad Maxwell (JIRA)

Brad Maxwell created AS7-5038: --------------------------------- Summary: org.jboss.as.jpa module missing javax.servlet.api dependency Key: AS7-5038 URL: https://issues.jboss.org/browse/AS7-5038 Project: Application Server 7 Issue Type: Bug Reporter: Brad Maxwell -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 10 months

4
10
0 / 0

[JBoss JIRA] (JBWEB-240) max-post-size documentation is incorrect. Min size in 1024.

by Jason Shepherd (JIRA)

11 years, 10 months

3
5
0 / 0

[JBoss JIRA] Created: (JBAS-8751) javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL not honored

by Nicklas Karlsson (JIRA)

javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL not honored ----------------------------------------------------------------------- Key: JBAS-8751 URL: https://issues.jboss.org/browse/JBAS-8751 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: JSF Affects Versions: 6.0.0.CR1 Reporter: Nicklas Karlsson Assignee: Stan Silvert Given a model like @javax.enterprise.inject.Model public class Model { private String data; public String getData() { return data; } public void setData(String data) { System.out.println("set data to " + data); this.data = data; } } and a view like <h:form> <h:inputText id="field" value="#{model.data}"/> <h:commandButton value="!"/> </h:form> an empty value is submitted even with <context-param> <param-name>javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL</param-name> <param-value>true</param-value> </context-param> Debugging the application shows that the emptyStringIsNull of the component is true. even with a @FacesConverter(forClass=String.class) which is correctly run and doing a setSubmittedValue(null), the model still sees a "" instead of a null Tested to work correctly on a GF 3.0.1 -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 10 months

4
3
0 / 0

[JBoss JIRA] (AS7-5276) NPE in Domain Mode Tests

by Stuart Douglas (JIRA)

Stuart Douglas created AS7-5276: ----------------------------------- Summary: NPE in Domain Mode Tests Key: AS7-5276 URL: https://issues.jboss.org/browse/AS7-5276 Project: Application Server 7 Issue Type: Bug Components: Domain Management Affects Versions: 7.1.2.Final (EAP) Reporter: Stuart Douglas Assignee: Brian Stansberry Fix For: 7.1.3.Final (EAP), 7.2.0.Alpha1 The following NPE shows up after a successful run of the domain mode tests: {code} [Host Controller] 20:11:41,741 ERROR [org.jboss.as.controller.management-operation] (domain-connection-threads - 1) JBAS014612: Operation ("full-replace-deployment") failed - address: (undefined): java.lang.NullPointerException [Host Controller] at org.jboss.as.domain.controller.operations.deployment.DeploymentFullReplaceHandler.execute(DeploymentFullReplaceHandler.java:213) [jboss-as-host-controller-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT] [Host Controller] at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:397) [jboss-as-controller-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT] [Host Controller] at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:284) [jboss-as-controller-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT] [Host Controller] at org.jboss.as.controller.AbstractOperationContext.completeStep(AbstractOperationContext.java:211) [jboss-as-controller-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT] [Host Controller] at org.jboss.as.domain.controller.operations.coordination.OperationSlaveStepHandler.execute(OperationSlaveStepHandler.java:66) [jboss-as-host-controller-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT] [Host Controller] at org.jboss.as.domain.controller.operations.coordination.PrepareStepHandler.execute(PrepareStepHandler.java:80) [jboss-as-host-controller-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT] [Host Controller] at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:397) [jboss-as-controller-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT] [Host Controller] at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:284) [jboss-as-controller-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT] [Host Controller] at org.jboss.as.controller.AbstractOperationContext.completeStep(AbstractOperationContext.java:211) [jboss-as-controller-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT] [Host Controller] at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:126) [jboss-as-controller-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT] [Host Controller] at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:111) [jboss-as-controller-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT] [Host Controller] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler.doExecute(TransactionalProtocolOperationHandler.java:112) [jboss-as-controller-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT] [Host Controller] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$1.execute(TransactionalProtocolOperationHandler.java:95) [jboss-as-controller-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT] [Host Controller] at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:296) [jboss-as-protocol-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT] [Host Controller] at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:518) [jboss-as-protocol-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT] [Host Controller] at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [classes.jar:1.6.0_33] [Host Controller] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [classes.jar:1.6.0_33] [Host Controller] at java.lang.Thread.run(Thread.java:680) [classes.jar:1.6.0_33] [Host Controller] at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.0.0.GA.jar:2.0.0.GA] {code} The tests still pass even with this exception -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 10 months

2
1
0 / 0

[JBoss JIRA] (JBBUILD-722) Thirdparty rebuild of dtd-parser 1.2-SNAPSHOT

by Paul Gier (JIRA)

Paul Gier created JBBUILD-722: --------------------------------- Summary: Thirdparty rebuild of dtd-parser 1.2-SNAPSHOT Key: JBBUILD-722 URL: https://issues.jboss.org/browse/JBBUILD-722 Project: JBoss Build System Issue Type: Task Components: Thirdparty Builds Reporter: Paul Gier Assignee: Paul Gier Fix For: Thirdparty Builds 2012 The 1.2-SNAPSHOT version of dtdparser is required by Jaxb 2.2.5 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 10 months

1
1
0 / 0

[JBoss JIRA] (JBBUILD-723) Thirdparty rebuild of rngom 201103-SNAPSHOT

by Paul Gier (JIRA)

Paul Gier created JBBUILD-723: --------------------------------- Summary: Thirdparty rebuild of rngom 201103-SNAPSHOT Key: JBBUILD-723 URL: https://issues.jboss.org/browse/JBBUILD-723 Project: JBoss Build System Issue Type: Task Components: Thirdparty Builds Reporter: Paul Gier Assignee: Paul Gier Fix For: Thirdparty Builds 2012 rngom version 201103-SNAPSHOT is required by jaxb 2.2.5 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 10 months

1
1
0 / 0

[JBoss JIRA] (AS7-5283) CLONE - Parameter -server is not added for PC and HC when running on IBM JDK 6 and 7

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/AS7-5283?page=com.atlassian.jira.plugin.s... ] Brian Stansberry updated AS7-5283: ---------------------------------- Labels: (was: eap601candidate) > CLONE - Parameter -server is not added for PC and HC when running on IBM JDK 6 and 7 > ------------------------------------------------------------------------------------ > > Key: AS7-5283 > URL: https://issues.jboss.org/browse/AS7-5283 > Project: Application Server 7 > Issue Type: Bug > Components: Scripts > Affects Versions: 7.1.1.Final, 7.1.2.Final (EAP) > Reporter: Rostislav Svoboda > Assignee: Brian Stansberry > Fix For: 7.1.3.Final (EAP), 7.2.0.Alpha1 > > > For IBM JDK 6 and 7 parameter -server is not added for PC and HC, server-one and server-two processes contain -server parameter. > On OracleJDK and OpenJDK it's added by default for domain.sh, in standalone.sh for IBM JDK parameter -server is added. > Problem is in domain.sh script, part starting with line 76. > IBM JDK 6 version output: > java version "1.6.0" > Java(TM) SE Runtime Environment (build pxi3260sr10fp1-20120321_01(SR10 FP1)) > IBM J9 VM (build 2.4, JRE 1.6.0 IBM J9 2.4 Linux x86-32 jvmxi3260sr10fp1-20120202_101568 (JIT enabled, AOT enabled) > J9VM - 20120202_101568 > JIT - r9_20111107_21307ifx1 > GC - 20120202_AA) > JCL - 20120320_01 > IBM JDK 7 version output: > java version "1.7.0" > Java(TM) SE Runtime Environment (build pxi3270-20110827_01) > IBM J9 VM (build 2.6, JRE 1.7.0 Linux x86-32 20110810_88604 (JIT enabled, AOT enabled) > J9VM - R26_Java726_GA_20110810_1208_B88592 > JIT - r11_20110810_20466 > GC - R26_Java726_GA_20110810_1208_B88592 > J9CL - 20110810_88604) > JCL - 20110809_01 based on Oracle 7b147 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (AS7-3919) HornetQ causing deadlock when max-size-bytes reaches its limit

by Ove Ranheim (JIRA)

Ove Ranheim created AS7-3919: -------------------------------- Summary: HornetQ causing deadlock when max-size-bytes reaches its limit Key: AS7-3919 URL: https://issues.jboss.org/browse/AS7-3919 Project: Application Server 7 Issue Type: Bug Components: JMS Affects Versions: 7.1.0.Final Reporter: Ove Ranheim Assignee: Andy Taylor Priority: Critical Fix For: 7.1.1.Final I have journal-file-size set to 10 Mb and max-size-bytes set 10 Mb, with a address policy of BLOCK. When my sendMailQueue reaches its limit a deadlock occurs. This is further emphasized in the JBossAS Forum reference. Here's a snippet from jstack after HornetQ crashes. {noformat} Found one Java-level deadlock: ============================= "Thread-878 (HornetQ-client-global-threads-1151364488)": waiting to lock monitor 0x0000000041df8640 (object 0x00000000ea17d6e0, a java.lang.Object), which is held by "Thread-873 (HornetQ-client-global-threads-1151364488)" "Thread-873 (HornetQ-client-global-threads-1151364488)": waiting to lock monitor 0x000000004107c8b8 (object 0x00000000ea17d6d0, a java.lang.Object), which is held by "Thread-878 (HornetQ-client-global-threads-1151364488)" Java stack information for the threads listed above: =================================================== "Thread-878 (HornetQ-client-global-threads-1151364488)": at org.hornetq.core.client.impl.ClientSessionFactoryImpl.close(ClientSessionFactoryImpl.java:461) - waiting to lock <0x00000000ea17d6e0> (a java.lang.Object) - locked <0x00000000ea17d6d0> (a java.lang.Object) at org.hornetq.core.client.impl.ServerLocatorImpl.doClose(ServerLocatorImpl.java:1294) at org.hornetq.core.client.impl.ServerLocatorImpl.close(ServerLocatorImpl.java:1238) at org.hornetq.jms.server.recovery.HornetQXAResourceWrapper.close(HornetQXAResourceWrapper.java:392) at org.hornetq.jms.server.recovery.HornetQXAResourceWrapper.connectionFailed(HornetQXAResourceWrapper.java:232) at org.hornetq.core.client.impl.ClientSessionFactoryImpl.callFailureListeners(ClientSessionFactoryImpl.java:905) at org.hornetq.core.client.impl.ClientSessionFactoryImpl.failoverOrReconnect(ClientSessionFactoryImpl.java:690) - locked <0x00000000f0222060> (a java.lang.Object) at org.hornetq.core.client.impl.ClientSessionFactoryImpl.handleConnectionFailure(ClientSessionFactoryImpl.java:556) at org.hornetq.core.client.impl.ClientSessionFactoryImpl.access$000(ClientSessionFactoryImpl.java:79) at org.hornetq.core.client.impl.ClientSessionFactoryImpl$1.run(ClientSessionFactoryImpl.java:386) at org.hornetq.utils.OrderedExecutorFactory$OrderedExecutor$1.run(OrderedExecutorFactory.java:100) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:662) "Thread-873 (HornetQ-client-global-threads-1151364488)": at org.hornetq.core.client.impl.ClientSessionFactoryImpl.close(ClientSessionFactoryImpl.java:458) - waiting to lock <0x00000000ea17d6d0> (a java.lang.Object) at org.hornetq.jms.server.recovery.HornetQXAResourceWrapper.close(HornetQXAResourceWrapper.java:391) at org.hornetq.jms.server.recovery.HornetQXAResourceWrapper.connectionFailed(HornetQXAResourceWrapper.java:232) at org.hornetq.core.client.impl.ClientSessionFactoryImpl.callFailureListeners(ClientSessionFactoryImpl.java:905) at org.hornetq.core.client.impl.ClientSessionFactoryImpl.failoverOrReconnect(ClientSessionFactoryImpl.java:690) - locked <0x00000000ea17d6e0> (a java.lang.Object) at org.hornetq.core.client.impl.ClientSessionFactoryImpl.handleConnectionFailure(ClientSessionFactoryImpl.java:556) at org.hornetq.core.client.impl.ClientSessionFactoryImpl.access$000(ClientSessionFactoryImpl.java:79) at org.hornetq.core.client.impl.ClientSessionFactoryImpl$1.run(ClientSessionFactoryImpl.java:386) at org.hornetq.utils.OrderedExecutorFactory$OrderedExecutor$1.run(OrderedExecutorFactory.java:100) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:662) Found 1 deadlock. {noformat} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 10 months

5
18
0 / 0

[JBoss JIRA] (AS7-5303) TS: Determine correct behavior of surefire and failsafe regarding ignoring <includes> when running single test.

by Jakub Senko (JIRA)

Jakub Senko created AS7-5303: -------------------------------- Summary: TS: Determine correct behavior of surefire and failsafe regarding ignoring <includes> when running single test. Key: AS7-5303 URL: https://issues.jboss.org/browse/AS7-5303 Project: Application Server 7 Issue Type: Bug Components: Test Suite Reporter: Jakub Senko Assignee: Ondrej Zizka Currently, Test Suite is using surefire plugin to run integration tests. Failsafe is more suitable to do this, and the goal is to migrate from surefire to failsafe for IT. However, there is a difference in how surefire and failsafe behaves when running a single test from CLI. Surefire ignores <includes> pattern by default. This is optional (http://jira.codehaus.org/browse/SUREFIRE-806). Failsafe does not ignore <includes> thus will not execute some tests that surefire would. Currently, this is not optional (http://jira.codehaus.org/browse/SUREFIRE-856). It needs to be decided whether to ignore <includes> by default, in which case http://jira.codehaus.org/browse/SUREFIRE-856 needs to be resolved before migrating to failsafe (https://jira.jboss.org/browse/AS7-4065), or not. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 10 months

2
2
0 / 0

[JBoss JIRA] (HIBERNATE-136) Hibernate 4.1.5.SP1 is not compatible with Java 1.5, it throws java.lang.UnsupportedClassVersionError: org/hibernate/ejb/HibernatePersistence : unsupported classversion 50.0

by Kirill Linnik (JIRA)

Kirill Linnik created HIBERNATE-136: --------------------------------------- Summary: Hibernate 4.1.5.SP1 is not compatible with Java 1.5, it throws java.lang.UnsupportedClassVersionError: org/hibernate/ejb/HibernatePersistence : unsupported classversion 50.0 Key: HIBERNATE-136 URL: https://issues.jboss.org/browse/HIBERNATE-136 Project: Hibernate Integration Issue Type: Bug Environment: Sun Microsystems Java 1.5, build 22 Weblogic 9.2.4 Reporter: Kirill Linnik Assignee: Steve Ebersole -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 10 months

2
6
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira August 2012