October 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (JBEE-169) Use JBoss Modules to load RESTEasy implementations of javax.ws.rs.ext.RuntimeDelegate and javax.ws.rs.client.ClientBuilder

by Alessio Soldano (JIRA)

Alessio Soldano created JBEE-169: ------------------------------------ Summary: Use JBoss Modules to load RESTEasy implementations of javax.ws.rs.ext.RuntimeDelegate and javax.ws.rs.client.ClientBuilder Key: JBEE-169 URL: https://issues.jboss.org/browse/JBEE-169 Project: JBoss JavaEE Spec APIs Issue Type: Enhancement Components: jboss-jaxrs-api Reporter: Alessio Soldano Assignee: Alessio Soldano Currently jboss-jaxrs-api_2.0_spec has a modified RESTEasy value for the default implementation of javax.ws.rs.ext.RuntimeDelegate. It should likely keep the default Jersey / JDK values and load JBoss/RESTEasy implementations of both javax.ws.rs.ext.RuntimeDelegate and javax.ws.rs.client.ClientBuilder using JBoss Modules when running in-container. This is basically what the jaxws-api already does for the javax.xml.ws.spi.Provider. -- This message was sent by Atlassian JIRA (v7.2.2#72004)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1909) Tab completion causes NUL characters ('\0') to be injected...sometimes

by Jean-Francois Denise (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1909?page=com.atlassian.jira.plugi... ] Jean-Francois Denise commented on WFCORE-1909: ---------------------------------------------- Hi David, thank-you for the additional information. I ran your branch, the value-type is a simple String, nothing special there. I checked CLI code, no way to internally inject this character, I found an explanation to what you are experiencing. It could be that, as our IDE are offering completion with the combination of "Ctrl- space" (at least NetBeans and Eclipse), you typed at some point this combination to complete the CLI as you are used to do in your IDE. In the terminal Ctrl-space means '\0' character... I was able to reproduce the problem. Type 'Ctrl space', nothing is displayed in the CLI console although '\0' has been stored. I am going to see if we can filter out (or make them visible) these characters at the Aesh level. Aesh sees all characters and has the choice to keep them or not. > Tab completion causes NUL characters ('\0') to be injected...sometimes > ---------------------------------------------------------------------- > > Key: WFCORE-1909 > URL: https://issues.jboss.org/browse/WFCORE-1909 > Project: WildFly Core > Issue Type: Bug > Components: CLI > Reporter: David Lloyd > Assignee: Jean-Francois Denise > Priority: Critical > > I noticed while testing my subsystem that sometimes using tab-complete on an attribute causes NUL ('\0') characters to be injected into the input. These characters are invisible on the screen but cause XML marshalling to fail as that character is forbidden. > My "less" output of .jboss-cli-history looks something like this: > {noformat} > embed-server --std-out=echo > cd subsystem=discovery > ./static-provider=test:add(services=[{uri=^@^@"local", abstract-type="ejb", abstract-type-authority="jboss"}]) > ./static-provider=test4:add(services=[{uri="local", abstract-type="ejb", abstract-type-authority="jboss"}]) > {noformat} > In the first "test:add" case I used tab-completion; in the second "test4:add" case I typed it out by hand. The "^@" are in inverse video in less, indicating a NUL character. -- This message was sent by Atlassian JIRA (v7.2.2#72004)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1910) Add ability to inherit resources

by Pavel Jelinek (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1910?page=com.atlassian.jira.plugi... ] Pavel Jelinek updated WFCORE-1910: ---------------------------------- Labels: user_experience (was: ) > Add ability to inherit resources > -------------------------------- > > Key: WFCORE-1910 > URL: https://issues.jboss.org/browse/WFCORE-1910 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Reporter: Pavel Jelinek > Assignee: Brian Stansberry > Labels: user_experience > > Motivation: > to be able to have stable resources which name and structure will be backward compatible even between major releases (e.g. something like /subsystem=web-abstract) and which could be inherited/implemented by resources which bring more configuration possibilities but may not be backward compatible between major releases (like e.g. /subsystem=undertow). > This would give users the possibility to write *stable CLI/HTTP API/whatever automation* if they use stable (parent) resources. There will still remain the option to use full configuration options offered by the implementing (children) resources but without backward compatibility guarantee. -- This message was sent by Atlassian JIRA (v7.2.2#72004)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1910) Add ability to inherit resources

by Pavel Jelinek (JIRA)

Pavel Jelinek created WFCORE-1910: ------------------------------------- Summary: Add ability to inherit resources Key: WFCORE-1910 URL: https://issues.jboss.org/browse/WFCORE-1910 Project: WildFly Core Issue Type: Feature Request Components: Domain Management Reporter: Pavel Jelinek Assignee: Brian Stansberry Motivation: to be able to have stable resources which name and structure will be backward compatible even between major releases (e.g. something like /subsystem=web-abstract) and which could be inherited/implemented by resources which bring more configuration possibilities but may not be backward compatible between major releases (like e.g. /subsystem=undertow). This would give users the possibility to write *stable CLI/HTTP API/whatever automation* if they use stable (parent) resources. There will still remain the option to use full configuration options offered by the implementing (children) resources but without backward compatibility guarantee. -- This message was sent by Atlassian JIRA (v7.2.2#72004)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7420) Ignore client messaging tests failing with a security manager

by Jeff Mesnil (JIRA)

Jeff Mesnil created WFLY-7420: --------------------------------- Summary: Ignore client messaging tests failing with a security manager Key: WFLY-7420 URL: https://issues.jboss.org/browse/WFLY-7420 Project: WildFly Issue Type: Task Components: JMS Affects Versions: 10.1.0.Final Reporter: Jeff Mesnil Assignee: Jeff Mesnil The upgrade to Artemis 1.4.0 (WFLY-7245) introduced a regression for JMS clients running with a security manager. The issue was fixed in Artemis master branch (https://issues.apache.org/jira/browse/ARTEMIS-808) and will be part of the next release after 1.4.0. In the meantime, ignore the failing tests when the security manager is set. -- This message was sent by Atlassian JIRA (v7.2.2#72004)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7322) LDAP referrals does not work in Elytron ldap-realm

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/WFLY-7322?page=com.atlassian.jira.plugin.... ] Jan Kalina commented on WFLY-7322: ---------------------------------- [~dlofthouse] Do we need *throw* mode of LDAP referrals support? If we will follow every referral, it will be equivalent of *follow* mode. > LDAP referrals does not work in Elytron ldap-realm > -------------------------------------------------- > > Key: WFLY-7322 > URL: https://issues.jboss.org/browse/WFLY-7322 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 11.0.0.Alpha1 > Reporter: Ondrej Lukas > Assignee: Jan Kalina > Priority: Blocker > > LDAP referrals cannot be used in Elytron {{ldap-realm}}. Ldap Realm is currently not prepared to work with referrals at all: > * {{ldap-realm}} does not include any options which enable working with LDAP referrals (PicketBox use {{baseFilter}} option which can be configured to return also referral object) > * implementation of {{org.wildfly.security.auth.realm.ldap.LdapSecurityRealm}} does not include any logic which handles referrals > Referrals are important feature of LDAP. It has to be covered by Elytron => requested blocker flag. -- This message was sent by Atlassian JIRA (v7.2.2#72004)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1909) Tab completion causes NUL characters ('\0') to be injected...sometimes

by Jean-Francois Denise (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1909?page=com.atlassian.jira.plugi... ] Jean-Francois Denise moved WFLY-7398 to WFCORE-1909: ---------------------------------------------------- Project: WildFly Core (was: WildFly) Key: WFCORE-1909 (was: WFLY-7398) Component/s: CLI (was: CLI) > Tab completion causes NUL characters ('\0') to be injected...sometimes > ---------------------------------------------------------------------- > > Key: WFCORE-1909 > URL: https://issues.jboss.org/browse/WFCORE-1909 > Project: WildFly Core > Issue Type: Bug > Components: CLI > Reporter: David Lloyd > Assignee: Jean-Francois Denise > Priority: Critical > > I noticed while testing my subsystem that sometimes using tab-complete on an attribute causes NUL ('\0') characters to be injected into the input. These characters are invisible on the screen but cause XML marshalling to fail as that character is forbidden. > My "less" output of .jboss-cli-history looks something like this: > {noformat} > embed-server --std-out=echo > cd subsystem=discovery > ./static-provider=test:add(services=[{uri=^@^@"local", abstract-type="ejb", abstract-type-authority="jboss"}]) > ./static-provider=test4:add(services=[{uri="local", abstract-type="ejb", abstract-type-authority="jboss"}]) > {noformat} > In the first "test:add" case I used tab-completion; in the second "test4:add" case I typed it out by hand. The "^@" are in inverse video in less, indicating a NUL character. -- This message was sent by Atlassian JIRA (v7.2.2#72004)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1908) Tab completion suggest writing attribute which has access type metric and is not writable

by Chao Wang (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1908?page=com.atlassian.jira.plugi... ] Chao Wang moved JBEAP-6715 to WFCORE-1908: ------------------------------------------ Project: WildFly Core (was: JBoss Enterprise Application Platform) Key: WFCORE-1908 (was: JBEAP-6715) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: CLI (was: CLI) (was: User Experience) Affects Version/s: 3.0.0.Alpha11 (was: 7.1.0.DR7) > Tab completion suggest writing attribute which has access type metric and is not writable > ----------------------------------------------------------------------------------------- > > Key: WFCORE-1908 > URL: https://issues.jboss.org/browse/WFCORE-1908 > Project: WildFly Core > Issue Type: Bug > Components: CLI > Affects Versions: 3.0.0.Alpha11 > Reporter: Chao Wang > Assignee: Chao Wang > Priority: Minor > > CLI tab completion suggests attributes that are not writable and their access-type is {{metric}} > Example {code} > /subsystem=messaging-activemq/server=default/jms-queue=DLQ:write-attribute(name=<TAB> > consumer-count delivering-count entries legacy-entries message-count messages-added scheduled-count > {code} > From executing {{:read-resource-description}} we can see, attributes consumer-count, delivering-count, message-count, messages-added, scheduled-count are of type metric. > On attempt to write metric attribute, for example message-count, non writable error is printed {code} > [standalone@localhost:9990 jms-queue=q] :write-attribute(name=message-count, value=5) > { > "outcome" => "failed", > "failure-description" => "WFLYCTL0048: Attribute message-count is not writable", > "rolled-back" => true > } > {code} > CLI should not suggest writing attributes that are not writable. -- This message was sent by Atlassian JIRA (v7.2.2#72004)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5029) Reintroduce EJB, JMS, JNDI over HTTP/HTTPS capability with HTTP Loadbalancer

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/WFLY-5029?page=com.atlassian.jira.plugin.... ] Stuart Douglas reassigned WFLY-5029: ------------------------------------ Assignee: Stuart Douglas (was: Jason Greene) > Reintroduce EJB, JMS, JNDI over HTTP/HTTPS capability with HTTP Loadbalancer > ---------------------------------------------------------------------------- > > Key: WFLY-5029 > URL: https://issues.jboss.org/browse/WFLY-5029 > Project: WildFly > Issue Type: Feature Request > Components: EJB, Server, Web (Undertow) > Affects Versions: 11.0.0.Alpha1 > Reporter: Bilge Ozpeynirci > Assignee: Stuart Douglas > > Ability to run EJB, JMS, JNDI over HTTP/HTTPS which was possible in earlier JBoss AS/EAP 5 & 4. > User will be able to do 1:1 EJB invocation to HTTP request, so that HTTP requests (that carry EJB Load) can be load balanced at the request level instead of at the connection level. > 1:1 mapping of EJB invocation to an HTTP request will be possible. This way, a hardware HTTP LB or Undertow Load Balancer or HTTPD Load Balancer can balance the requests according to a custom LB policy. In this case; the EJB clustering will not have to be configured. -- This message was sent by Atlassian JIRA (v7.2.2#72004)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7364) java.lang.IllegalArgumentException: UT000068: Servlet path match failed

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/WFLY-7364?page=com.atlassian.jira.plugin.... ] Stuart Douglas resolved WFLY-7364. ---------------------------------- Resolution: Rejected > java.lang.IllegalArgumentException: UT000068: Servlet path match failed > ----------------------------------------------------------------------- > > Key: WFLY-7364 > URL: https://issues.jboss.org/browse/WFLY-7364 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 10.1.0.Final > Reporter: william teskey > Assignee: Stuart Douglas > Priority: Minor > > [0m[31m16:24:45,861 ERROR [io.undertow.request] (default I/O-6) UT005071: Undertow request failed HttpServerExchange{ GET china2000fineart.com request {Accept=[*/*], User-Agent=[Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/48.0.2564.109 Safari/537.36], Referer=[http://china2000fineart.com], Host=[china2000fineart.com]} response {}}: java.lang.IllegalArgumentException: UT000068: Servlet path match failed > at io.undertow.servlet.handlers.ServletPathMatchesData.getServletHandlerByPath(ServletPathMatchesData.java:83) > at io.undertow.servlet.handlers.ServletPathMatches.getServletHandlerByPath(ServletPathMatches.java:83) > at io.undertow.servlet.handlers.ServletInitialHandler.handleRequest(ServletInitialHandler.java:151) > at org.wildfly.extension.undertow.deployment.GlobalRequestControllerHandler.handleRequest(GlobalRequestControllerHandler.java:39) > at io.undertow.server.handlers.HttpContinueReadHandler.handleRequest(HttpContinueReadHandler.java:65) > at io.undertow.server.handlers.PathHandler.handleRequest(PathHandler.java:94) > at org.wildfly.extension.undertow.Host$OptionsHandler.handleRequest(Host.java:295) > at io.undertow.server.handlers.HttpContinueReadHandler.handleRequest(HttpContinueReadHandler.java:65) > at org.wildfly.extension.undertow.Host$HostRootHandler.handleRequest(Host.java:303) > at io.undertow.server.handlers.NameVirtualHostHandler.handleRequest(NameVirtualHostHandler.java:54) > at io.undertow.server.handlers.error.SimpleErrorPageHandler.handleRequest(SimpleErrorPageHandler.java:78) > at io.undertow.server.handlers.CanonicalPathHandler.handleRequest(CanonicalPathHandler.java:49) > at io.undertow.server.handlers.ChannelUpgradeHandler.handleRequest(ChannelUpgradeHandler.java:158) > at io.undertow.server.handlers.DisallowedMethodsHandler.handleRequest(DisallowedMethodsHandler.java:61) > at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202) > at io.undertow.server.protocol.http.HttpReadListener.handleEventWithNoRunningRequest(HttpReadListener.java:243) > at io.undertow.server.protocol.http.HttpReadListener.handleEvent(HttpReadListener.java:134) > at io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:148) > at io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:92) > at io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:51) > at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) > at org.xnio.ChannelListeners$10.handleEvent(ChannelListeners.java:291) > at org.xnio.ChannelListeners$10.handleEvent(ChannelListeners.java:286) > at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) > at org.xnio.nio.QueuedNioTcpServer$1.run(QueuedNioTcpServer.java:128) > at org.xnio.nio.WorkerThread.safeRun(WorkerThread.java:588) > at org.xnio.nio.WorkerThread.run(WorkerThread.java:468) -- This message was sent by Atlassian JIRA (v7.2.2#72004)

8 years, 2 months

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 October 2016