January 2014 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-2635) HTTP Management Interface Configuration

by Andre Dietisheim (JIRA)

[ https://issues.jboss.org/browse/WFLY-2635?page=com.atlassian.jira.plugin.... ] Andre Dietisheim commented on WFLY-2635: ---------------------------------------- I^d be glad to contribute at least the parts that are related to the management-filters. Should we create sub-tasks? > HTTP Management Interface Configuration > --------------------------------------- > > Key: WFLY-2635 > URL: https://issues.jboss.org/browse/WFLY-2635 > Project: WildFly > Issue Type: Task > Security Level: Public(Everyone can see) > Components: Domain Management > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 9.0.0.CR1 > > > Various configuration items are required for the HTTP Management interface, this is a parent task to combine them. -- 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, 12 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2698) Transaction Aware EE Concurrency EJB Context Handle

by Eduardo Martins (JIRA)

[ https://issues.jboss.org/browse/WFLY-2698?page=com.atlassian.jira.plugin.... ] Eduardo Martins commented on WFLY-2698: --------------------------------------- the allows tasks created by CMT EJB to access UserTransaction, as mandated by JSR 236 > Transaction Aware EE Concurrency EJB Context Handle > --------------------------------------------------- > > Key: WFLY-2698 > URL: https://issues.jboss.org/browse/WFLY-2698 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: EE, EJB > Reporter: Eduardo Martins > Assignee: Eduardo Martins > > When using EE Concurrency Utilities with an EJB that does not manages transactions, there is no way to transactions, for instance with a JPA entity manager. This happens because the context handle that saves and sets up EJB state does not creates and manages a transaction, and UserTransaction usage is forbidden due to EJB being of CMT kind. -- 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, 12 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2698) Transaction Aware EE Concurrency EJB Context Handle

by Eduardo Martins (JIRA)

[ https://issues.jboss.org/browse/WFLY-2698?page=com.atlassian.jira.plugin.... ] Eduardo Martins edited comment on WFLY-2698 at 1/31/14 3:32 PM: ---------------------------------------------------------------- the new PR allows tasks created by CMT EJB to access UserTransaction, as mandated by JSR 236 was (Author: emmartins): the allows tasks created by CMT EJB to access UserTransaction, as mandated by JSR 236 > Transaction Aware EE Concurrency EJB Context Handle > --------------------------------------------------- > > Key: WFLY-2698 > URL: https://issues.jboss.org/browse/WFLY-2698 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: EE, EJB > Reporter: Eduardo Martins > Assignee: Eduardo Martins > > When using EE Concurrency Utilities with an EJB that does not manages transactions, there is no way to transactions, for instance with a JPA entity manager. This happens because the context handle that saves and sets up EJB state does not creates and manages a transaction, and UserTransaction usage is forbidden due to EJB being of CMT kind. -- 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, 12 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2853) JSFFailoverTestCase fails since latest clustring / session changes in UT

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFLY-2853?page=com.atlassian.jira.plugin.... ] Tomaz Cerar updated WFLY-2853: ------------------------------ Description: Since upgrade to Undertow CR2 which contains https://github.com/undertow-io/undertow/pull/164 JSFFailoverTestCase is failing. example of failure: http://brontes.lab.eng.brq.redhat.com/viewLog.html?buildId=9076&buildType... {noformat} org.junit.ComparisonFailure: expected:<...COz6P7qxwwkkxE.node-[0]> but was:<...COz6P7qxwwkkxE.node-[1]> at org.junit.Assert.assertEquals(Assert.java:115) at org.junit.Assert.assertEquals(Assert.java:144) at org.jboss.as.test.clustering.cluster.jsf.JSFFailoverTestCase.testGracefulSimpleFailover(JSFFailoverTestCase.java:268) {noformat} was: Since upgrade to Undertow CR2 which contains https://github.com/undertow-io/undertow/pull/164 JSFFailoverTestCase is failing. I have ignored it for time being > JSFFailoverTestCase fails since latest clustring / session changes in UT > ------------------------------------------------------------------------ > > Key: WFLY-2853 > URL: https://issues.jboss.org/browse/WFLY-2853 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Clustering > Affects Versions: 8.0.0.CR1 > Reporter: Tomaz Cerar > Assignee: Paul Ferraro > Priority: Blocker > Fix For: 8.0.0.Final > > > Since upgrade to Undertow CR2 which contains https://github.com/undertow-io/undertow/pull/164 > JSFFailoverTestCase is failing. > example of failure: http://brontes.lab.eng.brq.redhat.com/viewLog.html?buildId=9076&buildType... > {noformat} > org.junit.ComparisonFailure: expected:<...COz6P7qxwwkkxE.node-[0]> but was:<...COz6P7qxwwkkxE.node-[1]> > at org.junit.Assert.assertEquals(Assert.java:115) > at org.junit.Assert.assertEquals(Assert.java:144) > at org.jboss.as.test.clustering.cluster.jsf.JSFFailoverTestCase.testGracefulSimpleFailover(JSFFailoverTestCase.java:268) > {noformat} -- 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, 12 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2853) JSFFailoverTestCase fails since latest clustring / session changes in UT

by Tomaz Cerar (JIRA)

Tomaz Cerar created WFLY-2853: --------------------------------- Summary: JSFFailoverTestCase fails since latest clustring / session changes in UT Key: WFLY-2853 URL: https://issues.jboss.org/browse/WFLY-2853 Project: WildFly Issue Type: Bug Security Level: Public (Everyone can see) Components: Clustering Affects Versions: 8.0.0.CR1 Reporter: Tomaz Cerar Assignee: Paul Ferraro Priority: Blocker Fix For: 8.0.0.Final Since upgrade to Undertow CR2 which contains https://github.com/undertow-io/undertow/pull/164 JSFFailoverTestCase is failing. I have ignored it for time being -- 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, 12 months

1
0
0 / 0

[JBoss JIRA] (WFLY-943) XML schema; use of elementFormDefault='unqualified'; cannot validate some documents

by Joshua Wilson (JIRA)

[ https://issues.jboss.org/browse/WFLY-943?page=com.atlassian.jira.plugin.s... ] Joshua Wilson commented on WFLY-943: ------------------------------------ Looks like this was fixed on Wildfly. https://github.com/wildfly/wildfly/pull/5560 > 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 > 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, 12 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2635) HTTP Management Interface Configuration

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFLY-2635?page=com.atlassian.jira.plugin.... ] Darran Lofthouse commented on WFLY-2635: ---------------------------------------- This is actually going to be a much bigger task than just that one config item, we have quite a lot of additional items to get into the configuration. > HTTP Management Interface Configuration > --------------------------------------- > > Key: WFLY-2635 > URL: https://issues.jboss.org/browse/WFLY-2635 > Project: WildFly > Issue Type: Task > Security Level: Public(Everyone can see) > Components: Domain Management > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 9.0.0.CR1 > > > Various configuration items are required for the HTTP Management interface, this is a parent task to combine them. -- 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, 12 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2635) HTTP Management Interface Configuration

by Andre Dietisheim (JIRA)

[ https://issues.jboss.org/browse/WFLY-2635?page=com.atlassian.jira.plugin.... ] Andre Dietisheim commented on WFLY-2635: ---------------------------------------- I'll have a go for this one and try to provide the changes to allow the ip- and useragent- based filters to be configured for the management server. I currently have the filters enabled but missing the configuration part. > HTTP Management Interface Configuration > --------------------------------------- > > Key: WFLY-2635 > URL: https://issues.jboss.org/browse/WFLY-2635 > Project: WildFly > Issue Type: Task > Security Level: Public(Everyone can see) > Components: Domain Management > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 9.0.0.CR1 > > > Various configuration items are required for the HTTP Management interface, this is a parent task to combine them. -- 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, 12 months

1
0
0 / 0

[JBoss JIRA] (WFLY-1376) HttpServletResponseImpl.getWriter() cannot be called: getOutputStream() already called

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFLY-1376?page=com.atlassian.jira.plugin.... ] Tomaz Cerar commented on WFLY-1376: ----------------------------------- can you try with latest nightly build https://community.jboss.org/thread/224262 > HttpServletResponseImpl.getWriter() cannot be called: getOutputStream() already called > -------------------------------------------------------------------------------------- > > Key: WFLY-1376 > URL: https://issues.jboss.org/browse/WFLY-1376 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Web (Undertow) > Affects Versions: 8.0.0.Alpha1 > Reporter: Juergen Zimmermann > Assignee: Stuart Douglas > Fix For: 8.0.0.Alpha2 > > > When I invoke a RESTful web service for a not existing URI (resulting in a 404 error) I'm getting the stacktrace below. This is working fine with EAP 6.1.Beta. > In web.xml I have this declaration for a 404 error and a JSF-based error page: > <error-page> > <error-code>404</error-code> > <location>/error/pageNotFound.jsf</location> > </error-page> > Stacktrace: > 12:36:03,921 SEVERE [javax.enterprise.resource.webcontainer.jsf.application] Error Rendering View[/error/pageNotFound.xhtml]: java.lang.IllegalStateException: UT010006: Cannot call getWriter(), getOutputStream() already called > at io.undertow.servlet.spec.HttpServletResponseImpl.getWriter(HttpServletResponseImpl.java:284) [undertow-servlet-1.0.0.Alpha15.jar:1.0.0.Alpha15] > at com.sun.faces.context.ExternalContextImpl.getResponseOutputWriter(ExternalContextImpl.java:834) [jsf-impl-2.2.0-m13-jbossorg-1.jar:] > at javax.faces.context.ExternalContextWrapper.getResponseOutputWriter(ExternalContextWrapper.java:785) [jboss-jsf-api_2.2_spec-2.2.0-m13.jar:2.2.0-m13] > at com.sun.faces.application.view.FaceletViewHandlingStrategy.createResponseWriter(FaceletViewHandlingStrategy.java:1166) [jsf-impl-2.2.0-m13-jbossorg-1.jar:] > at com.sun.faces.application.view.FaceletViewHandlingStrategy.renderView(FaceletViewHandlingStrategy.java:390) [jsf-impl-2.2.0-m13-jbossorg-1.jar:] > at com.sun.faces.application.view.MultiViewHandler.renderView(MultiViewHandler.java:131) [jsf-impl-2.2.0-m13-jbossorg-1.jar:] > at javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:337) [jboss-jsf-api_2.2_spec-2.2.0-m13.jar:2.2.0-m13] > at javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:337) [jboss-jsf-api_2.2_spec-2.2.0-m13.jar:2.2.0-m13] > at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:120) [jsf-impl-2.2.0-m13-jbossorg-1.jar:] > at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101) [jsf-impl-2.2.0-m13-jbossorg-1.jar:] > at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:219) [jsf-impl-2.2.0-m13-jbossorg-1.jar:] > at javax.faces.webapp.FacesServlet.service(FacesServlet.java:647) [jboss-jsf-api_2.2_spec-2.2.0-m13.jar:2.2.0-m13] > at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:87) [undertow-servlet-1.0.0.Alpha15.jar:1.0.0.Alpha15] > at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:82) [undertow-servlet-1.0.0.Alpha15.jar:1.0.0.Alpha15] > at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:54) [undertow-servlet-1.0.0.Alpha15.jar:1.0.0.Alpha15] > at io.undertow.server.HttpHandlers.executeHandler(HttpHandlers.java:46) [undertow-core-1.0.0.Alpha15.jar:1.0.0.Alpha15] > at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:116) [undertow-servlet-1.0.0.Alpha15.jar:1.0.0.Alpha15] > at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.0.0.Alpha15.jar:1.0.0.Alpha15] > at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:79) > at io.undertow.server.HttpHandlers.executeHandler(HttpHandlers.java:46) [undertow-core-1.0.0.Alpha15.jar:1.0.0.Alpha15] > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:26) [undertow-core-1.0.0.Alpha15.jar:1.0.0.Alpha15] > at io.undertow.server.HttpHandlers.executeHandler(HttpHandlers.java:46) [undertow-core-1.0.0.Alpha15.jar:1.0.0.Alpha15] > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:26) [undertow-core-1.0.0.Alpha15.jar:1.0.0.Alpha15] > at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:108) [undertow-servlet-1.0.0.Alpha15.jar:1.0.0.Alpha15] > at io.undertow.servlet.handlers.ServletInitialHandler.dispatchToPath(ServletInitialHandler.java:93) [undertow-servlet-1.0.0.Alpha15.jar:1.0.0.Alpha15] > at io.undertow.servlet.spec.RequestDispatcherImpl.error(RequestDispatcherImpl.java:367) [undertow-servlet-1.0.0.Alpha15.jar:1.0.0.Alpha15] > at io.undertow.servlet.spec.RequestDispatcherImpl.error(RequestDispatcherImpl.java:286) [undertow-servlet-1.0.0.Alpha15.jar:1.0.0.Alpha15] > at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:124) [undertow-servlet-1.0.0.Alpha15.jar:1.0.0.Alpha15] > at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:106) [undertow-servlet-1.0.0.Alpha15.jar:1.0.0.Alpha15] > at io.undertow.servlet.handlers.ServletInitialHandler.handleRequest(ServletInitialHandler.java:83) [undertow-servlet-1.0.0.Alpha15.jar:1.0.0.Alpha15] > at io.undertow.server.HttpHandlers.executeRootHandler(HttpHandlers.java:52) [undertow-core-1.0.0.Alpha15.jar:1.0.0.Alpha15] > at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:544) [undertow-core-1.0.0.Alpha15.jar:1.0.0.Alpha15] > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_21] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_21] > at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_21] -- 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, 12 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2852) JBoss 7 - EJB Remote Transaction Timeout

by Sfe Br (JIRA)

Sfe Br created WFLY-2852: ---------------------------- Summary: 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 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

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira January 2014