[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-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
[JBoss JIRA] Created: (JBRULES-3033) java.lang.ClassCastException when change rule condition and declarative facts/events are used
by Federico Weisse (JIRA)
java.lang.ClassCastException when change rule condition and declarative facts/events are used
---------------------------------------------------------------------------------------------
Key: JBRULES-3033
URL: https://issues.jboss.org/browse/JBRULES-3033
Project: Drools
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: drools-core
Affects Versions: 5.1.1.FINAL
Reporter: Federico Weisse
Assignee: Mark Proctor
We have drl files where we declare events. we use declarative events (there is no java class AlertaPosManual)
(like this)
declare AlertaPosManual
@role (event)
@expires(10s)
idTerminal : java.lang.String
end
We use a StatefullSession for fusion cep and we need that changes in rules refresh the kBase in runtime. But when a rule condition changes this exception in throw
Exception in thread "Thread-2" java.lang.ClassCastException: com.sample.ConsumoPostManual cannot be cast to com.sample.ConsumoPostManual
at org.drools.base.com.sample.ConsumoPostManual17710704$getIdTerminal.getValue(Unknown Source)
at org.drools.base.extractors.BaseObjectClassFieldReader.getHashCode(BaseObjectClassFieldReader.java:192)
at org.drools.base.ClassFieldReader.getHashCode(ClassFieldReader.java:193)
at org.drools.core.util.AbstractHashTable$SingleIndex.hashCodeOf(AbstractHashTable.java:582)
at org.drools.core.util.RightTupleIndexHashTable.getOrCreate(RightTupleIndexHashTable.java:360)
at org.drools.core.util.RightTupleIndexHashTable.add(RightTupleIndexHashTable.java:243)
at org.drools.reteoo.AccumulateNode.assertObject(AccumulateNode.java:246)
at org.drools.reteoo.ObjectTypeNode.updateSink(ObjectTypeNode.java:276)
at org.drools.reteoo.PropagationQueuingNode.updateSink(PropagationQueuingNode.java:111)
at org.drools.reteoo.BetaNode.attach(BetaNode.java:214)
at org.drools.reteoo.builder.BuildUtils.attachNode(BuildUtils.java:151)
at org.drools.reteoo.builder.CollectBuilder.build(CollectBuilder.java:114)
at org.drools.reteoo.builder.PatternBuilder.attachPattern(PatternBuilder.java:111)
at org.drools.reteoo.builder.PatternBuilder.build(PatternBuilder.java:72)
at org.drools.reteoo.builder.GroupElementBuilder$AndBuilder.build(GroupElementBuilder.java:132)
at org.drools.reteoo.builder.GroupElementBuilder.build(GroupElementBuilder.java:78)
at org.drools.reteoo.builder.ReteooRuleBuilder.addSubRule(ReteooRuleBuilder.java:155)
at org.drools.reteoo.builder.ReteooRuleBuilder.addRule(ReteooRuleBuilder.java:128)
at org.drools.reteoo.ReteooBuilder.addRule(ReteooBuilder.java:117)
at org.drools.reteoo.ReteooRuleBase.addRule(ReteooRuleBase.java:428)
at org.drools.common.AbstractRuleBase.addRule(AbstractRuleBase.java:721)
at org.drools.common.AbstractRuleBase.addPackages(AbstractRuleBase.java:545)
at org.drools.reteoo.ReteooRuleBase.addPackages(ReteooRuleBase.java:445)
at org.drools.reteoo.ReteooRuleBase.addPackage(ReteooRuleBase.java:452)
at org.drools.agent.impl.KnowledgeAgentImpl.addResourcesToKnowledgeBase(KnowledgeAgentImpl.java:937)
at org.drools.agent.impl.KnowledgeAgentImpl.incrementalBuildResources(KnowledgeAgentImpl.java:821)
at org.drools.agent.impl.KnowledgeAgentImpl.buildKnowledgeBase(KnowledgeAgentImpl.java:586)
at org.drools.agent.impl.KnowledgeAgentImpl.applyChangeSet(KnowledgeAgentImpl.java:185)
at org.drools.agent.impl.KnowledgeAgentImpl$ChangeSetNotificationDetector.run(KnowledgeAgentImpl.java:1106)
at java.lang.Thread.run(Thread.java:619)
I think that's because the statefullSession has an instance of
com.sample.ConsumoPostManual (loaded with the classLoader
org.drools.rule.JavaDialectRuntimeData$PackageClassLoader@1218b25) But when
the kBase is regenerated and the class com.sample.ConsumoPostManual to, the
classLoader org.drools.rule.JavaDialectRuntimeData is recreated so there
are two versions of the class com.sample.ConsumoPostManual in differents
classLoader (one in the statefullSession and the other in the kBase)
--
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] Created: (JBRULES-2962) Knowledge Agent rebuilding KnowledgeBase with scanner/notifier does not work with declared facts
by Ross Hall (JIRA)
Knowledge Agent rebuilding KnowledgeBase with scanner/notifier does not work with declared facts
------------------------------------------------------------------------------------------------
Key: JBRULES-2962
URL: https://issues.jboss.org/browse/JBRULES-2962
Project: Drools
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: drools-core
Affects Versions: 5.2.0.M1, 5.1.1.FINAL
Reporter: Ross Hall
Assignee: Mark Proctor
When reloading rules in a KnowledgeAgent declared facts will cause ClassCastExceptions when new-instance is set to false. When new-instance is set to true, the KnowledgeBase is rebuilt, however declared facts are not recognized and associated rules will not fire. Rules not using declared facts will fire normally. Using POJOs works fine.
In both cases the KnowledgeAgent will build the rule base the first time, the issue only seems to occur when the changeset resources are modified and are detected by the resource notifier and scanner.
--
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] Created: (AS7-1613) NPE in TranslatingSuspendableChannel.scheduleReadTask
by Ondrej Zizka (JIRA)
NPE in TranslatingSuspendableChannel.scheduleReadTask
-----------------------------------------------------
Key: AS7-1613
URL: https://issues.jboss.org/browse/AS7-1613
Project: Application Server 7
Issue Type: Bug
Components: CLI
Affects Versions: 7.0.1.Final
Reporter: Ondrej Zizka
Assignee: Alexey Loubyansky
Happened after a while of inactivity (if that matters).
[standalone@localhost:9999 interface=public] cd ..
[standalone@localhost:9999 /] cd ..
[standalone@localhost:9999 /] ls
extension core-service path subsystem system-property deployment interface socket-binding-group
[standalone@localhost:9999 /] Exception in thread "pool-1-thread-21" java.lang.NullPointerException
at org.xnio.channels.TranslatingSuspendableChannel.scheduleReadTask(TranslatingSuspendableChannel.java:253)
at org.xnio.channels.TranslatingSuspendableChannel.resumeReads(TranslatingSuspendableChannel.java:233)
at org.jboss.remoting3.remote.ClientConnectionOpenListener$Authentication$2.run(ClientConnectionOpenListener.java:498)
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)
--
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] Created: (JBRULES-2791) Spring's JpaTransactionManager should be used instead of both: DroolsSpringTransactionManager and DroolsSpringJpaManager
by Anatoly Polinsky (JIRA)
Spring's JpaTransactionManager should be used instead of both: DroolsSpringTransactionManager and DroolsSpringJpaManager
------------------------------------------------------------------------------------------------------------------------
Key: JBRULES-2791
URL: https://jira.jboss.org/browse/JBRULES-2791
Project: Drools
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 5.1.1.FINAL, FUTURE
Environment: Spring Based Applications
Reporter: Anatoly Polinsky
Assignee: Mark Proctor
Instead of having two different components: "DroolsSpringTransactionManager" and "DroolsSpringJpaManager" that aim to do the work of "org.springframework.orm.jpa.JpaTransactionManager", and trying to fit a JTA model into it, the Spring's "JpaTransactionManager" itself should be used.
And instead of manually managing and constantly getting references to a "proper entity manager" from JpaManger within a SingleSessionCommandService, a @PersistenceContext should be injected. This will decouple SingleSessionCommandService from JpaManager interface, and will allow _any_ JPA provider to inject an entity manager.
It has more benefits, such as trust in underline JPA providers ( e.g. Hibernate ) and Spring Transaction Management capabilities to manage the process that they are actually excellent at.
/Anatoly
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 11 months