November 2014 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-286) The SecurityRealmService should only perform a generic mapping to RealmUser if really required.

by Darran Lofthouse (JIRA)

Darran Lofthouse created WFCORE-286: --------------------------------------- Summary: The SecurityRealmService should only perform a generic mapping to RealmUser if really required. Key: WFCORE-286 URL: https://issues.jboss.org/browse/WFCORE-286 Project: WildFly Core Issue Type: Bug Components: Domain Management Affects Versions: 1.0.0.Alpha13 Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 1.0.0.Alpha14 If there is a more accurate way to calculate the RealmUser then use it. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4013) The value of the bound attribute in socket-binding-group messaging is always false

by Kyle Lape (JIRA)

[ https://issues.jboss.org/browse/WFLY-4013?page=com.atlassian.jira.plugin.... ] Kyle Lape updated WFLY-4013: ---------------------------- Forum Reference: (was: https://c.na7.visual.force.com/apex/Case_View?sbstr=01264236) > The value of the bound attribute in socket-binding-group messaging is always false > ---------------------------------------------------------------------------------- > > Key: WFLY-4013 > URL: https://issues.jboss.org/browse/WFLY-4013 > Project: WildFly > Issue Type: Bug > Components: JMS > Affects Versions: JBoss AS7 7.2.0.Final > Environment: JBoss EAP 6.3.1. > Reporter: Tom Ross > Assignee: Jeff Mesnil > > The value of bound attribute in messaging socket group is always false. > {noformat} > /socket-binding-group=standard-sockets/socket-binding=messaging:read-resource(include-runtime=true, recursive=true) > { > "outcome" => "success", > "result" => { > "bound" => false, > "bound-address" => undefined, > "bound-port" => undefined, > "client-mappings" => undefined, > "fixed-port" => false, > "interface" => undefined, > "multicast-address" => undefined, > "multicast-port" => undefined, > "name" => "messaging", > "port" => 5445 > } > {noformat} -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4054) Unexpected attribute can be added to elements in Transactions Subsystem

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-4054?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-4054: ----------------------------------------------- Kabir Khan <kkhan(a)redhat.com> changed the Status of [bug 1156032|https://bugzilla.redhat.com/show_bug.cgi?id=1156032] from ASSIGNED to MODIFIED > Unexpected attribute can be added to elements in Transactions Subsystem > ----------------------------------------------------------------------- > > Key: WFLY-4054 > URL: https://issues.jboss.org/browse/WFLY-4054 > Project: WildFly > Issue Type: Bug > Components: Transactions > Reporter: Amos Feng > Assignee: Amos Feng > > If you add unexpected argument to element in standalone.xml then it's expected to get error of "Unexpected attribute '...' encountered" [1] when server is started. > When you add a random argument to some of the elements in transactions then no error is thrown. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-242) the deployment content is deleted if first undeploy and then deploy the same application using CLI batch

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFCORE-242?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on WFCORE-242: ------------------------------------------------ Kabir Khan <kkhan(a)redhat.com> changed the Status of [bug 1162444|https://bugzilla.redhat.com/show_bug.cgi?id=1162444] from POST to MODIFIED > the deployment content is deleted if first undeploy and then deploy the same application using CLI batch > -------------------------------------------------------------------------------------------------------- > > Key: WFCORE-242 > URL: https://issues.jboss.org/browse/WFCORE-242 > Project: WildFly Core > Issue Type: Bug > Components: CLI, Domain Management > Reporter: Jay Kumar SenSharma > Assignee: Emmanuel Hugonnet > Priority: Minor > > - If deploy and undeploy CLI commands executed in a batch mode then it causes missing deployment inside the "data/content" directory which leads to the following error: > {code} > [Host Controller] 10:33:42,387 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([("deployment" => "example.war")]) - failure description: "WFLYDC0058: No deployment content with hash d85f1e3106bc8a49838a0dccae9e80819c25e02c is available in the deployment content repository for deployment 'example.war'. This is a fatal boot error. To correct the problem, either restart with the --admin-only switch set and use the CLI to install the missing content or remove it from the configuration, or remove the deployment from the xml configuraiton file and restart." > [Host Controller] 10:33:42,390 FATAL [org.jboss.as.host.controller] (Controller Boot Thread) WFLYHC0034: Host Controller boot has failed in an unrecoverable manner; exiting. See previous messages for details. > {code} -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4129) The RemotingLoginModule should first check if there is already a RealmUser

by Darran Lofthouse (JIRA)

Darran Lofthouse created WFLY-4129: -------------------------------------- Summary: The RemotingLoginModule should first check if there is already a RealmUser Key: WFLY-4129 URL: https://issues.jboss.org/browse/WFLY-4129 Project: WildFly Issue Type: Bug Components: Security Affects Versions: 9.0.0.Alpha1 Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 9.0.0.Beta1 The reason is because the realm may have actually already substituted in a different name for the user. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-283) SASL_SERVER and SASL_PROTOCOL options not being passed all the way to Remoting

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFCORE-283?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on WFCORE-283: ------------------------------------------------ Darran Lofthouse <darran.lofthouse(a)redhat.com> changed the Status of [bug 1168313|https://bugzilla.redhat.com/show_bug.cgi?id=1168313] from ASSIGNED to POST > SASL_SERVER and SASL_PROTOCOL options not being passed all the way to Remoting > ------------------------------------------------------------------------------ > > Key: WFCORE-283 > URL: https://issues.jboss.org/browse/WFCORE-283 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management, Remoting, Security > Affects Versions: 1.0.0.Alpha13 > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 1.0.0.Alpha14 > > -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1899) Discovery returns after 16 responses even if there are no coord responses

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JGRP-1899?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated JGRP-1899: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1168329 > Discovery returns after 16 responses even if there are no coord responses > ------------------------------------------------------------------------- > > Key: JGRP-1899 > URL: https://issues.jboss.org/browse/JGRP-1899 > Project: JGroups > Issue Type: Bug > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 3.5.2, 3.6.1 > > > Discovery sets {{Responses.num_expected_rsps}} to 16 if no member list is defined. This makes discovery return after 16 responses even if no response from a coordinator has been received. > This is a problem if we have a cluster of size > 16 and the coordinator doesn't respond imediately, e.g. because it is busy processing other requests. > h5. Solution > * Set {{num_expected_rsps}} to 0 (= wait until at least 1 coord rsp has been received -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4128) Move JAX-RS 2.0 API into JBoss Specs

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFLY-4128?page=com.atlassian.jira.plugin.... ] Tomaz Cerar updated WFLY-4128: ------------------------------ Affects Version/s: 8.2.0.Final (was: 9.0.0.Beta1) > Move JAX-RS 2.0 API into JBoss Specs > ------------------------------------ > > Key: WFLY-4128 > URL: https://issues.jboss.org/browse/WFLY-4128 > Project: WildFly > Issue Type: Task > Components: REST > Affects Versions: 8.2.0.Final > Reporter: Fernando Nasser > Assignee: Tomaz Cerar > Priority: Minor > > Currently the JAX-RS 2.0 API comes from the RESTEasy project but we should have a JBoss Spec JAX-RS 2.0 API and use that one instead. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4128) Move JAX-RS 2.0 API into JBoss Specs

by Fernando Nasser (JIRA)

Fernando Nasser created WFLY-4128: ------------------------------------- Summary: Move JAX-RS 2.0 API into JBoss Specs Key: WFLY-4128 URL: https://issues.jboss.org/browse/WFLY-4128 Project: WildFly Issue Type: Task Components: REST Affects Versions: 9.0.0.Beta1 Reporter: Fernando Nasser Assignee: Tomaz Cerar Priority: Minor Currently the JAX-RS 2.0 API comes from the RESTEasy project but we should have a JBoss Spec JAX-RS 2.0 API and use that one instead. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4126) java.lang.ExceptionInInitializerError when invoking BIRT service

by Chezy Palani (JIRA)

[ https://issues.jboss.org/browse/WFLY-4126?page=com.atlassian.jira.plugin.... ] Chezy Palani commented on WFLY-4126: ------------------------------------ This is the other part of stack from the log file: Caused by: java.lang.ExceptionInInitializerError at org.apache.jasper.el.ELContextImpl.<init>(ELContextImpl.java:72) [jastow-1.0.0.Final.jar:1.0.0.Final] at org.apache.jasper.compiler.Validator$ValidateVisitor.checkXmlAttributes(Validator.java:1188) [jastow-1.0.0.Final.jar:1.0.0.Final] at org.apache.jasper.compiler.Validator$ValidateVisitor.visit(Validator.java:844) [jastow-1.0.0.Final.jar:1.0.0.Final] at org.apache.jasper.compiler.Node$CustomTag.accept(Node.java:1530) [jastow-1.0.0.Final.jar:1.0.0.Final] at org.apache.jasper.compiler.Node$Nodes.visit(Node.java:2377) [jastow-1.0.0.Final.jar:1.0.0.Final] at org.apache.jasper.compiler.Node$Visitor.visitBody(Node.java:2427) [jastow-1.0.0.Final.jar:1.0.0.Final] at org.apache.jasper.compiler.Node$Visitor.visit(Node.java:2433) [jastow-1.0.0.Final.jar:1.0.0.Final] at org.apache.jasper.compiler.Node$Root.accept(Node.java:495) [jastow-1.0.0.Final.jar:1.0.0.Final] at org.apache.jasper.compiler.Node$Nodes.visit(Node.java:2377) [jastow-1.0.0.Final.jar:1.0.0.Final] at org.apache.jasper.compiler.Validator.validateExDirectives(Validator.java:1768) [jastow-1.0.0.Final.jar:1.0.0.Final] at org.apache.jasper.compiler.Compiler.generateJava(Compiler.java:211) [jastow-1.0.0.Final.jar:1.0.0.Final] at org.apache.jasper.compiler.Compiler.compile(Compiler.java:359) [jastow-1.0.0.Final.jar:1.0.0.Final] at org.apache.jasper.compiler.Compiler.compile(Compiler.java:339) [jastow-1.0.0.Final.jar:1.0.0.Final] at org.apache.jasper.compiler.Compiler.compile(Compiler.java:326) [jastow-1.0.0.Final.jar:1.0.0.Final] at org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:604) [jastow-1.0.0.Final.jar:1.0.0.Final] at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:309) [jastow-1.0.0.Final.jar:1.0.0.Final] at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:326) [jastow-1.0.0.Final.jar:1.0.0.Final] at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:259) [jastow-1.0.0.Final.jar:1.0.0.Final] ... 42 more Caused by: java.lang.NullPointerException at javax.el.CompositeELResolver.add(CompositeELResolver.java:117) [jboss-el-api_3.0_spec-1.0.3.Final.jar:1.0.3.Final] at org.apache.jasper.el.ELResolverImpl.<clinit>(ELResolverImpl.java:51) [jastow-1.0.0.Final.jar:1.0.0.Final] ... 60 more > java.lang.ExceptionInInitializerError when invoking BIRT service > ---------------------------------------------------------------- > > Key: WFLY-4126 > URL: https://issues.jboss.org/browse/WFLY-4126 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 8.2.0.Final > Environment: Windows 7 and JDK 1.8 > Reporter: Chezy Palani > Assignee: Stuart Douglas > > There was no error during the deployment of the Application. Even hitting landing page works fine. When our service is invoked, we get this exception. > Context Path: > /actuatejavacomponent > Servlet Path: > /iv > Path Info: > null > Query String: > __report=%2fPublic%2fBIRT%20and%20BIRT%20Studio%20Examples%2fCustomer%20Dashboard%2erptdocument&closex=true&__vp=workgroup&showBanner=true&showBreadCrumb=false&locale=en_US > Stack Trace > javax.servlet.ServletException: java.lang.ExceptionInInitializerError > org.apache.jasper.servlet.JspServlet.service(JspServlet.java:267) > javax.servlet.http.HttpServlet.service(HttpServlet.java:790) > io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) > io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61) > io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:249) > io.undertow.servlet.handlers.ServletInitialHandler.dispatchToServlet(ServletInitialHandler.java:198) > io.undertow.servlet.spec.RequestDispatcherImpl.include(RequestDispatcherImpl.java:279) > com.actuate.iv.presentation.aggregation.IVBaseFragment.service(IVBaseFragment.java:261) > com.actuate.iv.servlet.IVHttpDispatcher.handleRequest(IVHttpDispatcher.java:144) > com.actuate.iv.servlet.IVServlet.doGet(IVServlet.java:261) > javax.servlet.http.HttpServlet.service(HttpServlet.java:687) > org.apache.axis.transport.http.AxisServletBase.service(AxisServletBase.java:327) > javax.servlet.http.HttpServlet.service(HttpServlet.java:790) > io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) > io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61) > io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) > org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78) > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) > io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:56) > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) > io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:63) > io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) > io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70) > io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76) > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:261) > io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:247) > io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:76) > io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:166) > io.undertow.server.Connectors.executeRootHandler(Connectors.java:197) > io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:759) > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > java.lang.Thread.run(Thread.java:745) -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 7 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 November 2014