November 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-7620) Core bridge is possible to create without forwarding-address

by Jeff Mesnil (JIRA)

[ https://issues.jboss.org/browse/WFLY-7620?page=com.atlassian.jira.plugin.... ] Jeff Mesnil closed WFLY-7620. ----------------------------- Resolution: Rejected > Core bridge is possible to create without forwarding-address > ------------------------------------------------------------ > > Key: WFLY-7620 > URL: https://issues.jboss.org/browse/WFLY-7620 > Project: WildFly > Issue Type: Bug > Components: JMS > Affects Versions: 10.1.0.Final > Reporter: Jeff Mesnil > Assignee: Jeff Mesnil > Priority: Minor > > Core bridge is possible to create without forwarding-address: > {code} > [standalone@localhost:9990 /] /subsystem=messaging-activemq/server=default/bridge=b:add(producer-window-size=-12,discovery-group=dg-group1, queue-name=jms.queue.DLQ) > {"outcome" => "success"} > {code} > It should be required parameter and such command should fail. > Additionally producer-window-size should not allow to set value -12. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ELY-763) Add trace logging to AuthenticationConfiguration

by Darran Lofthouse (JIRA)

Darran Lofthouse created ELY-763: ------------------------------------ Summary: Add trace logging to AuthenticationConfiguration Key: ELY-763 URL: https://issues.jboss.org/browse/ELY-763 Project: WildFly Elytron Issue Type: Enhancement Components: Authentication Client Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 1.1.0.Beta15 Where an AuthenticationConfiguration instance is selected for use we need to be able to log the resulting configuration. It should be possible to call a toString or equivalent that navigates the full hierarchy to log the settings in order. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7620) Core bridge is possible to create without forwarding-address

by Jeff Mesnil (JIRA)

[ https://issues.jboss.org/browse/WFLY-7620?page=com.atlassian.jira.plugin.... ] Jeff Mesnil moved JBEAP-7383 to WFLY-7620: ------------------------------------------ Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-7620 (was: JBEAP-7383) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: JMS (was: JMS) Affects Version/s: 10.1.0.Final (was: 7.1.0.DR8) > Core bridge is possible to create without forwarding-address > ------------------------------------------------------------ > > Key: WFLY-7620 > URL: https://issues.jboss.org/browse/WFLY-7620 > Project: WildFly > Issue Type: Bug > Components: JMS > Affects Versions: 10.1.0.Final > Reporter: Jeff Mesnil > Assignee: Jeff Mesnil > Priority: Minor > > Core bridge is possible to create without forwarding-address: > {code} > [standalone@localhost:9990 /] /subsystem=messaging-activemq/server=default/bridge=b:add(producer-window-size=-12,discovery-group=dg-group1, queue-name=jms.queue.DLQ) > {"outcome" => "success"} > {code} > It should be required parameter and such command should fail. > Additionally producer-window-size should not allow to set value -12. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1914) Test default CLI assignee

by Jean-Francois Denise (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1914?page=com.atlassian.jira.plugi... ] Jean-Francois Denise closed WFCORE-1914. ---------------------------------------- Resolution: Rejected > Test default CLI assignee > ------------------------- > > Key: WFCORE-1914 > URL: https://issues.jboss.org/browse/WFCORE-1914 > Project: WildFly Core > Issue Type: Bug > Components: CLI > Reporter: Jean-Francois Denise > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7210) Expose JAX-RS resources as children of the subsystem

by Lin Gao (JIRA)

[ https://issues.jboss.org/browse/WFLY-7210?page=com.atlassian.jira.plugin.... ] Lin Gao commented on WFLY-7210: ------------------------------- [~ggam] I am really sorry for the late reply. :-) What was concerned when implementing WFLY-7024 without more level of sub resources is that it may produce too much resources and sub-resources in case of large deployments in memory. And the REST endpoints information will probably be parsed during deployment time, which will potentially impact the deployment time. Current design is that each root REST resource is added during deployment by {{JaxrsScanningProcessor}} without further analyzing inside of the ResourceClass. The {{:read-resource()}} operation will read the information in {{ResourceMethodRegistry}} exposed by {{HttpServletDispatcher}} at run-time. Is it possible that the web console can parse the data for the jaxrs subsystem to customize the UI as we want? [~mkopecky] [~harald.pehl] WDYT? > Expose JAX-RS resources as children of the subsystem > ---------------------------------------------------- > > Key: WFLY-7210 > URL: https://issues.jboss.org/browse/WFLY-7210 > Project: WildFly > Issue Type: Feature Request > Components: REST > Affects Versions: 10.1.0.Final > Reporter: Guillermo González de Agüero > Assignee: Lin Gao > Attachments: after-wfly7024.png, hal-jaxrs.png > > > Servlets, EJBs, WebSockets, JPA, etc expose its components as children of the subsystem in the management API. For example to list the stateless EJBs of a deployment: > [standalone@localhost:9990 /] /deployment=cdivsejb.war/subsystem=ejb3:read-children-resources(child-type=stateless-session-bean) > This makes it specially easy to navigate trough the web console (attached screenshot). > To read JAX-RS resources, the command would be: > [standalone@localhost:9990 /] /deployment=cdivsejb.war/subsystem=jaxrs:show-resources() > I propose to make deprecate the show-resources operation and create a new "resources" child, containing the Rest resources. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2131) UNICAST3 drops all messages until it receives the first one

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2131?page=com.atlassian.jira.plugin.... ] Bela Ban edited comment on JGRP-2131 at 11/17/16 2:46 AM: ---------------------------------------------------------- Intercepting {{JOIN_RSP}} and {{INSTALL_MERGE_VIEW}} messages, determining the keyserver (= coordinator) and sending a request for the shared key to it fixed the issue. The unit test which reproduces the problem is {{ASYM_ENCRYPT_BlockTest}} \[1\]. \[1\] https://github.com/belaban/JGroups/blob/master/tests/byteman/org/jgroups/... was (Author: belaban): Intercepting {{JOIN_RSP}} and {{INSTALL_MERGE_VIEW}} messages, determining the keyserver (= coordinator) and sending a request for the shared key to it fixed the issue. The unit test which reproduces the problem is {{ASYM_ENCRYPT_BlockTest}}. > UNICAST3 drops all messages until it receives the first one > ----------------------------------------------------------- > > Key: JGRP-2131 > URL: https://issues.jboss.org/browse/JGRP-2131 > Project: JGroups > Issue Type: Bug > Affects Versions: 3.6.10 > Reporter: Dennis Reed > Assignee: Bela Ban > Fix For: 3.6.12, 4.0 > > > UNICAST3.getReceiverEntry returns null if it hasn't seen the first message yet. > This causes UNICAST3.handleDataReceived to drop the message. > When you add *ENCRYPT, this causes a major deadlock. *ENCRYPT will queue most messages until it gets the encryption key, which can often include the first message (so UNICAST3 won't see it yet). Then when an important message such as JOIN_RSP comes through, UNICAST3 drops it. Since UNICAST3 never lets any messages through in this case, the encryption key will never get set so that *ENCRYPT can pass the first message up and free the deadlock. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2131) UNICAST3 drops all messages until it receives the first one

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2131?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-2131: -------------------------------- Intercepting {{JOIN_RSP}} and {{INSTALL_MERGE_VIEW}} messages, determining the keyserver (= coordinator) and sending a request for the shared key to it fixed the issue. The unit test which reproduces the problem is {{ASYM_ENCRYPT_BlockTest}}. > UNICAST3 drops all messages until it receives the first one > ----------------------------------------------------------- > > Key: JGRP-2131 > URL: https://issues.jboss.org/browse/JGRP-2131 > Project: JGroups > Issue Type: Bug > Affects Versions: 3.6.10 > Reporter: Dennis Reed > Assignee: Bela Ban > Fix For: 3.6.12, 4.0 > > > UNICAST3.getReceiverEntry returns null if it hasn't seen the first message yet. > This causes UNICAST3.handleDataReceived to drop the message. > When you add *ENCRYPT, this causes a major deadlock. *ENCRYPT will queue most messages until it gets the encryption key, which can often include the first message (so UNICAST3 won't see it yet). Then when an important message such as JOIN_RSP comes through, UNICAST3 drops it. Since UNICAST3 never lets any messages through in this case, the encryption key will never get set so that *ENCRYPT can pass the first message up and free the deadlock. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1998) Custom NameService by sun.net.spi.nameservice.provider.n doesn't work on WildFly

by Lin Gao (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1998?page=com.atlassian.jira.plugi... ] Lin Gao updated WFCORE-1998: ---------------------------- Labels: downstream_dependency (was: ) > Custom NameService by sun.net.spi.nameservice.provider.n doesn't work on WildFly > -------------------------------------------------------------------------------- > > Key: WFCORE-1998 > URL: https://issues.jboss.org/browse/WFCORE-1998 > Project: WildFly Core > Issue Type: Bug > Components: Modules > Affects Versions: 2.2.0.Final > Reporter: Osamu Nagano > Assignee: Osamu Nagano > Labels: downstream_dependency > Attachments: nameserviceProviderTest.zip > > > System property {{sun.net.spi.nameservice.provider.<n>}} allows a user to customize a NameService. It works on a standalone java, which is using JBoss Modules, if {{services="import"}} is added on sun.jdk module dependency and the sun.jdk module has the following additional dependencies. > {code} > <path name="sun/net/spi/nameservice"/> > <path name="sun/net/spi/nameservice/dns"/> > {code} > Though it doesn't work as a web application which has the same module path and the same dependency in jboss-deployment-structure.xml. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (LOGTOOL-119) GeneratedSourceAnalysisTest needs to be redone

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/LOGTOOL-119?page=com.atlassian.jira.plugi... ] James Perkins updated LOGTOOL-119: ---------------------------------- Git Pull Request: https://github.com/jboss-logging/jboss-logging-tools/pull/54, https://github.com/jboss-logging/jboss-logging-tools/pull/55 (was: https://github.com/jboss-logging/jboss-logging-tools/pull/54) > GeneratedSourceAnalysisTest needs to be redone > ---------------------------------------------- > > Key: LOGTOOL-119 > URL: https://issues.jboss.org/browse/LOGTOOL-119 > Project: Log Tool > Issue Type: Task > Reporter: James Perkins > Assignee: James Perkins > Fix For: 2.0.2.Final, 2.1.0.Alpha1 > > > The {{GeneratedSourceAnalysisTest}} test needs to be redone to better parse source files. Adding new methods or various enhancements to the generated source files usually causes problems with the test. The parsing is also very crude and should be improved. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (LOGTOOL-119) GeneratedSourceAnalysisTest needs to be redone

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/LOGTOOL-119?page=com.atlassian.jira.plugi... ] James Perkins updated LOGTOOL-119: ---------------------------------- Fix Version/s: 2.0.2.Final > GeneratedSourceAnalysisTest needs to be redone > ---------------------------------------------- > > Key: LOGTOOL-119 > URL: https://issues.jboss.org/browse/LOGTOOL-119 > Project: Log Tool > Issue Type: Task > Reporter: James Perkins > Assignee: James Perkins > Fix For: 2.0.2.Final, 2.1.0.Alpha1 > > > The {{GeneratedSourceAnalysisTest}} test needs to be redone to better parse source files. Adding new methods or various enhancements to the generated source files usually causes problems with the test. The parsing is also very crude and should be improved. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

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