February 2014 - jboss-jira - Jboss List Archives

[JBoss JIRA] (JGRP-1779) MethodCall: implement Streamable

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1779?page=com.atlassian.jira.plugin.... ] Bela Ban resolved JGRP-1779. ---------------------------- Resolution: Done > MethodCall: implement Streamable > -------------------------------- > > Key: JGRP-1779 > URL: https://issues.jboss.org/browse/JGRP-1779 > Project: JGroups > Issue Type: Enhancement > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Minor > Fix For: 3.5 > > > MethodCall currently only implements Externalizable. By implementing Streamable, marshalling and unmarshalling should be faster, for simple arguments. -- 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

12 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JBLOGGING-95) Add Logger/LoggerProvider to support new Log4j 2 to improve performance

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/JBLOGGING-95?page=com.atlassian.jira.plug... ] David Lloyd commented on JBLOGGING-95: -------------------------------------- No problem, I've released 3.2.0.Beta1 for you. > Add Logger/LoggerProvider to support new Log4j 2 to improve performance > ----------------------------------------------------------------------- > > Key: JBLOGGING-95 > URL: https://issues.jboss.org/browse/JBLOGGING-95 > Project: JBoss Logging > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: jboss-logging-spi > Affects Versions: 3.2.0.Beta1 > Reporter: Nicholas Williams > Assignee: David Lloyd > Priority: Minor > Fix For: 3.2.0.Beta1 > > Original Estimate: 1 day > Remaining Estimate: 1 day > > The new Log4j 2 project will be released soon. It has major improvements over Log4j and Logback. Currently, JBoss Logging can log to Log4j 2 indirectly by way of SLF4J (if the log4j-slf4j artifact is on the classpath) or the Log4j 1.2 API (if the log4j-1.2-api artifact is on the classpath and when JBLOGGING-94 is fixed). However, performance would be improved if JBoss Logging could log directly to the Log4j 2 API. > Looks like we just need a new {{Log4j2Logger}} and {{Log4j2LoggerProvider}}. I'll try to submit a pull request in the next few weeks. I'm currently working on other tasks in Log4j 2. -- 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

12 years, 3 months

1
0
0 / 0

[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 commented on WFLY-1884: ----------------------------------------- This is not a bug... 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

12 years, 3 months

1
0
0 / 0

[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

12 years, 3 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

12 years, 3 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

12 years, 3 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

12 years, 3 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

12 years, 3 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

12 years, 3 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

12 years, 3 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