February 2014 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-1884) JBoss AS7 Management console not displaying

by Salim Badakhchani (JIRA)

[ https://issues.jboss.org/browse/WFLY-1884?page=com.atlassian.jira.plugin.... ] Salim Badakhchani closed WFLY-1884. ----------------------------------- Resolution: Rejected See https://bugzilla.redhat.com/show_bug.cgi?id=853457 > JBoss AS7 Management console not displaying > ------------------------------------------- > > Key: WFLY-1884 > URL: https://issues.jboss.org/browse/WFLY-1884 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Environment: Fedora 18 > java version "1.7.0_25" > OpenJDK Runtime Environment (fedora-2.3.10.4.fc18-x86_64) > OpenJDK 64-Bit Server VM (build 23.7-b01, mixed mode) > [standalone@localhost:9999 /] version > JBoss Admin Command-line Interface > JBOSS_HOME: /usr/share/jboss-as > JBoss AS release: 7.1.1.Final "Brontes" > JAVA_HOME: null > java.version: 1.7.0_25 > java.vm.vendor: Oracle Corporation > java.vm.version: 23.7-b01 > os.name: Linux > os.version: 3.10.4-100.fc18.x86_64 > Reporter: Salim Badakhchani > Labels: admin-console, blank, jboss > > After installing via yum and creating an admin user via add-user.sh script I get a blank page when clicking the link to the Administration Console from the welcome page. This is not a remote login attempt and I can connect via the cli. -- 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, 11 months

1
0
0 / 0

[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 commented on WFLY-2852: ----------------------------------- Are you using CMT or are you controlling the transaction remotely via UserTransaction? > 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

11 years, 11 months

1
0
0 / 0

[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 commented on WFLY-2852: ----------------------------------- I think the correct behavior here is for the UserTransaction to control the transaction timeout. > 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

11 years, 11 months

1
0
0 / 0

[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

11 years, 11 months

1
0
0 / 0

[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

11 years, 11 months

1
0
0 / 0

[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

11 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2333) Web deployment code assumes only a single ServletContainerInitializer is present in each jar

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-2333?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated WFLY-2333: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1060740 > Web deployment code assumes only a single ServletContainerInitializer is present in each jar > -------------------------------------------------------------------------------------------- > > Key: WFLY-2333 > URL: https://issues.jboss.org/browse/WFLY-2333 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Web (Undertow) > Affects Versions: 8.0.0.Beta1 > Reporter: Stuart Douglas > Assignee: Stuart Douglas > Fix For: 8.0.0.CR1 > > Attachments: diycdemo.zip, hellomyfaces.zip > > -- 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, 11 months

1
0
0 / 0

[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

11 years, 11 months

1
0
0 / 0

[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

11 years, 11 months

1
0
0 / 0

[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

11 years, 11 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira February 2014