[JBoss JIRA] (WFLY-2852) JBoss 7 - EJB Remote Transaction Timeout
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/WFLY-2852?page=com.atlassian.jira.plugin.... ]
David Lloyd reassigned WFLY-2852:
---------------------------------
Assignee: David Lloyd
> JBoss 7 - EJB Remote Transaction Timeout
> ----------------------------------------
>
> Key: WFLY-2852
> URL: https://issues.jboss.org/browse/WFLY-2852
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Reporter: Sfe Br
> Assignee: David Lloyd
> Labels: jboss
> Fix For: JBoss AS7 7.2.0.Final
>
>
> I have a remote call that allow to run a process that takes more than 5 minutes, after passing this time the transaction was canceled and the global transaction was rollbacked at the commit phase.
> The problem is that i can't modify the timeout value.
> Note: After consulting the method createOrResumeXidTransaction of the EJBRemoteTransactionPropagatingInterceptor class, I found that the timeout value is always 300 seconds (it seems that this value is hardcoded)
> You can refer to my discussion with jaikiran pai: https://community.jboss.org/thread/236493
> Thanks,
--
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
10 years, 11 months
[JBoss JIRA] (WFLY-943) XML schema; use of elementFormDefault='unqualified'; cannot validate some documents
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-943?page=com.atlassian.jira.plugin.s... ]
Radoslav Husar commented on WFLY-943:
-------------------------------------
Looking at the source code, it looks like the JPA one is never used?
{noformat}
jpa/core/src/main/java/org/jboss/as/jpa/processor/JPAJarJBossAllParser.java:
public static final QName ROOT_ELEMENT = new QName("http://www.jboss.com/xml/ns/javaee", "jboss-jpa");
{noformat}
Ouch. And if we were to fix that we would have to keep the backward compatibility..
> XML schema; use of elementFormDefault='unqualified'; cannot validate some documents
> -----------------------------------------------------------------------------------
>
> Key: WFLY-943
> URL: https://issues.jboss.org/browse/WFLY-943
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Documentation
> Affects Versions: 8.0.0.Alpha3
> Reporter: Elias Ross
> Assignee: Radoslav Husar
> Fix For: 8.0.0.Final
>
> Attachments: jboss-deployment-structure.xml
>
>
> When attempting to write a (seemingly) valid jboss-deployment-structure.xml using the schema in ./docs, my document fails to validate.
> This is because of the settings used in the XSD. Have these XSDs been used to validate actual documents? By setting unqualified to 'qualified' then the documents will probably validate.
> $ git grep elementFormDefault..unqualified
> jboss-deployment-dependencies-1_0.xsd: elementFormDefault="unqualified"
> jboss-deployment-structure-1_0.xsd: elementFormDefault="unqualified"
> jboss-deployment-structure-1_1.xsd: elementFormDefault="unqualified"
> jboss-deployment-structure-1_2.xsd: elementFormDefault="unqualified"
> jboss-ejb-client_1_0.xsd: elementFormDefault="unqualified"
> jboss-ejb-client_1_1.xsd: elementFormDefault="unqualified"
> jboss-ejb-client_1_2.xsd: elementFormDefault="unqualified"
> jboss-jpa_1_0.xsd: elementFormDefault="unqualified"
--
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
10 years, 11 months
[JBoss JIRA] (WFLY-943) XML schema; use of elementFormDefault='unqualified'; cannot validate some documents
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-943?page=com.atlassian.jira.plugin.s... ]
Radoslav Husar reassigned WFLY-943:
-----------------------------------
Assignee: Radoslav Husar
No, the ejb-client schemas are not fixed and they need a fix.
The other 2 are unchanged, deployment-dependencies and jpa and might need a fix.
> XML schema; use of elementFormDefault='unqualified'; cannot validate some documents
> -----------------------------------------------------------------------------------
>
> Key: WFLY-943
> URL: https://issues.jboss.org/browse/WFLY-943
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Documentation
> Affects Versions: 8.0.0.Alpha3
> Reporter: Elias Ross
> Assignee: Radoslav Husar
> Fix For: 8.0.0.Final
>
> Attachments: jboss-deployment-structure.xml
>
>
> When attempting to write a (seemingly) valid jboss-deployment-structure.xml using the schema in ./docs, my document fails to validate.
> This is because of the settings used in the XSD. Have these XSDs been used to validate actual documents? By setting unqualified to 'qualified' then the documents will probably validate.
> $ git grep elementFormDefault..unqualified
> jboss-deployment-dependencies-1_0.xsd: elementFormDefault="unqualified"
> jboss-deployment-structure-1_0.xsd: elementFormDefault="unqualified"
> jboss-deployment-structure-1_1.xsd: elementFormDefault="unqualified"
> jboss-deployment-structure-1_2.xsd: elementFormDefault="unqualified"
> jboss-ejb-client_1_0.xsd: elementFormDefault="unqualified"
> jboss-ejb-client_1_1.xsd: elementFormDefault="unqualified"
> jboss-ejb-client_1_2.xsd: elementFormDefault="unqualified"
> jboss-jpa_1_0.xsd: elementFormDefault="unqualified"
--
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
10 years, 11 months
[JBoss JIRA] (WFLY-2161) JBAS014356 exception not thrown for @Asyncronous EJB methods
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-2161?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration updated WFLY-2161:
------------------------------------------
Bugzilla Update: Perform
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1060734
> JBAS014356 exception not thrown for @Asyncronous EJB methods
> ------------------------------------------------------------
>
> Key: WFLY-2161
> URL: https://issues.jboss.org/browse/WFLY-2161
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: EJB
> Affects Versions: 8.0.0.Alpha4
> Reporter: James Livingston
> Assignee: Stuart Douglas
> Fix For: 8.0.0.CR1
>
>
> If you call an ejb method with default visibility (e.g. from a servlet in the same package), an EJBException with code JBAS014356 is thrown because the method is not public.
> If the method is annotated with @Asynchronous and returns void, the exception is not seen because the interceptor from AsyncFutureInterceptorFactory is used before NotBusinessMethodInterceptor, the exception is thrown in the worker thread instead.
> With a void return, the exception is silently dropped. With a Future<?> return, it will be set as the failure exception on the future rather than being thrown from the call.
> As per the forum reference we need to check the spec, but the validity of the business method should probably be checked before the handoff to the worker thread.
--
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
10 years, 11 months
[JBoss JIRA] (JGRP-1786) DefaultTimeScheduler: unit test fails
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1786?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-1786:
---------------------------
Summary: DefaultTimeScheduler: unit test fails (was: 3.5)
> DefaultTimeScheduler: unit test fails
> -------------------------------------
>
> Key: JGRP-1786
> URL: https://issues.jboss.org/browse/JGRP-1786
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.2.13
> Environment: RHEL 5 x86_64
> Windows x86_64
> Reporter: Richard Achmatowicz
> Assignee: Bela Ban
> Fix For: 3.5
>
>
> The test case starts off by scheduling a timer task using the DefaultTimeScheduler and then sleeping, waiting for the task to execute
> Instead of the task being executed, the call to sleep is interrupted and the test case fails with an interrupted exception. Catching this interrupted exception shows that the task has not had a chance to execute before the sleep was interrupted.
> The same test case passes with the other two TimeScheduler implementations: TimeScheduler2 and HashedTimingWheel.
>
--
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
10 years, 11 months
[JBoss JIRA] (JGRP-1786) 3.5
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1786?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1786:
--------------------------------
craps ! Do you remember the original subject ?
> 3.5
> ---
>
> Key: JGRP-1786
> URL: https://issues.jboss.org/browse/JGRP-1786
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.2.13
> Environment: RHEL 5 x86_64
> Windows x86_64
> Reporter: Richard Achmatowicz
> Assignee: Bela Ban
> Fix For: 3.5
>
>
> The test case starts off by scheduling a timer task using the DefaultTimeScheduler and then sleeping, waiting for the task to execute
> Instead of the task being executed, the call to sleep is interrupted and the test case fails with an interrupted exception. Catching this interrupted exception shows that the task has not had a chance to execute before the sleep was interrupted.
> The same test case passes with the other two TimeScheduler implementations: TimeScheduler2 and HashedTimingWheel.
>
--
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
10 years, 11 months
[JBoss JIRA] (JGRP-1786) 3.5
by Richard Achmatowicz (JIRA)
[ https://issues.jboss.org/browse/JGRP-1786?page=com.atlassian.jira.plugin.... ]
Richard Achmatowicz commented on JGRP-1786:
-------------------------------------------
Bela, did you intend to change the subject to 3.5? I assume it was an accident!
> 3.5
> ---
>
> Key: JGRP-1786
> URL: https://issues.jboss.org/browse/JGRP-1786
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.2.13
> Environment: RHEL 5 x86_64
> Windows x86_64
> Reporter: Richard Achmatowicz
> Assignee: Bela Ban
> Fix For: 3.5
>
>
> The test case starts off by scheduling a timer task using the DefaultTimeScheduler and then sleeping, waiting for the task to execute
> Instead of the task being executed, the call to sleep is interrupted and the test case fails with an interrupted exception. Catching this interrupted exception shows that the task has not had a chance to execute before the sleep was interrupted.
> The same test case passes with the other two TimeScheduler implementations: TimeScheduler2 and HashedTimingWheel.
>
--
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
10 years, 11 months
[JBoss JIRA] (WFLY-2851) Can't validate jboss-deployment-structure.xml due to incorrect schema
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-2851?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration updated WFLY-2851:
------------------------------------------
Bugzilla Update: Perform
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1060719
> Can't validate jboss-deployment-structure.xml due to incorrect schema
> ---------------------------------------------------------------------
>
> Key: WFLY-2851
> URL: https://issues.jboss.org/browse/WFLY-2851
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 8.0.0.CR1
> Reporter: Harald Wellmann
> Assignee: Stuart Douglas
>
> The following deployment structure cannot be validated against the XML schema:
> {code:xml}
> <jboss-deployment-structure xmlns="urn:jboss:deployment-structure:1.2">
> <deployment>
> <dependencies>
> <module name="foo"/>
> </dependencies>
> </deployment>
> </jboss-deployment-structure>
> {code}
> This looks like a glitch in the schema where the {{module-alias}} element in {{deploymentType}} is missing a {{minOccurs="0"}}.
> The same holds for the {{filter}} element of {{resource-root}}, which should be optional according to the schema documentation.
--
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
10 years, 11 months