[JBoss JIRA] (JGRP-1709) Logging: convert the most important WARN and ERROR messages to use IDs and resource bundles
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1709?page=com.atlassian.jira.plugin.... ]
Bela Ban edited comment on JGRP-1709 at 10/2/13 10:49 AM:
----------------------------------------------------------
The following classes below still need to be converted, excluding
- classes that are not officially supported (STOMP, PRIO)
- classes that are not used anymore (e.g. NAKACK, NakReceiverWindow, Retransmitter, DefaultRetransmitter, RangeBasedRetransmitter etc)
- test code (StateTransferTest)
- demos (Whiteboard, GraphPanel, Draw, QuoteServer)
{panel}
-src/org/jgroups/stack/Configurator.java-
src/org/jgroups/conf/XmlConfigurator.java
src/org/jgroups/conf/PropertyHelper.java
src/org/jgroups/conf/ProtocolConfiguration.java
src/org/jgroups/conf/ClassConfigurator.java
src/org/jgroups/protocols/Locking.java
src/org/jgroups/protocols/FILE_PING.java
src/org/jgroups/protocols/FD_SOCK.java
src/org/jgroups/protocols/RSVP.java
src/org/jgroups/protocols/UDP.java
src/org/jgroups/protocols/FD_PING.java
src/org/jgroups/protocols/COMPRESS.java
src/org/jgroups/protocols/VERIFY_SUSPECT.java
src/org/jgroups/protocols/MFC.java
src/org/jgroups/protocols/MERGE3.java
src/org/jgroups/protocols/FRAG2.java
src/org/jgroups/protocols/FlowControl.java
src/org/jgroups/protocols/ENCRYPT.java
src/org/jgroups/protocols/FORWARD_TO_COORD.java
src/org/jgroups/protocols/S3_PING.java
src/org/jgroups/protocols/FD.java
src/org/jgroups/protocols/UNICAST2.java
src/org/jgroups/protocols/Discovery.java
src/org/jgroups/protocols/JDBC_PING.java
src/org/jgroups/protocols/TCP.java
src/org/jgroups/protocols/UFC.java
src/org/jgroups/protocols/SEQUENCER.java
src/org/jgroups/protocols/AUTH.java
src/org/jgroups/protocols/TP.java
src/org/jgroups/protocols/TCPGOSSIP.java
src/org/jgroups/protocols/MPING.java
src/org/jgroups/protocols/pbcast/GMS.java
src/org/jgroups/protocols/pbcast/GmsImpl.java
src/org/jgroups/protocols/pbcast/STATE_TRANSFER.java
src/org/jgroups/protocols/pbcast/ClientGmsImpl.java
src/org/jgroups/protocols/pbcast/StreamingStateTransfer.java
src/org/jgroups/protocols/pbcast/Merger.java
src/org/jgroups/protocols/pbcast/CoordGmsImpl.java
src/org/jgroups/protocols/pbcast/STABLE.java
src/org/jgroups/protocols/pbcast/FLUSH.java
src/org/jgroups/protocols/pbcast/STATE_SOCK.java
src/org/jgroups/protocols/pbcast/NAKACK2.java
src/org/jgroups/protocols/relay/RELAY2.java
src/org/jgroups/protocols/relay/Relayer.java
src/org/jgroups/protocols/tom/TOA.java
src/org/jgroups/util/TimeScheduler2.java
src/org/jgroups/util/Util.java
src/org/jgroups/util/ForwardQueue.java
src/org/jgroups/util/Queue.java
src/org/jgroups/jmx/ResourceDMBean.java
src/org/jgroups/jmx/JmxConfigurator.java
src/org/jgroups/blocks/RequestCorrelator.java
src/org/jgroups/blocks/GroupRequest.java
src/org/jgroups/blocks/TCPConnectionMap.java
src/org/jgroups/blocks/Request.java
src/org/jgroups/blocks/RpcDispatcher.java
src/org/jgroups/blocks/MethodCall.java
src/org/jgroups/blocks/MessageDispatcher.java
src/org/jgroups/auth/MD5Token.java
src/org/jgroups/auth/FixedMembershipToken.java
src/org/jgroups/auth/SimpleToken.java
src/org/jgroups/auth/X509Token.java
{panel}
was (Author: belaban):
The following classes below still need to be converted, excluding
- classes that are not officially supported (STOMP, PRIO)
- classes that are not used anymore (e.g. NAKACK, NakReceiverWindow, Retransmitter, DefaultRetransmitter, RangeBasedRetransmitter etc)
- test code (StateTransferTest)
- demos (Whiteboard, GraphPanel, Draw, QuoteServer)
{panel}
src/org/jgroups/stack/Configurator.java
src/org/jgroups/conf/XmlConfigurator.java
src/org/jgroups/conf/PropertyHelper.java
src/org/jgroups/conf/ProtocolConfiguration.java
src/org/jgroups/conf/ClassConfigurator.java
src/org/jgroups/protocols/Locking.java
src/org/jgroups/protocols/FILE_PING.java
src/org/jgroups/protocols/FD_SOCK.java
src/org/jgroups/protocols/RSVP.java
src/org/jgroups/protocols/UDP.java
src/org/jgroups/protocols/FD_PING.java
src/org/jgroups/protocols/COMPRESS.java
src/org/jgroups/protocols/VERIFY_SUSPECT.java
src/org/jgroups/protocols/MFC.java
src/org/jgroups/protocols/MERGE3.java
src/org/jgroups/protocols/FRAG2.java
src/org/jgroups/protocols/FlowControl.java
src/org/jgroups/protocols/ENCRYPT.java
src/org/jgroups/protocols/FORWARD_TO_COORD.java
src/org/jgroups/protocols/S3_PING.java
src/org/jgroups/protocols/FD.java
src/org/jgroups/protocols/UNICAST2.java
src/org/jgroups/protocols/Discovery.java
src/org/jgroups/protocols/JDBC_PING.java
src/org/jgroups/protocols/TCP.java
src/org/jgroups/protocols/UFC.java
src/org/jgroups/protocols/SEQUENCER.java
src/org/jgroups/protocols/AUTH.java
src/org/jgroups/protocols/TP.java
src/org/jgroups/protocols/TCPGOSSIP.java
src/org/jgroups/protocols/MPING.java
src/org/jgroups/protocols/pbcast/GMS.java
src/org/jgroups/protocols/pbcast/GmsImpl.java
src/org/jgroups/protocols/pbcast/STATE_TRANSFER.java
src/org/jgroups/protocols/pbcast/ClientGmsImpl.java
src/org/jgroups/protocols/pbcast/StreamingStateTransfer.java
src/org/jgroups/protocols/pbcast/Merger.java
src/org/jgroups/protocols/pbcast/CoordGmsImpl.java
src/org/jgroups/protocols/pbcast/STABLE.java
src/org/jgroups/protocols/pbcast/FLUSH.java
src/org/jgroups/protocols/pbcast/STATE_SOCK.java
src/org/jgroups/protocols/pbcast/NAKACK2.java
src/org/jgroups/protocols/relay/RELAY2.java
src/org/jgroups/protocols/relay/Relayer.java
src/org/jgroups/protocols/tom/TOA.java
src/org/jgroups/util/TimeScheduler2.java
src/org/jgroups/util/Util.java
src/org/jgroups/util/ForwardQueue.java
src/org/jgroups/util/Queue.java
src/org/jgroups/jmx/ResourceDMBean.java
src/org/jgroups/jmx/JmxConfigurator.java
src/org/jgroups/blocks/RequestCorrelator.java
src/org/jgroups/blocks/GroupRequest.java
src/org/jgroups/blocks/TCPConnectionMap.java
src/org/jgroups/blocks/Request.java
src/org/jgroups/blocks/RpcDispatcher.java
src/org/jgroups/blocks/MethodCall.java
src/org/jgroups/blocks/MessageDispatcher.java
src/org/jgroups/auth/MD5Token.java
src/org/jgroups/auth/FixedMembershipToken.java
src/org/jgroups/auth/SimpleToken.java
src/org/jgroups/auth/X509Token.java
{panel}
> Logging: convert the most important WARN and ERROR messages to use IDs and resource bundles
> -------------------------------------------------------------------------------------------
>
> Key: JGRP-1709
> URL: https://issues.jboss.org/browse/JGRP-1709
> Project: JGroups
> Issue Type: Task
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 3.4
>
>
> Convert WARN and ERROR messages that might be seen by users to use a resource bundle (conf/jg-messages*.properties) and assign unique IDs the those messages.
> Link in BZ: https://bugzilla.redhat.com/show_bug.cgi?id=999671
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 2 months
[JBoss JIRA] (DROOLS-194) Add support in KIE to register custom Wagons
by Kurt Stam (JIRA)
[ https://issues.jboss.org/browse/DROOLS-194?page=com.atlassian.jira.plugin... ]
Kurt Stam updated DROOLS-194:
-----------------------------
Attachment: kie-srampwagon.tgz
Import the project into eclipse - go into the dtgov-workflows module
and run the KieTest.
If you have a breakpoint set in the Aether class; it will stop and say the hint = "files".
so you return 'null' at the moment.
it gets "files' from the protocol defined in the url:
ArtifactRepository srampRepo = artifactRepoFactory.createArtifactRepository("central", //$NON-NLS-1$
"files:/tmp/srampRepo",
> Add support in KIE to register custom Wagons
> --------------------------------------------
>
> Key: DROOLS-194
> URL: https://issues.jboss.org/browse/DROOLS-194
> Project: Drools
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Reporter: Kurt Stam
> Assignee: Mark Proctor
> Attachments: kie-srampwagon.tgz
>
>
> The ManualWagonProvider subclass of Aether in KIE registers the HTTPWagon. It should be possible to add your own Wagon through config our automated machinery when another Wagon is put on the classpath and references in the build/extensions of a MavenProject. To get the SrampWagon to work we used the following code:
> {quote}
> private static class ManualWagonProvider implements WagonProvider {
> public Wagon lookup( String roleHint ) throws Exception {
> if ( "http".equals( roleHint ) ) {
> return new AhcWagon();
> }
> if ( "sramp".equals( roleHint ) ) {
> return new SrampWagon();
> }
> return null;
> }
> public void release( Wagon wagon ) { }
> }
> {quote}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 2 months
[JBoss JIRA] (JGRP-1709) Logging: convert the most important WARN and ERROR messages to use IDs and resource bundles
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1709?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1709:
--------------------------------
The following classes below still need to be converted, excluding
- classes that are not officially supported (STOMP, PRIO)
- classes that are not used anymore (e.g. NAKACK, NakReceiverWindow, Retransmitter, DefaultRetransmitter, RangeBasedRetransmitter etc)
- test code (StateTransferTest)
- demos (Whiteboard, GraphPanel, Draw, QuoteServer)
{panel}
src/org/jgroups/stack/Configurator.java
src/org/jgroups/conf/XmlConfigurator.java
src/org/jgroups/conf/PropertyHelper.java
src/org/jgroups/conf/ProtocolConfiguration.java
src/org/jgroups/conf/ClassConfigurator.java
src/org/jgroups/protocols/Locking.java
src/org/jgroups/protocols/FILE_PING.java
src/org/jgroups/protocols/FD_SOCK.java
src/org/jgroups/protocols/RSVP.java
src/org/jgroups/protocols/UDP.java
src/org/jgroups/protocols/FD_PING.java
src/org/jgroups/protocols/COMPRESS.java
src/org/jgroups/protocols/VERIFY_SUSPECT.java
src/org/jgroups/protocols/MFC.java
src/org/jgroups/protocols/MERGE3.java
src/org/jgroups/protocols/FRAG2.java
src/org/jgroups/protocols/FlowControl.java
src/org/jgroups/protocols/ENCRYPT.java
src/org/jgroups/protocols/FORWARD_TO_COORD.java
src/org/jgroups/protocols/S3_PING.java
src/org/jgroups/protocols/FD.java
src/org/jgroups/protocols/UNICAST2.java
src/org/jgroups/protocols/Discovery.java
src/org/jgroups/protocols/JDBC_PING.java
src/org/jgroups/protocols/TCP.java
src/org/jgroups/protocols/UFC.java
src/org/jgroups/protocols/SEQUENCER.java
src/org/jgroups/protocols/AUTH.java
src/org/jgroups/protocols/TP.java
src/org/jgroups/protocols/TCPGOSSIP.java
src/org/jgroups/protocols/MPING.java
src/org/jgroups/protocols/pbcast/GMS.java
src/org/jgroups/protocols/pbcast/GmsImpl.java
src/org/jgroups/protocols/pbcast/STATE_TRANSFER.java
src/org/jgroups/protocols/pbcast/ClientGmsImpl.java
src/org/jgroups/protocols/pbcast/StreamingStateTransfer.java
src/org/jgroups/protocols/pbcast/Merger.java
src/org/jgroups/protocols/pbcast/CoordGmsImpl.java
src/org/jgroups/protocols/pbcast/STABLE.java
src/org/jgroups/protocols/pbcast/FLUSH.java
src/org/jgroups/protocols/pbcast/STATE_SOCK.java
src/org/jgroups/protocols/pbcast/NAKACK2.java
src/org/jgroups/protocols/relay/RELAY2.java
src/org/jgroups/protocols/relay/Relayer.java
src/org/jgroups/protocols/tom/TOA.java
src/org/jgroups/util/TimeScheduler2.java
src/org/jgroups/util/Util.java
src/org/jgroups/util/ForwardQueue.java
src/org/jgroups/util/Queue.java
src/org/jgroups/jmx/ResourceDMBean.java
src/org/jgroups/jmx/JmxConfigurator.java
src/org/jgroups/blocks/RequestCorrelator.java
src/org/jgroups/blocks/GroupRequest.java
src/org/jgroups/blocks/TCPConnectionMap.java
src/org/jgroups/blocks/Request.java
src/org/jgroups/blocks/RpcDispatcher.java
src/org/jgroups/blocks/MethodCall.java
src/org/jgroups/blocks/MessageDispatcher.java
src/org/jgroups/auth/MD5Token.java
src/org/jgroups/auth/FixedMembershipToken.java
src/org/jgroups/auth/SimpleToken.java
src/org/jgroups/auth/X509Token.java
{panel}
> Logging: convert the most important WARN and ERROR messages to use IDs and resource bundles
> -------------------------------------------------------------------------------------------
>
> Key: JGRP-1709
> URL: https://issues.jboss.org/browse/JGRP-1709
> Project: JGroups
> Issue Type: Task
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 3.4
>
>
> Convert WARN and ERROR messages that might be seen by users to use a resource bundle (conf/jg-messages*.properties) and assign unique IDs the those messages.
> Link in BZ: https://bugzilla.redhat.com/show_bug.cgi?id=999671
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 2 months
[JBoss JIRA] (WFLY-2203) Error deploying multiple *-ds.xml files
by Nick Howes (JIRA)
Nick Howes created WFLY-2203:
--------------------------------
Summary: Error deploying multiple *-ds.xml files
Key: WFLY-2203
URL: https://issues.jboss.org/browse/WFLY-2203
Project: WildFly
Issue Type: Bug
Affects Versions: 8.0.0.Beta1
Reporter: Nick Howes
Our individual *-ds.xml datasources were all deploying fine in Alpha4 but in the Beta1 nightlies this error appears on startup:
{noformat}
15:07:52,111 ERROR [org.jboss.msc.service] (MSC service thread 1-4) MSC000002: Invocation of listener "org.jboss.as.connector.subsystems.datasources.D
ataSourceStatisticsListener@7d18ac99" failed: java.lang.IllegalArgumentException: JBAS014742: A node is already registered at '(deployment => *)(subsy
stem => datasources)(data-source => *)(statistics => jdbc)'
at org.jboss.as.controller.registry.NodeSubregistry.register(NodeSubregistry.java:86) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1
-SNAPSHOT]
at org.jboss.as.controller.registry.ConcreteResourceRegistration.registerSubModel(ConcreteResourceRegistration.java:149) [wildfly-controller-8
.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
at org.jboss.as.controller.registry.AbstractResourceRegistration.registerSubModel(AbstractResourceRegistration.java:90) [wildfly-controller-8.
0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
at org.jboss.as.connector.subsystems.datasources.DataSourceStatisticsListener.transition(DataSourceStatisticsListener.java:72) [wildfly-connec
tor-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
at org.jboss.msc.service.ServiceControllerImpl.invokeListener(ServiceControllerImpl.java:1533) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
{noformat}
Our datasource files look like this. I haven't tried putting all the datasource elements into one file.
{code}
<?xml version="1.0" encoding="UTF-8"?>
<datasources>
<datasource jndi-name="java:/AlphaDS" enabled="true" use-java-context="true" pool-name="AlphaDS">
<connection-url>jdbc:oracle:thin://@db-host:1666/dev-db</connection-url>
<driver>oracle</driver>
<security>
<user-name>XXX</user-name>
<password>YYY</password>
</security>
<connection-property name="defaultNChar">true</connection-property>
</datasource>
</datasources>
{code}
{code}
<?xml version="1.0" encoding="UTF-8"?>
<datasources>
<datasource jndi-name="java:/BetaDS" enabled="true" use-java-context="true" pool-name="BetaDS">
<connection-url>jdbc:oracle:thin://@db-host:1666/dev-db</connection-url>
<driver>oracle</driver>
<security>
<user-name>XXX</user-name>
<password>YYY</password>
</security>
<connection-property name="defaultNChar">true</connection-property>
</datasource>
</datasources>
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 2 months
[JBoss JIRA] (JGRP-1710) Messages get too large due to big headers (in large clusters)
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1710?page=com.atlassian.jira.plugin.... ]
Bela Ban resolved JGRP-1710.
----------------------------
Resolution: Done
> Messages get too large due to big headers (in large clusters)
> -------------------------------------------------------------
>
> Key: JGRP-1710
> URL: https://issues.jboss.org/browse/JGRP-1710
> Project: JGroups
> Issue Type: Bug
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.4
>
>
> In some cases, messages get bigger than the max bundling size because of large headers:
> {panel}
> ERROR 17:33:08,096 | Timer-5,c0,172.29.189.9-svc9-ZM26S32728-59135 | [TP.java:1335] | (org) | 172.29.189.9-svc9-ZM26S32728-59135: failed sending message to 172.29.190.181-svc2-00832091-31665 (70850 bytes): java.lang.Exception: message size (70850) is greater than max bundling size (64000). Set the fragmentation/bundle size in FRAG and TP correctly, headers: GMS: GmsHeader[INSTALL_MERGE_VIEW]: view=MergeView::[172.29.190.174-svc6-00832251-874|27] (1479) ...
> {panel}
> In the case of INSTALL_MERGE_VIEW, we send the full view (*not* the DeltaView) and the digest in the header. With 1479 members (as shown the the example above), this increases the message size beyond the max bundling size.
> Possible SOLUTION
> * Place the header fields in the message's buffer instead
> * Move FRAG2 *under* GMS
> ** Investigate impact on flow control etc
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 2 months
[JBoss JIRA] (JGRP-1710) Messages get too large due to big headers (in large clusters)
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1710?page=com.atlassian.jira.plugin.... ]
Bela Ban edited comment on JGRP-1710 at 10/2/13 8:27 AM:
---------------------------------------------------------
As discussed on JGRP-1507: FRAG\{2\} cannot be moved over the transport as retransmission of large messages with 1 fragment missing would cause retransmission of the entire message (all fragments).
Therefore, the current strategy is to move large data from the header into the message's buffer and - if needed - add a *second* FRAG\{2\} directly over the transport. This second fragmentation protocol would typically not have to do any work, as fragmentation is done by the first fragmentation protocol. The only case where work would need to be done is when large data are added by a protocol, e.g. view and digest by {{INSTALL_MERGE_VIEW in GMS}}.
The advantage of moving large data into the body of a message is that FRAG2.down() can do a cheap {{Message.getLength()}}, compared to a more costly {{Message.size()}} by {{FRAG.down()}}.
was (Author: belaban):
As discussed on JGRP-1507: FRAG\{2\} cannot be moved over the transport as retransmission of large messages with 1 fragment missing would cause retransmission of the entire message (all fragments).
Therefore, the current strategy is to move large data from the header into the message's buffer and - if needed - add a second FRAG\{2\} directly over the transport. This second fragmentation protocol would typically not have to do any work, as fragmentation is done by the first fragmentation protocol. The only case where work would need to be done is when large data are added by a protocol, e.g. view and digest by {{INSTALL_MERGE_VIEW in GMS}}.
The advantage of moving large data into the body of a message is that FRAG2.down() can do a cheap {{Message.getLength()}}, compared to a more costly {{Message.size()}} by {{FRAG.down(){{.
> Messages get too large due to big headers (in large clusters)
> -------------------------------------------------------------
>
> Key: JGRP-1710
> URL: https://issues.jboss.org/browse/JGRP-1710
> Project: JGroups
> Issue Type: Bug
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.4
>
>
> In some cases, messages get bigger than the max bundling size because of large headers:
> {panel}
> ERROR 17:33:08,096 | Timer-5,c0,172.29.189.9-svc9-ZM26S32728-59135 | [TP.java:1335] | (org) | 172.29.189.9-svc9-ZM26S32728-59135: failed sending message to 172.29.190.181-svc2-00832091-31665 (70850 bytes): java.lang.Exception: message size (70850) is greater than max bundling size (64000). Set the fragmentation/bundle size in FRAG and TP correctly, headers: GMS: GmsHeader[INSTALL_MERGE_VIEW]: view=MergeView::[172.29.190.174-svc6-00832251-874|27] (1479) ...
> {panel}
> In the case of INSTALL_MERGE_VIEW, we send the full view (*not* the DeltaView) and the digest in the header. With 1479 members (as shown the the example above), this increases the message size beyond the max bundling size.
> Possible SOLUTION
> * Place the header fields in the message's buffer instead
> * Move FRAG2 *under* GMS
> ** Investigate impact on flow control etc
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 2 months
[JBoss JIRA] (WFLY-2118) PersistenceException breaks default error page
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-2118?page=com.atlassian.jira.plugin.... ]
Stuart Douglas commented on WFLY-2118:
--------------------------------------
I wonder if we should change this behaviour? The intention was to make development easier, as you can see stack traces if you are working on localhost (and there are no proxy headers), but it could be confusing as it overrides the default error page.
> PersistenceException breaks default error page
> ----------------------------------------------
>
> Key: WFLY-2118
> URL: https://issues.jboss.org/browse/WFLY-2118
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Reporter: Juergen Zimmermann
> Assignee: Stuart Douglas
> Attachments: mojarra-2.1.zip, testcase-WFLY-2118.zip
>
>
> I'm using the latest WildFly snapshot with Undertow 1.0.0.Beta13. When I get a PersistenceException caused by Hibernate due to an invalid entity (according to Bean Validation), then the webbrowser doesn't get the default error page. The stacktrace is shown below. I'll attach a testcase.
> {code}
> [com.arjuna.ats.arjuna] ARJUNA012125: TwoPhaseCoordinator.beforeCompletion - failed for SynchronizationImple< 0:ffffc0a8b801:4240ead4:523ac52c:15, org.hibernate.engine.transaction.synchronization.internal.RegisteredSynchronization@20cf7473 >: javax.persistence.PersistenceException: error during managed flush
> at org.hibernate.jpa.spi.AbstractEntityManagerImpl$CallbackExceptionMapperImpl.mapManagedFlushFailure(AbstractEntityManagerImpl.java:1785) [hibernate-entitymanager-4.3.0.Beta4.jar:4.3.0.Beta4]
> at org.hibernate.engine.transaction.synchronization.internal.SynchronizationCallbackCoordinatorImpl.beforeCompletion(SynchronizationCallbackCoordinatorImpl.java:118) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> at org.hibernate.engine.transaction.synchronization.internal.RegisteredSynchronization.beforeCompletion(RegisteredSynchronization.java:53) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> at com.arjuna.ats.internal.jta.resources.arjunacore.SynchronizationImple.beforeCompletion(SynchronizationImple.java:76) [narayana-jts-jacorb-5.0.0.M4.jar:5.0.0.M4 (revision: ${buildNumber})]
> at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.beforeCompletion(TwoPhaseCoordinator.java:273) [narayana-jts-jacorb-5.0.0.M4.jar:5.0.0.M4 (revision: ${buildNumber})]
> at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:93) [narayana-jts-jacorb-5.0.0.M4.jar:5.0.0.M4 (revision: ${buildNumber})]
> at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:162) [narayana-jts-jacorb-5.0.0.M4.jar:5.0.0.M4 (revision: ${buildNumber})]
> at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1170) [narayana-jts-jacorb-5.0.0.M4.jar:5.0.0.M4 (revision: ${buildNumber})]
> at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.commit(BaseTransaction.java:126) [narayana-jts-jacorb-5.0.0.M4.jar:5.0.0.M4 (revision: ${buildNumber})]
> at com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.commit(BaseTransactionManagerDelegate.java:75)
> at com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorBase.endTransaction(TransactionalInterceptorBase.java:131) [narayana-jts-jacorb-5.0.0.M4.jar:5.0.0.M4 (revision: ${buildNumber})]
> at com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorBase.invokeInOurTx(TransactionalInterceptorBase.java:77) [narayana-jts-jacorb-5.0.0.M4.jar:5.0.0.M4 (revision: ${buildNumber})]
> at com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorRequired.intercept(TransactionalInterceptorRequired.java:52) [narayana-jts-jacorb-5.0.0.M4.jar:5.0.0.M4 (revision: ${buildNumber})]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_40]
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_40]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_40]
> at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_40]
> at org.jboss.weld.interceptor.proxy.SimpleMethodInvocation.invoke(SimpleMethodInvocation.java:30) [weld-core-impl-2.1.0.Beta1.jar:2013-09-05 17:01]
> at org.jboss.weld.interceptor.chain.AbstractInterceptionChain.invokeNext(AbstractInterceptionChain.java:90) [weld-core-impl-2.1.0.Beta1.jar:2013-09-05 17:01]
> at org.jboss.weld.interceptor.chain.AbstractInterceptionChain.invokeNextInterceptor(AbstractInterceptionChain.java:75) [weld-core-impl-2.1.0.Beta1.jar:2013-09-05 17:01]
> at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.executeInterception(InterceptorMethodHandler.java:48) [weld-core-impl-2.1.0.Beta1.jar:2013-09-05 17:01]
> at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.invoke(InterceptorMethodHandler.java:41) [weld-core-impl-2.1.0.Beta1.jar:2013-09-05 17:01]
> at org.jboss.weld.bean.proxy.CombinedInterceptorAndDecoratorStackMethodHandler.invoke(CombinedInterceptorAndDecoratorStackMethodHandler.java:53) [weld-core-impl-2.1.0.Beta1.jar:2013-09-05 17:01]
> at testcase.web.CustomerModel$Proxy$_$$_WeldSubclass.create(Unknown Source) [classes:]
> at testcase.web.CustomerModel$Proxy$_$$_WeldClientProxy.create(Unknown Source) [classes:]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_40]
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_40]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_40]
> at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_40]
> at javax.el.ELUtil.invokeMethod(ELUtil.java:326) [javax.el-3.0-b07.jar:3.0-b07]
> at javax.el.BeanELResolver.invoke(BeanELResolver.java:536) [javax.el-3.0-b07.jar:3.0-b07]
> at javax.el.CompositeELResolver.invoke(CompositeELResolver.java:256) [javax.el-3.0-b07.jar:3.0-b07]
> at com.sun.el.parser.AstValue.invoke(AstValue.java:269) [javax.el-3.0-b07.jar:3.0-b07]
> at com.sun.el.MethodExpressionImpl.invoke(MethodExpressionImpl.java:304) [javax.el-3.0-b07.jar:3.0-b07]
> at org.jboss.weld.util.el.ForwardingMethodExpression.invoke(ForwardingMethodExpression.java:40) [weld-core-impl-2.1.0.Beta1.jar:2013-09-05 17:01]
> at org.jboss.weld.el.WeldMethodExpression.invoke(WeldMethodExpression.java:50) [weld-core-impl-2.1.0.Beta1.jar:2013-09-05 17:01]
> at org.jboss.weld.util.el.ForwardingMethodExpression.invoke(ForwardingMethodExpression.java:40) [weld-core-impl-2.1.0.Beta1.jar:2013-09-05 17:01]
> at org.jboss.weld.el.WeldMethodExpression.invoke(WeldMethodExpression.java:50) [weld-core-impl-2.1.0.Beta1.jar:2013-09-05 17:01]
> at com.sun.faces.facelets.el.TagMethodExpression.invoke(TagMethodExpression.java:105) [jsf-impl-2.1.26.jar:2.1.26]
> at javax.faces.component.MethodBindingMethodExpressionAdapter.invoke(MethodBindingMethodExpressionAdapter.java:87) [jsf-api-2.1.26.jar:2.1]
> at com.sun.faces.application.ActionListenerImpl.processAction(ActionListenerImpl.java:101) [jsf-impl-2.1.26.jar:2.1.26]
> at javax.faces.component.UICommand.broadcast(UICommand.java:315) [jsf-api-2.1.26.jar:2.1]
> at javax.faces.component.UIViewRoot.broadcastEvents(UIViewRoot.java:786) [jsf-api-2.1.26.jar:2.1]
> at javax.faces.component.UIViewRoot.processApplication(UIViewRoot.java:1251) [jsf-api-2.1.26.jar:2.1]
> at com.sun.faces.lifecycle.InvokeApplicationPhase.execute(InvokeApplicationPhase.java:81) [jsf-impl-2.1.26.jar:2.1.26]
> at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101) [jsf-impl-2.1.26.jar:2.1.26]
> at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118) [jsf-impl-2.1.26.jar:2.1.26]
> at javax.faces.webapp.FacesServlet.service(FacesServlet.java:593) [jsf-api-2.1.26.jar:2.1]
> at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:87) [undertow-servlet-1.0.0.Beta13.jar:1.0.0.Beta13]
> at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:59) [undertow-servlet-1.0.0.Beta13.jar:1.0.0.Beta13]
> at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.0.0.Beta13.jar:1.0.0.Beta13]
> at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:81)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta13.jar:1.0.0.Beta13]
> at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:113) [undertow-servlet-1.0.0.Beta13.jar:1.0.0.Beta13]
> at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:52) [undertow-core-1.0.0.Beta13.jar:1.0.0.Beta13]
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.0.Beta13.jar:1.0.0.Beta13]
> at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) [undertow-core-1.0.0.Beta13.jar:1.0.0.Beta13]
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:65) [undertow-servlet-1.0.0.Beta13.jar:1.0.0.Beta13]
> at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:70) [undertow-core-1.0.0.Beta13.jar:1.0.0.Beta13]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta13.jar:1.0.0.Beta13]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta13.jar:1.0.0.Beta13]
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:209) [undertow-servlet-1.0.0.Beta13.jar:1.0.0.Beta13]
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:196) [undertow-servlet-1.0.0.Beta13.jar:1.0.0.Beta13]
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:69) [undertow-servlet-1.0.0.Beta13.jar:1.0.0.Beta13]
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:130) [undertow-servlet-1.0.0.Beta13.jar:1.0.0.Beta13]
> at io.undertow.server.HttpHandlers.executeRootHandler(HttpHandlers.java:36) [undertow-core-1.0.0.Beta13.jar:1.0.0.Beta13]
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:614) [undertow-core-1.0.0.Beta13.jar:1.0.0.Beta13]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_40]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_40]
> at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_40]
> Caused by: javax.validation.ConstraintViolationException: Validation failed for classes [testcase.domain.Customer] during persist time for groups [javax.validation.groups.Default, ]
> List of constraint violations:[
> ConstraintViolationImpl{interpolatedMessage='Min length = 2, max length = 32', propertyPath=name, rootBeanClass=class testcase.domain.Customer, messageTemplate='Min length = {min}, max length = {max}'}
> ConstraintViolationImpl{interpolatedMessage='Zip code is 5 digits', propertyPath=zip, rootBeanClass=class testcase.domain.Customer, messageTemplate='Zip code is 5 digits'}
> ConstraintViolationImpl{interpolatedMessage='A name must have one capital letter, followed by small letters', propertyPath=name, rootBeanClass=class testcase.domain.Customer, messageTemplate='A name must have one capital letter, followed by small letters'}
> ]
> at org.hibernate.cfg.beanvalidation.BeanValidationEventListener.validate(BeanValidationEventListener.java:159) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> at org.hibernate.cfg.beanvalidation.BeanValidationEventListener.onPreInsert(BeanValidationEventListener.java:94) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> at org.hibernate.action.internal.EntityInsertAction.preInsert(EntityInsertAction.java:196) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> at org.hibernate.action.internal.EntityInsertAction.execute(EntityInsertAction.java:96) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> at org.hibernate.engine.spi.ActionQueue.execute(ActionQueue.java:377) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> at org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:369) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> at org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:286) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> at org.hibernate.event.internal.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:340) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> at org.hibernate.event.internal.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:52) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> at org.hibernate.internal.SessionImpl.flush(SessionImpl.java:1235) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> at org.hibernate.internal.SessionImpl.managedFlush(SessionImpl.java:405) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> at org.hibernate.engine.transaction.synchronization.internal.SynchronizationCallbackCoordinatorImpl.beforeCompletion(SynchronizationCallbackCoordinatorImpl.java:113) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> ... 68 more
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 2 months