July 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-3107) Allow slave hosts to ignore missing RBAC config resources

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3107?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-3107: ------------------------------------- Description: Part of parent issue whereby slaves can ignore missing RBAC constraint resources for write requests coming from the DC. If the DC sent the request, then the address is ok overall. So if it's missing on the slave that means the slave doesn't have that constraint registered and doesn't need to handle the op. This fix could possibly be backported to the 2.1.x and to EAP 6.4.x in lieu of adding transformers as part of the parent issue. In the case of 2.1.x it also allows slaves to ignore the related extension even if the code for it is present (which is only a minor benefit.) was: Part of parent issue whereby slaves can ignore missing RBAC constraint resources for write requests coming from the DC. If the DC sent the request, then the address is ok overall. So if it's missing on the slave that means the slave doesn't have that constraint registered and doesn't need to handle the op. This fix could possibly be backported to the 2.1.x and to EAP 6.4.x in lieu of adding transformers as part of the parent issue. > Allow slave hosts to ignore missing RBAC config resources > --------------------------------------------------------- > > Key: WFCORE-3107 > URL: https://issues.jboss.org/browse/WFCORE-3107 > Project: WildFly Core > Issue Type: Sub-task > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Brian Stansberry > > Part of parent issue whereby slaves can ignore missing RBAC constraint resources for write requests coming from the DC. > If the DC sent the request, then the address is ok overall. So if it's missing on the slave that means the slave doesn't have that constraint registered and doesn't need to handle the op. > This fix could possibly be backported to the 2.1.x and to EAP 6.4.x in lieu of adding transformers as part of the parent issue. In the case of 2.1.x it also allows slaves to ignore the related extension even if the code for it is present (which is only a minor benefit.) -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3110) NullPointerException in ModelControllerMBeanServerPlugin::accepts

by Brian Stansberry (JIRA)

Brian Stansberry created WFCORE-3110: ---------------------------------------- Summary: NullPointerException in ModelControllerMBeanServerPlugin::accepts Key: WFCORE-3110 URL: https://issues.jboss.org/browse/WFCORE-3110 Project: WildFly Core Issue Type: Bug Components: JMX Reporter: Brian Stansberry ModelControllerMBeanServerPlugin.accepts throws a NPE if getLegacyDomain returns null. {code} java.lang.NullPointerException at java.util.regex.Matcher.getTextLength(Unknown Source) at java.util.regex.Matcher.reset(Unknown Source) at java.util.regex.Matcher.(Unknown Source) at java.util.regex.Pattern.matcher(Unknown Source) at org.jboss.as.jmx.model.ModelControllerMBeanServerPlugin.accepts(ModelControllerMBeanServerPlugin.java:111) at org.jboss.as.jmx.PluggableMBeanServerImpl.queryMBeans(PluggableMBeanServerImpl.java:821) {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (SECURITY-864) NameNotFoundException due to policyRegistration -- service jboss.naming.context.java.policyRegistration

by Eric B (JIRA)

[ https://issues.jboss.org/browse/SECURITY-864?page=com.atlassian.jira.plug... ] Eric B commented on SECURITY-864: --------------------------------- [~pmm] I noticed the `JBossPolicyRegistrationObjectFactory`, but not entirely sure how it should be used. I created an issue in GitHub relating to my question. > NameNotFoundException due to policyRegistration -- service jboss.naming.context.java.policyRegistration > ------------------------------------------------------------------------------------------------------- > > Key: SECURITY-864 > URL: https://issues.jboss.org/browse/SECURITY-864 > Project: PicketBox > Issue Type: Bug > Components: PicketBox > Reporter: Chao Wang > Assignee: Stefan Guilhen > > "NameNotFoundException due to policyRegistration -- service jboss.naming.context.java.policyRegistration" is recorded in server.log during quickstart example run by changing log level: > {noformat} > <logger category="org.jboss.as.security"> > <level name="TRACE"/> > </logger> > <logger category="org.jboss.security"> > <level name="TRACE"/> > </logger> > {noformat} > See detailed description in community discussion [#907134|https://developer.jboss.org/message/907134] > I choose Jira component picketbox since the exception is titled as "PBOX000293: Exception caught: javax.naming.NameNotFoundException" -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9140) Elytron API doesn't work in JSPs

by Josef Cacek (JIRA)

Josef Cacek created WFLY-9140: --------------------------------- Summary: Elytron API doesn't work in JSPs Key: WFLY-9140 URL: https://issues.jboss.org/browse/WFLY-9140 Project: WildFly Issue Type: Bug Components: Web (Undertow), Security Reporter: Josef Cacek Assignee: Stuart Douglas Priority: Blocker Elytron dependencies seems to be missing on Jasper classpath, so usage of Elytron API in JSPs can lead to ClassNotFound issues. I have following JSP: {code:jsp} <%@ page language="java" contentType="text/html; charset=UTF-8" pageEncoding="UTF-8" session="false"%> <% final java.util.concurrent.Callable<String> callable = () -> { return "test"; }; System.out.println(org.wildfly.security.auth.client.AuthenticationContext.captureCurrent().runCallable(callable)); %> {code} But its deployment fails due to CNF during compilation. The Jasper is missing Contextual class from wildfly-common. {noformat} 13:44:56,380 ERROR [io.undertow.request] (default task-7) UT005023: Exception handling request to /authenticator/: org.apache.jasper.JasperException: JBWEB004062: Unable to compile class for JSP: JBWEB004060: An error occurred at line: 8 in the jsp file: /index.jsp The type org.wildfly.common.context.Contextual cannot be resolved. It is indirectly referenced from required .class files 5: return "test"; 6: }; 7: 8: System.out.println(org.wildfly.security.auth.client.AuthenticationContext.captureCurrent().runCallable(callable)); 9: %> 10: JBWEB004060: An error occurred at line: 8 in the jsp file: /index.jsp The method runCallable(Callable<String>) is undefined for the type AuthenticationContext 5: return "test"; 6: }; 7: 8: System.out.println(org.wildfly.security.auth.client.AuthenticationContext.captureCurrent().runCallable(callable)); 9: %> 10: Stacktrace: at org.apache.jasper.compiler.DefaultErrorHandler.javacError(DefaultErrorHandler.java:95) at org.apache.jasper.compiler.ErrorDispatcher.javacError(ErrorDispatcher.java:198) at org.apache.jasper.compiler.JDTCompiler.generateClass(JDTCompiler.java:449) at org.apache.jasper.compiler.Compiler.compile(Compiler.java:359) at org.apache.jasper.compiler.Compiler.compile(Compiler.java:334) at org.apache.jasper.compiler.Compiler.compile(Compiler.java:321) at org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:652) at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:358) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:403) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:347) at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62) at io.undertow.jsp.JspFileHandler.handleRequest(JspFileHandler.java:32) at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) at org.wildfly.elytron.web.undertow.server.ElytronRunAsHandler.lambda$handleRequest$1(ElytronRunAsHandler.java:68) at org.wildfly.security.auth.server.FlexibleIdentityAssociation.runAsFunctionEx(FlexibleIdentityAssociation.java:101) at org.wildfly.security.auth.server.Scoped.runAsFunctionEx(Scoped.java:150) at org.wildfly.security.auth.server.Scoped.runAs(Scoped.java:62) at org.wildfly.elytron.web.undertow.server.ElytronRunAsHandler.handleRequest(ElytronRunAsHandler.java:67) at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46) at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64) at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) at org.wildfly.extension.undertow.deployment.GlobalRequestControllerHandler.handleRequest(GlobalRequestControllerHandler.java:68) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292) at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81) at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138) at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135) at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48) at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43) at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508) at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508) at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508) at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508) at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272) at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81) at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104) at io.undertow.server.Connectors.executeRootHandler(Connectors.java:326) at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:812) 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:748) {noformat} This is a similar problem (in modules dependencies) as we already have reported for Maven dependencies in JBEAP-10893. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9139) Upgrade Artemis 1.5.5.jbossorg-005

by Jeff Mesnil (JIRA)

[ https://issues.jboss.org/browse/WFLY-9139?page=com.atlassian.jira.plugin.... ] Jeff Mesnil moved JBEAP-12367 to WFLY-9139: ------------------------------------------- Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-9139 (was: JBEAP-12367) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: JMS (was: ActiveMQ) (was: JMS) > Upgrade Artemis 1.5.5.jbossorg-005 > ---------------------------------- > > Key: WFLY-9139 > URL: https://issues.jboss.org/browse/WFLY-9139 > Project: WildFly > Issue Type: Component Upgrade > Components: JMS > Reporter: Jeff Mesnil > Assignee: Jeff Mesnil > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2199) JDBC_PING cluster doesn't handle shutdown members

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2199?page=com.atlassian.jira.plugin.... ] Bela Ban resolved JGRP-2199. ---------------------------- Resolution: Done Fixed according to your suggestion. Thanks, Douglas > JDBC_PING cluster doesn't handle shutdown members > ------------------------------------------------- > > Key: JGRP-2199 > URL: https://issues.jboss.org/browse/JGRP-2199 > Project: JGroups > Issue Type: Bug > Affects Versions: 4.0 > Reporter: Douglas Adams > Assignee: Bela Ban > Fix For: 4.0.5 > > Attachments: file-ping.xml, jdbc-ping.xml, stuck_starting_up.log > > > FILE_PING and JDBC_PING have different behavior when a cluster's coordinator stops. > With FILE_PING the coordinator will delete the whole cluster's file on shutdown of the coordinator. > JDBC_PING does not do this and reveals a problematic flaw in how node's are handled on shutdown. > When I added my own logging to the source of these files I observed that they're both continuously writing to the database/file all of the members because {{write()}} is called very frequently. > --- > Current behavior: > GIVEN a cluster of JDBC_PING registered nodes > WHEN a node shuts down > THEN it removes itself from the database table AND the coordinator almost immediately re-adds the shut down member to the table because of the {{List<PingData>}} sent to write() > GIVEN a cluster of JDBC_PING registered nodes has only the coordinator left > WHEN the coordinator shuts down > THEN the coordinator removes itself from the database and because there's no coordinator left the database shows a list of only the 'members' with no coordinator > GIVEN a cluster of JDBC_PING registered nodes > WHEN the coordinator shuts down or crashes and does not have time to remove itself from the database > THEN the next node to start will never finish negotiating membership with the cluster because a phantom coordinator still exists (see attachement: stuck_starting_up.log) > --- > I expected the behavior between JDBC_PING and FILE_PING to remain consistent -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3109) WFCORE-3078 fix causes that only one AuditLogItem is written

by Rostislav Svoboda (JIRA)

Rostislav Svoboda created WFCORE-3109: ----------------------------------------- Summary: WFCORE-3078 fix causes that only one AuditLogItem is written Key: WFCORE-3109 URL: https://issues.jboss.org/browse/WFCORE-3109 Project: WildFly Core Issue Type: Bug Components: Domain Management Reporter: Rostislav Svoboda Assignee: ehsavoie Hugonnet WFCORE-3078 fix causes that only one AuditLogItem is written https://github.com/wildfly/wildfly-core/pull/2627#discussion_r129549452 queuedItems.clear() is inside for (AuditLogItem record : queuedItems) so only one AuditLogItem is written ? -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (HAWKULARQE-150) Redeploy archive on EAP - Should fail

by Michael Foley (JIRA)

[ https://issues.jboss.org/browse/HAWKULARQE-150?page=com.atlassian.jira.pl... ] Michael Foley commented on HAWKULARQE-150: ------------------------------------------ Thanks Hayk for following thru on this! Please log a bugzilla on this .... medium priority. And mention that it was from a Red Hat Solutions Architect ... > Redeploy archive on EAP - Should fail > ------------------------------------- > > Key: HAWKULARQE-150 > URL: https://issues.jboss.org/browse/HAWKULARQE-150 > Project: Hawkular QE > Issue Type: Task > Reporter: Hayk Hovsepyan > Assignee: Hayk Hovsepyan > Priority: Critical > > <mfoley> both apps are deployed in the same eap? > <bhirsch> yep > <mfoley> so you deployed 1 ... shows in the display > <bhirsch> And actions work. I can use cf to start, stop, and deploy > <mfoley> deploy a 2nd ... not showing the display > <bhirsch> correct > <mfoley> odd > <bhirsch> agreed > <mfoley> i suppose a 3rd would not display either > <bhirsch> haven't tried yet. I'm not really an MW guy, so all I had was ticket-monster and helloworld :-) Need a third .war > <mfoley> it's okay > <mfoley> seems like a bug to me ... > <mfoley> i appreciate the feedback > <bhirsch> np > <mfoley> you are a solutions architect? > <bhirsch> correct, SA in the Northeast > <mfoley> cool ... > <mfoley> general question ... what is your impression of the MW Provider? > <bhirsch> I have a customer that wanted a CF demo, with a focus on the MW provider area (they are a JBoss customer) So, here we are. > <mfoley> you can be direct .... it's okay > <bhirsch> So far so good > <mfoley> :) > <mfoley> excellent > <bhirsch> No complaints really. The deployment is a little involved, but very well documented > <mfoley> well ... only demo 1 deployment :) > <bhirsch> haha... yeah. I'm not very worried about that part. Just figured it was something you all would want to know > <mfoley> oh we do > <bhirsch> they'll probably be thrilled to see MW in CF at all > <mfoley> i hope so ... it would be validation of the new direction and strategy > <bhirsch> They use a lot of EAP, so this plus OpenShift (also an OSE customer) could help us beat VMware VRA out the door > <mfoley> :) -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1681) Publish XSDs automatically for new Drools versions

by Petr Široký (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1681?page=com.atlassian.jira.plugi... ] Petr Široký reassigned DROOLS-1681: ----------------------------------- Assignee: Michael Biarnes Kiefer (was: Petr Široký) > Publish XSDs automatically for new Drools versions > -------------------------------------------------- > > Key: DROOLS-1681 > URL: https://issues.jboss.org/browse/DROOLS-1681 > Project: Drools > Issue Type: Feature Request > Components: build > Affects Versions: 6.4.0.Final, 6.5.0.Final, 7.0.0.Final, 7.1.0.Final > Reporter: Russell Morrisey > Assignee: Michael Biarnes Kiefer > > When a new Drools final version is released, the XSD should be published and uploaded automatically to the site. > Drools website is missing XSDs for 6.4, 6.5 and 7.x. The URL given in the kmodule.xml example files returns a 404 error. > Automation of the XSDs was previously discussed here: > https://github.com/kiegroup/droolsjbpm-build-bootstrap/pull/122/files -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1681) Publish XSDs automatically for new Drools versions

by Michael Biarnes Kiefer (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1681?page=com.atlassian.jira.plugi... ] Michael Biarnes Kiefer commented on DROOLS-1681: ------------------------------------------------ created a PR > Publish XSDs automatically for new Drools versions > -------------------------------------------------- > > Key: DROOLS-1681 > URL: https://issues.jboss.org/browse/DROOLS-1681 > Project: Drools > Issue Type: Feature Request > Components: build > Affects Versions: 6.4.0.Final, 6.5.0.Final, 7.0.0.Final, 7.1.0.Final > Reporter: Russell Morrisey > Assignee: Petr Široký > > When a new Drools final version is released, the XSD should be published and uploaded automatically to the site. > Drools website is missing XSDs for 6.4, 6.5 and 7.x. The URL given in the kmodule.xml example files returns a 404 error. > Automation of the XSDs was previously discussed here: > https://github.com/kiegroup/droolsjbpm-build-bootstrap/pull/122/files -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 9 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 July 2017