December 2015 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-1201) Could not upload new deployment

by Jason Greene (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1201?page=com.atlassian.jira.plugi... ] Jason Greene updated WFCORE-1201: --------------------------------- Fix Version/s: 2.0.6.Final (was: 2.0.5.Final) > Could not upload new deployment > ------------------------------- > > Key: WFCORE-1201 > URL: https://issues.jboss.org/browse/WFCORE-1201 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 1.0.2.Final > Environment: 2 different machines > Linux Debian Squeeze & Jessie > Oracle Java SE 8 > Reporter: Claudio Weiler > Assignee: Harald Pehl > Fix For: 2.0.6.Final > > > WildFly stop to accept deployments via interface upload with following stacktrace: > ERROR [io.undertow.request] (XNIO-1 task-2) Undertow request failed HttpServerExchange{ POST /management-upload}: java.io.IOException: UT000036: Connection terminated parsing multipart data > at io.undertow.server.handlers.form.MultiPartParserDefinition$MultiPartUploadHandler.parseBlocking(MultiPartParserDefinition.java:203) > at org.jboss.as.domain.http.server.DomainApiGenericOperationHandler.handleRequest(DomainApiGenericOperationHandler.java:104) > at io.undertow.server.handlers.encoding.EncodingHandler.handleRequest(EncodingHandler.java:72) > at org.jboss.as.domain.http.server.security.SubjectDoAsHandler$1.run(SubjectDoAsHandler.java:72) > at org.jboss.as.domain.http.server.security.SubjectDoAsHandler$1.run(SubjectDoAsHandler.java:68) > at java.security.AccessController.doPrivileged(Native Method) > at javax.security.auth.Subject.doAs(Subject.java:422) > at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:92) > at org.jboss.as.domain.http.server.security.SubjectDoAsHandler.handleRequest(SubjectDoAsHandler.java:68) > at org.jboss.as.domain.http.server.security.SubjectDoAsHandler.handleRequest(SubjectDoAsHandler.java:63) > at io.undertow.server.handlers.BlockingHandler.handleRequest(BlockingHandler.java:56) > at org.jboss.as.domain.http.server.DomainApiCheckHandler.handleRequest(DomainApiCheckHandler.java:87) > at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:52) > at io.undertow.server.Connectors.executeRootHandler(Connectors.java:199) > at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:774) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > Same artifact was used before with success, nothing changed. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5906) Intermittent failure in EJBClientDescriptorTestCase.testClientInvocationTimeout

by Stuart Douglas (JIRA)

Stuart Douglas created WFLY-5906: ------------------------------------ Summary: Intermittent failure in EJBClientDescriptorTestCase.testClientInvocationTimeout Key: WFLY-5906 URL: https://issues.jboss.org/browse/WFLY-5906 Project: WildFly Issue Type: Bug Reporter: Stuart Douglas Assignee: Stuart Douglas -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5905) Intermittent failure in EJBClientDescriptorTestCase.testClientInvocationTimeout

by Stuart Douglas (JIRA)

Stuart Douglas created WFLY-5905: ------------------------------------ Summary: Intermittent failure in EJBClientDescriptorTestCase.testClientInvocationTimeout Key: WFLY-5905 URL: https://issues.jboss.org/browse/WFLY-5905 Project: WildFly Issue Type: Bug Reporter: Stuart Douglas Assignee: Stuart Douglas -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5904) A deadlock can result if an EJB is being passivated at the same time an invocation made

by Stuart Douglas (JIRA)

Stuart Douglas created WFLY-5904: ------------------------------------ Summary: A deadlock can result if an EJB is being passivated at the same time an invocation made Key: WFLY-5904 URL: https://issues.jboss.org/browse/WFLY-5904 Project: WildFly Issue Type: Bug Components: Clustering, EJB Reporter: Stuart Douglas Assignee: Paul Ferraro As seen in EJBClientDescriptorTestCase.testClientInvocationTimeout This can be reproduced locally by adding a loop around the final invocations in the test: {code} for (int i = 0; i < 1000; ++i) {  Assert.assertEquals("bar", remote1.getManagedBeanMessage());  Assert.assertEquals("bar", remote2.getManagedBeanMessage());  } {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5904) A deadlock can result if an EJB is being passivated at the same time an invocation made

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/WFLY-5904?page=com.atlassian.jira.plugin.... ] Stuart Douglas updated WFLY-5904: --------------------------------- Attachment: passivationTestFailureDump.txt Attached stack dump when deadlock occurs > A deadlock can result if an EJB is being passivated at the same time an invocation made > --------------------------------------------------------------------------------------- > > Key: WFLY-5904 > URL: https://issues.jboss.org/browse/WFLY-5904 > Project: WildFly > Issue Type: Bug > Components: Clustering, EJB > Reporter: Stuart Douglas > Assignee: Paul Ferraro > Attachments: passivationTestFailureDump.txt > > > As seen in EJBClientDescriptorTestCase.testClientInvocationTimeout > This can be reproduced locally by adding a loop around the final invocations in the test: > {code} > for (int i = 0; i < 1000; ++i) {  > Assert.assertEquals("bar", remote1.getManagedBeanMessage());  > Assert.assertEquals("bar", remote2.getManagedBeanMessage());  > } > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (SECURITY-930) A security-domain can only load login-modules from a single JBoss module

by Stefan Guilhen (JIRA)

[ https://issues.jboss.org/browse/SECURITY-930?page=com.atlassian.jira.plug... ] Stefan Guilhen commented on SECURITY-930: ----------------------------------------- Derek, I recall working on a fix for this but I need to recheck if my PR was merged. Basically there was an issue with how the SecurityInfo used to store the jboss-module that simply would not allow references to multiple modules. Being more specific, the info class only had a single reference to a jboss-module and that causes trouble when you have more than one module as the second reference would override the first one. The fix consisted in storing all modules that were set in the config (by changing the reference in the info class to a collection) and then change the ClassLoader used by the JBossCachedAuthenticationManager to use all the references available. I'll try to find this commit and check if it has made it into WildFly. I'll post again once I figure this out. > A security-domain can only load login-modules from a single JBoss module > -------------------------------------------------------------------------- > > Key: SECURITY-930 > URL: https://issues.jboss.org/browse/SECURITY-930 > Project: PicketBox > Issue Type: Bug > Components: JBossSX, Security-SPI > Reporter: Derek Horton > Assignee: Stefan Guilhen > > A security-domain can only load login-modules from a single JBoss module. Even though the security-domain configuration will allow each login module defined within a single security-domain to have a "module" attribute, the only module that is used to load the login-modules is the last "module" attribute that the parsing system locates. > For example, with the following configuration, it looks like "org.jboss.example.CustomLoginModule" should be loaded from the "org.jboss.example" jboss-module and "org.jboss.example.CustomBaseCertLoginModule" should be loaded from the "org.jboss.another.example" jboss-module: > <security-domain name="jmx-console" cache-type="default"> > <authentication> > <login-module code="org.jboss.example.CustomLoginModule" module="org.jboss.example" flag="required"> > <module-option name="usersProperties" value="${jboss.server.config.dir}/users.properties"/> > <module-option name="rolesProperties" value="${jboss.server.config.dir}/roles.properties"/> > </login-module> > <login-module code="org.jboss.example.CustomBaseCertLoginModule" module="org.jboss.another.example" flag="required"> > <module-option name="usersProperties" value="${jboss.server.config.dir}/users.properties"/> > <module-option name="rolesProperties" value="${jboss.server.config.dir}/roles.properties"/> > </login-module> > </authentication> > </security-domain> > Unfortunately, it does not work like this. Only the "org.jboss.another.example" jboss-module is used to load the custom login modules. > There seems to be two issues. 1) The security subsystem code only "remembers" the last module that is defined within a single security domain. 2) I think issue #1 is happening because the JBoss authentication code (org.jboss.security.authentication.JBossCachedAuthenticationManager.authenticate()) defers to the JVM's login module handling code. The JVM appears to treat the login modules as one atomic until and so a single classloader is set and then the JVM login module code is invoked to handle the authentication requests. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5903) AsyncMethodTestCase fails intermittently

by Stuart Douglas (JIRA)

Stuart Douglas created WFLY-5903: ------------------------------------ Summary: AsyncMethodTestCase fails intermittently Key: WFLY-5903 URL: https://issues.jboss.org/browse/WFLY-5903 Project: WildFly Issue Type: Bug Reporter: Stuart Douglas Assignee: Stuart Douglas -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5902) AsyncMethodTestCase fails intermittently

by Stuart Douglas (JIRA)

Stuart Douglas created WFLY-5902: ------------------------------------ Summary: AsyncMethodTestCase fails intermittently Key: WFLY-5902 URL: https://issues.jboss.org/browse/WFLY-5902 Project: WildFly Issue Type: Bug Reporter: Stuart Douglas Assignee: Stuart Douglas -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1256) To make JBOSS AS 7 node communication secure

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1256?page=com.atlassian.jira.plugi... ] Brian Stansberry moved WFLY-1147 to WFCORE-1256: ------------------------------------------------ Project: WildFly Core (was: WildFly) Key: WFCORE-1256 (was: WFLY-1147) Issue Type: Task (was: Feature Request) Component/s: Domain Management (was: Documentation) (was: Domain Management) > To make JBOSS AS 7 node communication secure > --------------------------------------------- > > Key: WFCORE-1256 > URL: https://issues.jboss.org/browse/WFCORE-1256 > Project: WildFly Core > Issue Type: Task > Components: Domain Management > Environment: JBOSS AS 7.1.0 final , Windows 7 > Reporter: hitesh yadav > Assignee: Brian Stansberry > Labels: jboss > > I am using JBOSS AS 7.1.0 final in domain mode . > There are 4 node in domain. > My requirement is to make node communication secure ............like HTTPS. > As per my understanding JBOSS AS 7 uses JGroups for communication between domain node and JGroups use TCP or UDP protocol for communicate. > For example ......when we are using HTTPS protocol, all communication between Browser and Server are done in Encrypted formate........... > I need same thing in JBOSS AS 7 node communication ........means all communication between domain nodes must be done in some Encryption/Decryption form or any other way to make communication secure ...... -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1147) Eliminate ProcessController

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1147?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-1147: ------------------------------------- Component/s: Domain Management (was: Server) > Eliminate ProcessController > --------------------------- > > Key: WFCORE-1147 > URL: https://issues.jboss.org/browse/WFCORE-1147 > Project: WildFly Core > Issue Type: Task > Components: Domain Management > Reporter: David Lloyd > > We should eliminate ProcessController and directly have the HC control the servers. This should greatly simplify the code and add more power and flexibility to the management and lifecycle of server JVMs. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 6 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 December 2015