January 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-2202) Add support for multiple dynamic parts in capability names

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2202?page=com.atlassian.jira.plugi... ] Tomaz Cerar updated WFCORE-2202: -------------------------------- Priority: Critical (was: Major) > Add support for multiple dynamic parts in capability names > ---------------------------------------------------------- > > Key: WFCORE-2202 > URL: https://issues.jboss.org/browse/WFCORE-2202 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management > Affects Versions: 3.0.0.Alpha16 > Reporter: Tomaz Cerar > Assignee: Brian Stansberry > Priority: Critical > > Currently dynamic capabilites only allow one, last, part of name to be dynamic. > There are cases where we need support for multiple dynamic parts such are cases in infinispan subsystem and in undertow. > For example when you have "virtual host" in undertow it is defined under path > /subsystem=undertow/server=*default-server*/host=*default-host* > And here are two capabilities in this path. > first is > {{/subsystem=undertow/server=default}} which server capability with name "default" > but host capability is defined by its name as well as name of server capability that is its parent. > We need support in management layer to expose this kind of capability names. > Prototype impl is available my branch https://github.com/ctomc/wildfly-core/tree/capabilites-api -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2202) Add support for multiple dynamic parts in capability names

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2202?page=com.atlassian.jira.plugi... ] Tomaz Cerar reassigned WFCORE-2202: ----------------------------------- Assignee: Tomaz Cerar (was: Brian Stansberry) > Add support for multiple dynamic parts in capability names > ---------------------------------------------------------- > > Key: WFCORE-2202 > URL: https://issues.jboss.org/browse/WFCORE-2202 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management > Affects Versions: 3.0.0.Alpha16 > Reporter: Tomaz Cerar > Assignee: Tomaz Cerar > Priority: Critical > > Currently dynamic capabilites only allow one, last, part of name to be dynamic. > There are cases where we need support for multiple dynamic parts such are cases in infinispan subsystem and in undertow. > For example when you have "virtual host" in undertow it is defined under path > /subsystem=undertow/server=*default-server*/host=*default-host* > And here are two capabilities in this path. > first is > {{/subsystem=undertow/server=default}} which server capability with name "default" > but host capability is defined by its name as well as name of server capability that is its parent. > We need support in management layer to expose this kind of capability names. > Prototype impl is available my branch https://github.com/ctomc/wildfly-core/tree/capabilites-api -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2202) Add support for multiple dynamic parts in capability names

by Tomaz Cerar (JIRA)

Tomaz Cerar created WFCORE-2202: ----------------------------------- Summary: Add support for multiple dynamic parts in capability names Key: WFCORE-2202 URL: https://issues.jboss.org/browse/WFCORE-2202 Project: WildFly Core Issue Type: Enhancement Components: Domain Management Affects Versions: 3.0.0.Alpha16 Reporter: Tomaz Cerar Assignee: Brian Stansberry Currently dynamic capabilites only allow one, last, part of name to be dynamic. There are cases where we need support for multiple dynamic parts such are cases in infinispan subsystem and in undertow. For example when you have "virtual host" in undertow it is defined under path /subsystem=undertow/server=*default-server*/host=*default-host* And here are two capabilities in this path. first is {{/subsystem=undertow/server=default}} which server capability with name "default" but host capability is defined by its name as well as name of server capability that is its parent. We need support in management layer to expose this kind of capability names. Prototype impl is available my branch https://github.com/ctomc/wildfly-core/tree/capabilites-api -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5416) Unhandled exceptions from custom JASPI modules should cause the HTTP status code to be set as an error (500, 400, etc)

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-5416?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-5416: ----------------------------------------------- Petr Penicka <ppenicka(a)redhat.com> changed the Status of [bug 1262482|https://bugzilla.redhat.com/show_bug.cgi?id=1262482] from VERIFIED to CLOSED > Unhandled exceptions from custom JASPI modules should cause the HTTP status code to be set as an error (500, 400, etc) > ---------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-5416 > URL: https://issues.jboss.org/browse/WFLY-5416 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Reporter: Derek Horton > Assignee: Stuart Douglas > Fix For: 10.0.0.CR4 > > > If a custom JASPI auth module throws an exception, Wildfly/Undertow (the JASPI authenticator) ignores it and returns a 200. The web page that was requested does not get displayed. A blank page and a HTTP 200 are returned. > Should a 40x or a 500 be returned instead? Or is it the responsibility of the custom JASPI auth module to set the status correctly? > It seems like the container would need to be careful and not overwrite a status code that the JASPI module had explicitly set. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7890) Unable to set IPv6 address in Elytron authentication context match-host rule

by Ilia Vassilev (JIRA)

[ https://issues.jboss.org/browse/WFLY-7890?page=com.atlassian.jira.plugin.... ] Ilia Vassilev reassigned WFLY-7890: ----------------------------------- Assignee: Ilia Vassilev > Unable to set IPv6 address in Elytron authentication context match-host rule > ---------------------------------------------------------------------------- > > Key: WFLY-7890 > URL: https://issues.jboss.org/browse/WFLY-7890 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 11.0.0.Alpha1 > Reporter: Martin Choma > Assignee: Ilia Vassilev > > Setting IPv6 address in wildfly-config.xml cause validation error. > {code:xml|title=wildfly-config.xml} > <?xml version="1.0" encoding="UTF-8"?> > <authentication-client xmlns="urn:elytron:1.0"> > <authentication-configurations> > <configuration name="set-host-to-localhost"> > <set-host name="localhost"/> > </configuration> > </authentication-configurations> > <authentication-rules> > <rule use-configuration="set-host-to-localhost"> > <match-host name="::1"/> > </rule> > </authentication-rules> > </authentication-client> > {code} > {code:title=server.log} > java.lang.IllegalArgumentException: ELY01029: Invalid host specification "::1" > at org.wildfly.security.auth.client.MatchHostRule.<init>(MatchHostRule.java:39) > at org.wildfly.security.auth.client.MatchRule.matchHost(MatchRule.java:411) > at org.wildfly.security.auth.client.ElytronXmlParser.parseAbstractMatchRuleType(ElytronXmlParser.java:701) > at org.wildfly.security.auth.client.ElytronXmlParser.parseAuthenticationRuleType(ElytronXmlParser.java:467) > at org.wildfly.security.auth.client.ElytronXmlParser.parseRulesType(ElytronXmlParser.java:484) > at org.wildfly.security.auth.client.ElytronXmlParser.parseAuthenticationClientType(ElytronXmlParser.java:241) > at org.wildfly.security.auth.client.ElytronXmlParser.parseAuthenticationClientConfiguration(ElytronXmlParser.java:169) > at org.wildfly.security.auth.client.XmlConfigurationTest.testMatcHostRuleConfiguration(XmlConfigurationTest.java:175) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47) > at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) > at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44) > at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50) > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236) > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229) > at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26) > at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27) > at org.junit.runners.ParentRunner.run(ParentRunner.java:309) > at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:367) > at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:274) > at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238) > at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:161) > at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:290) > at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:242) > at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:121) > {code} > It is because of elytron validation [1]. However don't know if just allowing ":" in regexp is valid solution. > [1] https://github.com/wildfly-security/wildfly-elytron/blob/7debbcabc7c20be5... -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBWEB-310) Allow servlets to be marked overridable via Servlet registration API

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JBWEB-310?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on JBWEB-310: ----------------------------------------------- Petr Penicka <ppenicka(a)redhat.com> changed the Status of [bug 1094248|https://bugzilla.redhat.com/show_bug.cgi?id=1094248] from VERIFIED to CLOSED > Allow servlets to be marked overridable via Servlet registration API > -------------------------------------------------------------------- > > Key: JBWEB-310 > URL: https://issues.jboss.org/browse/JBWEB-310 > Project: JBoss Web > Issue Type: Enhancement > Affects Versions: JBossWeb-7.5.0.GA > Reporter: James Livingston > Assignee: Remy Maucherat > Attachments: JBWEB-310.patch > > > To resolve https://bugzilla.redhat.com/show_bug.cgi?id=1094248, JBossWeb needs to add an 'overridable' flag on Wrapper, and not treat new mappings as conflicting if the one previously using the mapping was marked overridable. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBMETA-385) Add overridable flag to servlet metadata

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JBMETA-385?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on JBMETA-385: ------------------------------------------------ Petr Penicka <ppenicka(a)redhat.com> changed the Status of [bug 1094248|https://bugzilla.redhat.com/show_bug.cgi?id=1094248] from VERIFIED to CLOSED > Add overridable flag to servlet metadata > ---------------------------------------- > > Key: JBMETA-385 > URL: https://issues.jboss.org/browse/JBMETA-385 > Project: JBoss Metadata > Issue Type: Enhancement > Components: web > Affects Versions: 7.2.1.Final > Reporter: James Livingston > Assignee: Bartosz Baranowski > Fix For: 7.2.2.Final > > > To resolve https://bugzilla.redhat.com/show_bug.cgi?id=1094248, I believe we need an additional 'overridable' flag on the servlet metadata which indicates whether ServletContainerInitializers (and other code using servlet dynamic registration) should be allowed to override the servlet. Normally this is not allowed, however JBWeb's internal use of DefaultServlet to handle static resources should be. > This only needs to go into 7, since the Undertow subsystem in Wildfly handles this quite differently, so does not need to pass a flag between components. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1199) CLI Lists in non-interactive mode are erroneously split into multiple commands

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1199?page=com.atlassian.jira.plugi... ] RH Bugzilla Integration commented on WFCORE-1199: ------------------------------------------------- Petr Penicka <ppenicka(a)redhat.com> changed the Status of [bug 1284885|https://bugzilla.redhat.com/show_bug.cgi?id=1284885] from VERIFIED to CLOSED > CLI Lists in non-interactive mode are erroneously split into multiple commands > ------------------------------------------------------------------------------ > > Key: WFCORE-1199 > URL: https://issues.jboss.org/browse/WFCORE-1199 > Project: WildFly Core > Issue Type: Bug > Components: CLI, Modules, Patching > Reporter: Ryan Emerson > Assignee: Ryan Emerson > Fix For: 2.0.8.Final > > > The problem arises because commands entered in non-interactive mode are split by the "," character. Therefore, in the case of: > "./bin/jboss-cli.sh -c --controller=localhost --commands="module add --name=test --resources=test.jar --dependencies=dep1,dep2" > the cli is incorrectly splitting the request into two distinct commands: > 1. module add --name=test --resources=test.jar --dependencies=dep1 > 2. dep2 > The reason this behaviour is not observed in interactive mode is because multiple commands can not be specified. However, in non-interactive mode --commands=ls,pwd is valid and should result in the execution of ls followed by pwd. > This problem is not restricted to the module command, as it affects all commands entered in non-interactive mode that require a comma-separated list as an argument. So far this appears to be PatchHanlder.java, ASModuleHandler.java and DeploymentOverlayHandler.java. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6402) EJBs accessible too early (spec violation)

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-6402?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-6402: ----------------------------------------------- Petr Penicka <ppenicka(a)redhat.com> changed the Status of [bug 1310908|https://bugzilla.redhat.com/show_bug.cgi?id=1310908] from VERIFIED to CLOSED > EJBs accessible too early (spec violation) > ------------------------------------------ > > Key: WFLY-6402 > URL: https://issues.jboss.org/browse/WFLY-6402 > Project: WildFly > Issue Type: Bug > Components: EJB > Affects Versions: 10.0.0.Final > Reporter: Brad Maxwell > Assignee: Fedor Gavrilov > Labels: downstream_dependency > Attachments: auto-test-reproducer.zip > > > {code} > EJB 3.1 spec, section 4.8.1: > "If the Startup annotation appears on the Singleton bean class or if the Singleton has been designated via the deployment descriptor as requiring eager initialization, the container must initialize the Singleton bean instance during the application startup sequence. The container must initialize all such startup-time Singletons before any external client requests (that is, client requests originating outside of the application) are delivered to any enterprise bean components in the application. > {code} > Wildlfy does not implement this correctly, and allows calls to other EJBs before a @Startup @Singleton finishes its @PostConstruct call. > This Jira ticket handles two PR's on WFLY: > https://github.com/wildfly/wildfly/pull/8824 (that is already merged) > and https://github.com/wildfly/wildfly/pull/8989 -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1525) ageout-history does not report failures

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1525?page=com.atlassian.jira.plugi... ] RH Bugzilla Integration commented on WFCORE-1525: ------------------------------------------------- Petr Penicka <ppenicka(a)redhat.com> changed the Status of [bug 1331586|https://bugzilla.redhat.com/show_bug.cgi?id=1331586] from VERIFIED to CLOSED > ageout-history does not report failures > ---------------------------------------- > > Key: WFCORE-1525 > URL: https://issues.jboss.org/browse/WFCORE-1525 > Project: WildFly Core > Issue Type: Bug > Components: Patching > Affects Versions: 2.1.0.Final > Reporter: Dennis Reed > Assignee: Bartosz Spyrko-Śmietanko > Fix For: 3.0.0.Alpha1 > > > When ageout-history cannot delete the old CP files, it silently fails and returns "success". > LocalAgeoutHistoryHandler#recursiveDelete does keep track of whether the > delete failed or succeeded, but the return value from this method is ignored > in execute(...). > If recursiveDelete returns false, it should report a failure. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 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 January 2017