[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
13 years, 11 months
[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
13 years, 11 months
[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
13 years, 11 months
[JBoss JIRA] (AS7-4293) Support property expansion in redirect-port attribute of the web system's connector
by Sven-Jørgen Karlsen (JIRA)
Sven-Jørgen Karlsen created AS7-4293:
----------------------------------------
Summary: Support property expansion in redirect-port attribute of the web system's connector
Key: AS7-4293
URL: https://issues.jboss.org/browse/AS7-4293
Project: Application Server 7
Issue Type: Bug
Components: Web
Affects Versions: 7.1.1.Final
Environment: Standalone JBoss AS 7 on RHEL Linux and Windows 7 Enterprise x64
Reporter: Sven-Jørgen Karlsen
Assignee: Remy Maucherat
Priority: Optional
The connector element of the web subsystem doesn't support property expansion, forcing you to hardwire the port
number. E.g., writing:
...
<subsystem xmlns="urn:jboss:domain:web:1.1" default-virtual-server="default-host">
<connector name="http" protocol="HTTP/1.1" scheme="http" socket-binding="http"
redirect-port="${jboss.web.https.port}"/>
...
causes a NumberFormatException. Runtime properties for this attribute was supported in previous versions.
Another problem is that there is no predefined property with the above name.
An alternative solution is to allow a reference to a socket binding groups in the attribute value, as discussed in
http://community.jboss.org/thread/176339
--
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
13 years, 11 months
