[JBoss JIRA] (WFLY-7050) JDK ORB char conversion preceeded by empty string conversion fails with ArrayIndexOutOfBoundsException
by Konstantin Glazkov (JIRA)
[ https://issues.jboss.org/browse/WFLY-7050?page=com.atlassian.jira.plugin.... ]
Konstantin Glazkov updated WFLY-7050:
-------------------------------------
Steps to Reproduce:
ostream.write_string ("");
ostream.write_char (' ');
JUnit test is in attachment "empty_string_followed_by_char_conversion_unit_test.patch"
was:
ostream.write_string ("");
ostream.write_char (' ');
JUnit test is in attachment "empty_string_followed_by_char_conversion_unit_test_fix.patch"
> JDK ORB char conversion preceeded by empty string conversion fails with ArrayIndexOutOfBoundsException
> ------------------------------------------------------------------------------------------------------
>
> Key: WFLY-7050
> URL: https://issues.jboss.org/browse/WFLY-7050
> Project: WildFly
> Issue Type: Bug
> Components: IIOP
> Affects Versions: 10.1.0.Final
> Reporter: Konstantin Glazkov
> Assignee: Tomasz Adamski
> Attachments: empty_string_followed_by_char_conversion_suggested_fix.patch, empty_string_followed_by_char_conversion_unit_test.patch, empty_string_followed_by_char_conversion_unit_test_fix.patch
>
>
> If IDL structure contains string and char fields, and generated *Helper#write method looks like
> ostream.write_string (value.string_field); //empty string
> ostream.write_char (value.char_field); //any char
> without non-empty strings before char field, then write_char method will fail with stacktrace:
> Caused by: java.lang.ArrayIndexOutOfBoundsException: 0
> at com.sun.corba.se.impl.encoding.CodeSetConversion$JavaCTBConverter.convert(CodeSetConversion.java:206) [openjdk-orb-8.0.6.Final.jar:8.0.6.Final]
> at com.sun.corba.se.impl.encoding.CDROutputStream_1_0.write_char(CDROutputStream_1_0.java:318) [openjdk-orb-8.0.6.Final.jar:8.0.6.Final]
> at com.sun.corba.se.impl.encoding.CDROutputStream.write_char(CDROutputStream.java:138) [openjdk-orb-8.0.6.Final.jar:8.0.6.Final]
> at SomeClassHelper.write(SomeClassHelper.java:<some line>)
> Suggested fix is in attachment "empty_string_followed_by_char_conversion_suggested_fix.patch"
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFLY-7050) JDK ORB char conversion preceeded by empty string conversion fails with ArrayIndexOutOfBoundsException
by Konstantin Glazkov (JIRA)
[ https://issues.jboss.org/browse/WFLY-7050?page=com.atlassian.jira.plugin.... ]
Konstantin Glazkov updated WFLY-7050:
-------------------------------------
Attachment: empty_string_followed_by_char_conversion_unit_test.patch
> JDK ORB char conversion preceeded by empty string conversion fails with ArrayIndexOutOfBoundsException
> ------------------------------------------------------------------------------------------------------
>
> Key: WFLY-7050
> URL: https://issues.jboss.org/browse/WFLY-7050
> Project: WildFly
> Issue Type: Bug
> Components: IIOP
> Affects Versions: 10.1.0.Final
> Reporter: Konstantin Glazkov
> Assignee: Tomasz Adamski
> Attachments: empty_string_followed_by_char_conversion_suggested_fix.patch, empty_string_followed_by_char_conversion_unit_test.patch, empty_string_followed_by_char_conversion_unit_test_fix.patch
>
>
> If IDL structure contains string and char fields, and generated *Helper#write method looks like
> ostream.write_string (value.string_field); //empty string
> ostream.write_char (value.char_field); //any char
> without non-empty strings before char field, then write_char method will fail with stacktrace:
> Caused by: java.lang.ArrayIndexOutOfBoundsException: 0
> at com.sun.corba.se.impl.encoding.CodeSetConversion$JavaCTBConverter.convert(CodeSetConversion.java:206) [openjdk-orb-8.0.6.Final.jar:8.0.6.Final]
> at com.sun.corba.se.impl.encoding.CDROutputStream_1_0.write_char(CDROutputStream_1_0.java:318) [openjdk-orb-8.0.6.Final.jar:8.0.6.Final]
> at com.sun.corba.se.impl.encoding.CDROutputStream.write_char(CDROutputStream.java:138) [openjdk-orb-8.0.6.Final.jar:8.0.6.Final]
> at SomeClassHelper.write(SomeClassHelper.java:<some line>)
> Suggested fix is in attachment "empty_string_followed_by_char_conversion_suggested_fix.patch"
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFLY-6127) Throw IllegalStateException if JTA tx has an unsynchronized persistence context and the target is synchronized persistence context
by Viacheslav Astapkovich (JIRA)
[ https://issues.jboss.org/browse/WFLY-6127?page=com.atlassian.jira.plugin.... ]
Viacheslav Astapkovich edited comment on WFLY-6127 at 9/5/16 11:54 AM:
-----------------------------------------------------------------------
*The obtained defect:*
A defect related to the check of synchronization type (to satisfy JPA spec 2.1 section 7.6.4.1) was found in WildFly 10.1.0.Final.
The Method getSynchronizationType of ExtendedEntityManager class ALWAYS returns SYNCHRONIZED type of synchronization.
*FIX:*
We created a fork of WildFly-jpa project at: https://github.com/argustelecom/wildfly/tree/WFLY-6127
Our Fix commit: https://github.com/wildfly/wildfly/commit/3bff5fde3cfc23f3999dc75c320029e...
Corrections: The method getSynchronizationType returns declared synchronization type.
*Effect:*
We use our own realization of Martin Fowler’s pattern "Unit of Work". We initialize Unsynchronized Extended Persistence Context and our realization controls the synchronization with transaction.
Our Beans can be controlled by UnitOfWork, as well as be used as a part of WebService call.
This requires the declaration of synchronized persistence context.
We catch IllegalStateException after we have fixed the defect of synchronization type determination, because we initialize UNSYNCHRONIZED persistence context, but we declare synchronized persistence context in our beans.
However, our UnitOfWork realization controls synchronization of persistence context and we can synchronize context before the synchronization type check.
*Our actions:*
We had to add the possibility to check synchronization type in the testForMixedSynchronizationTypes method of TransactionScopedEntityManager class by isJoinToTransaction method (i.e. the actual type of synchronization).
This ability is realized by property "jboss.as.jpa.syncasjoin" in persistence.xml file. Only if this property is set to true - we perform testForMixedSynchronizationTypes by isJoinToTransaction method. The system operates as usual if this property is not defined or set to false.
Commit: https://github.com/wildfly/wildfly/commit/195a8a65a9fae006ad603e425f6a16d...
*Commentary:*
Though our actions deviate from JPA SPEC, we have a valid reason for acting this way:
- A question arose in the development process of the JPA specification : "Should we relax this if the PC has been joined to the transaction?".
Unfortunately, no feedback was given and Linda DeMichiel decided to keep it as it was
( https://java.net/projects/jpa-spec/lists/jsr338-experts/archive/2011-08/m... )
- We found a JIRA task https://java.net/jira/browse/JPA_SPEC-6 . And it was also closed too: "No feedback in favor of changing current approach"
was (Author: veselroger):
*The obtained defect:*
A defect related to the check of synchronization type (to satisfy JPA spec 2.1 section 7.6.4.1) was found in WildFly 10.1.0.Final.
The Method getSynchronizationType of ExtendedEntityManager class ALWAYS returns SYNCHRONIZED type of synchronization.
*FIX:*
We created a fork of WildFly-jpa project at: https://github.com/argustelecom/wildfly/tree/WFLY-6127
Our Fix commit: https://github.com/wildfly/wildfly/commit/3bff5fde3cfc23f3999dc75c320029e...
Corrections: The method getSynchronizationType returns declared synchronization type.
*Effect:*
We use our own realization of Martin Fowler’s pattern "Unit of Work". We initialize Unsynchronized Extended Persistence Context and our realization controls the synchronization with transaction.
Our Beans can be controlled by UnitOfWork, as well as be used as a part of WebService.
This requires the declaration of synchronized persistence context.
We catch IllegalStateException after we have fixed the defect of synchronization type determination, because we initialize UNSYNCHRONIZED persistence context, but we declare synchronized persistence context in our beans.
However, our UnitOfWork realization controls synchronization of persistence context and we can synchronize context before the synchronization type check.
*Our actions:*
We had to add the possibility to check synchronization type in the testForMixedSynchronizationTypes method of TransactionScopedEntityManager class by isJoinToTransaction method (i.e. the actual type of synchronization).
This ability is realized by property "jboss.as.jpa.syncasjoin" in persistence.xml file. Only if this property is set to true - we perform testForMixedSynchronizationTypes by isJoinToTransaction method. The system operates as usual if this property is not defined or set to false.
*Commentary:*
Though our actions deviate from JPA SPEC, we have a valid reason for acting this way:
- A question arose in the development process of the JPA specification : "Should we relax this if the PC has been joined to the transaction?".
Unfortunately, no feedback was given and Linda DeMichiel decided to keep it as it was
( https://java.net/projects/jpa-spec/lists/jsr338-experts/archive/2011-08/m... )
- We found a JIRA task https://java.net/jira/browse/JPA_SPEC-6 . And it was also closed too: "No feedback in favor of changing current approach"
> Throw IllegalStateException if JTA tx has an unsynchronized persistence context and the target is synchronized persistence context
> ----------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-6127
> URL: https://issues.jboss.org/browse/WFLY-6127
> Project: WildFly
> Issue Type: Bug
> Components: JPA / Hibernate
> Affects Versions: 9.0.2.Final
> Reporter: Mazen Mahmoud
> Assignee: Scott Marlow
> Priority: Blocker
> Fix For: 10.1.0.CR1, 10.1.0.Final
>
> Attachments: server-log.txt
>
>
> SPEC: If a component is called and the JTA transaction is propagated into that component:
> If there is a persistence context of type SynchronizationType.UNSYNCHRONIZED
> associated with the JTA transaction and the target component specifies a persistence context of type SynchronizationType.SYNCHRONIZED, the IllegalStateException is thrown by the container
> We have a stateful session bean (SFB1) / PC: TRANSACTION/UNSYNCHRONIZED)
> stateful session bean (SFB2) / PC: TRANSACTION/SYNCHRONIZED)
> SFB1 method M1 (REQUIRED) calls SFB2 Method 2 (REQUIRED):
> PC is propagated from SFB1 to SFB2 without any exception.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFLY-7050) JDK ORB char conversion preceeded by empty string conversion fails with ArrayIndexOutOfBoundsException
by Konstantin Glazkov (JIRA)
Konstantin Glazkov created WFLY-7050:
----------------------------------------
Summary: JDK ORB char conversion preceeded by empty string conversion fails with ArrayIndexOutOfBoundsException
Key: WFLY-7050
URL: https://issues.jboss.org/browse/WFLY-7050
Project: WildFly
Issue Type: Bug
Components: IIOP
Affects Versions: 10.1.0.Final
Reporter: Konstantin Glazkov
Assignee: Tomasz Adamski
Attachments: empty_string_followed_by_char_conversion_suggested_fix.patch, empty_string_followed_by_char_conversion_unit_test_fix.patch
If IDL structure contains string and char fields, and generated *Helper#write method looks like
ostream.write_string (value.string_field); //empty string
ostream.write_char (value.char_field); //any char
without non-empty strings before char field, then write_char method will fail with stacktrace:
Caused by: java.lang.ArrayIndexOutOfBoundsException: 0
at com.sun.corba.se.impl.encoding.CodeSetConversion$JavaCTBConverter.convert(CodeSetConversion.java:206) [openjdk-orb-8.0.6.Final.jar:8.0.6.Final]
at com.sun.corba.se.impl.encoding.CDROutputStream_1_0.write_char(CDROutputStream_1_0.java:318) [openjdk-orb-8.0.6.Final.jar:8.0.6.Final]
at com.sun.corba.se.impl.encoding.CDROutputStream.write_char(CDROutputStream.java:138) [openjdk-orb-8.0.6.Final.jar:8.0.6.Final]
at SomeClassHelper.write(SomeClassHelper.java:<some line>)
Suggested fix is in attachment "empty_string_followed_by_char_conversion_suggested_fix.patch"
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFLY-6127) Throw IllegalStateException if JTA tx has an unsynchronized persistence context and the target is synchronized persistence context
by Viacheslav Astapkovich (JIRA)
[ https://issues.jboss.org/browse/WFLY-6127?page=com.atlassian.jira.plugin.... ]
Viacheslav Astapkovich edited comment on WFLY-6127 at 9/5/16 11:51 AM:
-----------------------------------------------------------------------
*The obtained defect:*
A defect related to the check of synchronization type (to satisfy JPA spec 2.1 section 7.6.4.1) was found in WildFly 10.1.0.Final.
The Method getSynchronizationType of ExtendedEntityManager class ALWAYS returns SYNCHRONIZED type of synchronization.
*FIX:*
We created a fork of WildFly-jpa project at: https://github.com/argustelecom/wildfly/tree/WFLY-6127
Our Fix commit: https://github.com/wildfly/wildfly/commit/3bff5fde3cfc23f3999dc75c320029e...
Corrections: The method getSynchronizationType returns declared synchronization type.
*Effect:*
We use our own realization of Martin Fowler’s pattern "Unit of Work". We initialize Unsynchronized Extended Persistence Context and our realization controls the synchronization with transaction.
Our Beans can be controlled by UnitOfWork, as well as be used as a part of WebService.
This requires the declaration of synchronized persistence context.
We catch IllegalStateException after we have fixed the defect of synchronization type determination, because we initialize UNSYNCHRONIZED persistence context, but we declare synchronized persistence context in our beans.
However, our UnitOfWork realization controls synchronization of persistence context and we can synchronize context before the synchronization type check.
*Our actions:*
We had to add the possibility to check synchronization type in the testForMixedSynchronizationTypes method of TransactionScopedEntityManager class by isJoinToTransaction method (i.e. the actual type of synchronization).
This ability is realized by property "jboss.as.jpa.syncasjoin" in persistence.xml file. Only if this property is set to true - we perform testForMixedSynchronizationTypes by isJoinToTransaction method. The system operates as usual if this property is not defined or set to false.
*Commentary:*
Though our actions deviate from JPA SPEC, we have a valid reason for acting this way:
- A question arose in the development process of the JPA specification : "Should we relax this if the PC has been joined to the transaction?".
Unfortunately, no feedback was given and Linda DeMichiel decided to keep it as it was
( https://java.net/projects/jpa-spec/lists/jsr338-experts/archive/2011-08/m... )
- We found a JIRA task https://java.net/jira/browse/JPA_SPEC-6 . And it was also closed too: "No feedback in favor of changing current approach"
was (Author: veselroger):
*The obtained defect:*
A defect related to the check of synchronization type (to satisfy JPA spec 2.1 section 7.6.4.1) was found in WildFly 10.1.0.Final.
The Method getSynchronizationType of ExtendedEntityManager class ALWAYS returns SYNCHRONIZED type of synchronization.
*FIX:*
We created a fork of WildFly-jpa project at: https://github.com/argustelecom/wildfly/tree/WFLY-6127
Our Fix commit: https://github.com/wildfly/wildfly/commit/3bff5fde3cfc23f3999dc75c320029e...
Corrections: The method getSynchronizationType returns declared synchronization type.
*Effect:*
We use our own realization of Martin Fowler’s pattern "Unit of Work". We initialize Unsynchronized Extended Persistence Context and our realization controls the synchronization with transaction.
Our Beans can be controlled by UnitOfWork, as well as be used as a part of WebService.
This requires the declaration of synchronized persistence context.
We catch IllegalStateException after we have fixed the defect of synchronization type determination, because we initialize UNSYNCHRONIZED persistence context, but we declare synchronized persistence context in our beans.
However, our UnitOfWork realization controls synchronization of persistence context and we can synchronize context before the synchronization type check.
*Our actions:*
We had to add the possibility to check synchronization type in the testForMixedSynchronizationTypes method of TransactionScopedEntityManager class by isJoinToTransaction method (i.e. the actual type of synchronization).
This ability is realized by property "jboss.as.jpa.syncasjoin" in persistence.xml file. Only if this property is set to true - we perform testForMixedSynchronizationTypes by isJoinToTransaction method. The system operates as usual if this property is not defined or set to false.
*Commentary:*
Though our actions deviate from JPA SPEC, we have a valid reason for acting this way:
- A question arose in the development process of the JPA specification : "Should we relax this if the PC has been joined to the transaction?".
Unfortunately, no feedback was given and Linda DeMichiel decided to keep it as it was
( https://java.net/projects/jpa-spec/lists/jsr338-experts/archive/2011-08/m... )
- We also found a JIRA task https://java.net/jira/browse/JPA_SPEC-6 . And it was closed too because "No feedback in favor of changing current approach"
> Throw IllegalStateException if JTA tx has an unsynchronized persistence context and the target is synchronized persistence context
> ----------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-6127
> URL: https://issues.jboss.org/browse/WFLY-6127
> Project: WildFly
> Issue Type: Bug
> Components: JPA / Hibernate
> Affects Versions: 9.0.2.Final
> Reporter: Mazen Mahmoud
> Assignee: Scott Marlow
> Priority: Blocker
> Fix For: 10.1.0.CR1, 10.1.0.Final
>
> Attachments: server-log.txt
>
>
> SPEC: If a component is called and the JTA transaction is propagated into that component:
> If there is a persistence context of type SynchronizationType.UNSYNCHRONIZED
> associated with the JTA transaction and the target component specifies a persistence context of type SynchronizationType.SYNCHRONIZED, the IllegalStateException is thrown by the container
> We have a stateful session bean (SFB1) / PC: TRANSACTION/UNSYNCHRONIZED)
> stateful session bean (SFB2) / PC: TRANSACTION/SYNCHRONIZED)
> SFB1 method M1 (REQUIRED) calls SFB2 Method 2 (REQUIRED):
> PC is propagated from SFB1 to SFB2 without any exception.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFLY-6127) Throw IllegalStateException if JTA tx has an unsynchronized persistence context and the target is synchronized persistence context
by Viacheslav Astapkovich (JIRA)
[ https://issues.jboss.org/browse/WFLY-6127?page=com.atlassian.jira.plugin.... ]
Viacheslav Astapkovich commented on WFLY-6127:
----------------------------------------------
*The obtained defect:*
A defect related to the check of synchronization type (to satisfy JPA spec 2.1 section 7.6.4.1) was found in WildFly 10.1.0.Final.
The Method getSynchronizationType of ExtendedEntityManager class ALWAYS returns SYNCHRONIZED type of synchronization.
*FIX:*
We created a fork of WildFly-jpa project at: https://github.com/argustelecom/wildfly/tree/WFLY-6127
Our Fix commit: https://github.com/wildfly/wildfly/commit/3bff5fde3cfc23f3999dc75c320029e...
Corrections: The method getSynchronizationType returns declared synchronization type.
*Effect:*
We use our own realization of Martin Fowler’s pattern "Unit of Work". We initialize Unsynchronized Extended Persistence Context and our realization controls the synchronization with transaction.
Our Beans can be controlled by UnitOfWork, as well as be used as a part of WebService.
This requires the declaration of synchronized persistence context.
We catch IllegalStateException after we have fixed the defect of synchronization type determination, because we initialize UNSYNCHRONIZED persistence context, but we declare synchronized persistence context in our beans.
However, our UnitOfWork realization controls synchronization of persistence context and we can synchronize context before the synchronization type check.
*Our actions:*
We had to add the possibility to check synchronization type in the testForMixedSynchronizationTypes method of TransactionScopedEntityManager class by isJoinToTransaction method (i.e. the actual type of synchronization).
This ability is realized by property "jboss.as.jpa.syncasjoin" in persistence.xml file. Only if this property is set to true - we perform testForMixedSynchronizationTypes by isJoinToTransaction method. The system operates as usual if this property is not defined or set to false.
*Commentary:*
Though our actions deviate from JPA SPEC, we have a valid reason for acting this way:
- A question arose in the development process of the JPA specification : "Should we relax this if the PC has been joined to the transaction?".
Unfortunately, no feedback was given and Linda DeMichiel decided to keep it as it was
( https://java.net/projects/jpa-spec/lists/jsr338-experts/archive/2011-08/m... )
- We also found a JIRA task https://java.net/jira/browse/JPA_SPEC-6 . And it was closed too because "No feedback in favor of changing current approach"
> Throw IllegalStateException if JTA tx has an unsynchronized persistence context and the target is synchronized persistence context
> ----------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-6127
> URL: https://issues.jboss.org/browse/WFLY-6127
> Project: WildFly
> Issue Type: Bug
> Components: JPA / Hibernate
> Affects Versions: 9.0.2.Final
> Reporter: Mazen Mahmoud
> Assignee: Scott Marlow
> Priority: Blocker
> Fix For: 10.1.0.CR1, 10.1.0.Final
>
> Attachments: server-log.txt
>
>
> SPEC: If a component is called and the JTA transaction is propagated into that component:
> If there is a persistence context of type SynchronizationType.UNSYNCHRONIZED
> associated with the JTA transaction and the target component specifies a persistence context of type SynchronizationType.SYNCHRONIZED, the IllegalStateException is thrown by the container
> We have a stateful session bean (SFB1) / PC: TRANSACTION/UNSYNCHRONIZED)
> stateful session bean (SFB2) / PC: TRANSACTION/SYNCHRONIZED)
> SFB1 method M1 (REQUIRED) calls SFB2 Method 2 (REQUIRED):
> PC is propagated from SFB1 to SFB2 without any exception.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (GPD-98) GPD creates invalid gpd.xml when nodes contain special characters on Windows
by Koen Aers (JIRA)
[ https://issues.jboss.org/browse/GPD-98?page=com.atlassian.jira.plugin.sys... ]
Koen Aers resolved GPD-98.
--------------------------
Resolution: Out of Date
> GPD creates invalid gpd.xml when nodes contain special characters on Windows
> -----------------------------------------------------------------------------
>
> Key: GPD-98
> URL: https://issues.jboss.org/browse/GPD-98
> Project: jBPM GPD
> Issue Type: Bug
> Components: jpdl
> Affects Versions: jBPM JPDL Designer 3.0.13, jBPM JPDL Designer 3.1.0.alpha4
> Environment: Windows XP, Eclipse 3.2.1
> Reporter: Martin Weiler
> Assignee: Koen Aers
> Fix For: jBPM jPDL Designer 3.x
>
> Attachments: processdefintion.xml
>
>
> A process with a node containing a special character, such as <start-state name="Début">, leads to an invalid gpd.xml. This is reproducible with the attached sample processdefinition.xml on a Windows machine.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months