February 2015 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-4173) Server side EJB Handler not compression response

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-4173?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-4173: ----------------------------------------------- Jan Martiska <jmartisk(a)redhat.com> changed the Status of [bug 1172856|https://bugzilla.redhat.com/show_bug.cgi?id=1172856] from POST to ON_QA > Server side EJB Handler not compression response > ------------------------------------------------ > > Key: WFLY-4173 > URL: https://issues.jboss.org/browse/WFLY-4173 > Project: WildFly > Issue Type: Bug > Components: EJB > Affects Versions: 9.0.0.Alpha1 > Reporter: Brad Maxwell > Assignee: Tomas Hofman > > When compression is enabled for request/response, the jboss-ejb-client is sending a compressed request, but the application server is responding with an uncompressed response. > On the server enabling TRACE on org.jboss.as.ejb3, we can see the server receives a compressed request > TRACE [org.jboss.as.ejb3] (default task-5) Got message with header 0x1b on channel Channel ID 56b01772 (inbound) of Remoting connection TRACE [org.jboss.as.ejb3.invocation] (default task-5) Received a compressed message stream > Client side, Enabling TRACE on the client side for org.jboss.ejb.client we see it is 0x5 where it should be 0x1b > TRACE org.jboss.ejb.client.remoting.ChannelAssociation - Received message with header 0x5 -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1915) JDBC_PING discovery fails when stale entries are found in the database

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1915?page=com.atlassian.jira.plugin.... ] Bela Ban resolved JGRP-1915. ---------------------------- Resolution: Done > JDBC_PING discovery fails when stale entries are found in the database > ---------------------------------------------------------------------- > > Key: JGRP-1915 > URL: https://issues.jboss.org/browse/JGRP-1915 > Project: JGroups > Issue Type: Bug > Affects Versions: 3.6.1 > Reporter: Patrick Haas > Assignee: Bela Ban > Fix For: 3.6.3 > > > Node: "CHQ-PATRICKH-55008" > Database contains two rows.. other node is dead but was unable to remove the JDBC entry. > 1) JChannel.connect(...) > 2) JChannel.down(Event[CONNECT_WITH_STATE_TRANSFER_USE_FLUSH]) > 3) STATE_TRANSFER -> FRAG2 -> MFC -> UFC -> GMS > 4) GMS.down(...) calls out to joinWithStateTransfer -> joinInternal(...) > JDBC pulls the node list from the database table. > Ping Data: > - CHQ-PATRICKH-3895, name=CHQ-PATRICKH-3895, addr=10.1.130.228:55503, server > - CHQ-PATRICKH-55008, name=CHQ-PATRICKH-55008, addr=10.1.130.228:57489 > joinInternal is a never-terminating while loop: > - down: Event.FIND_INITIAL_MBRS_EVT > - inspect responses -- no valid join responses > - responses are NOT empty -> does not become singletonMember > - gets all coordinators (none) > - Sorts all nodes by GUID in a TreeSet > - Is first of all joiners? > - No, another joiner is listed first > ... repeat forever > When the process is restarted and a node ID < than the existing db entry is generated, it successfully takes over as owner. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1915) JDBC_PING discovery fails when stale entries are found in the database

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1915?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-1915: -------------------------------- OK, zombies are handled, too, now. I updated the documentation at [1], check it out and see if this fixes your issue. [1] http://www.jgroups.org/manual/index.html#_jdbc_ping > JDBC_PING discovery fails when stale entries are found in the database > ---------------------------------------------------------------------- > > Key: JGRP-1915 > URL: https://issues.jboss.org/browse/JGRP-1915 > Project: JGroups > Issue Type: Bug > Affects Versions: 3.6.1 > Reporter: Patrick Haas > Assignee: Bela Ban > Fix For: 3.6.3 > > > Node: "CHQ-PATRICKH-55008" > Database contains two rows.. other node is dead but was unable to remove the JDBC entry. > 1) JChannel.connect(...) > 2) JChannel.down(Event[CONNECT_WITH_STATE_TRANSFER_USE_FLUSH]) > 3) STATE_TRANSFER -> FRAG2 -> MFC -> UFC -> GMS > 4) GMS.down(...) calls out to joinWithStateTransfer -> joinInternal(...) > JDBC pulls the node list from the database table. > Ping Data: > - CHQ-PATRICKH-3895, name=CHQ-PATRICKH-3895, addr=10.1.130.228:55503, server > - CHQ-PATRICKH-55008, name=CHQ-PATRICKH-55008, addr=10.1.130.228:57489 > joinInternal is a never-terminating while loop: > - down: Event.FIND_INITIAL_MBRS_EVT > - inspect responses -- no valid join responses > - responses are NOT empty -> does not become singletonMember > - gets all coordinators (none) > - Sorts all nodes by GUID in a TreeSet > - Is first of all joiners? > - No, another joiner is listed first > ... repeat forever > When the process is restarted and a node ID < than the existing db entry is generated, it successfully takes over as owner. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4335) ArquillianService incorrectly sets TCCL

by Thomas Diesler (JIRA)

[ https://issues.jboss.org/browse/WFLY-4335?page=com.atlassian.jira.plugin.... ] Thomas Diesler commented on WFLY-4335: -------------------------------------- I can't see how this can be true for all threads that execute a given functionality. IMHO the guarantees are weak. It may be true that all requests coming in on an undertow endpoint can be mapped to a war deployment, but is this generally true for all? IMHO this shadows potential problems when the functionality under test is not called from an ARQ test case (i.e. from an normal javaee endpoint) Anyway, we can probably make this configurable (see WFLY-4392) so the current behaviour does not change for the wildfly tests. > ArquillianService incorrectly sets TCCL > --------------------------------------- > > Key: WFLY-4335 > URL: https://issues.jboss.org/browse/WFLY-4335 > Project: WildFly > Issue Type: Bug > Components: Test Suite > Affects Versions: 8.2.0.Final > Reporter: Thomas Diesler > Assignee: Thomas Diesler > > While integrating Camel in WildFly I noticed that @BeforeClass, @Before and @Test methods are being called with the TCCL of the test deployment. > Camel happens to rely on TCCL, which is of course questionable in a modular environment. As a result it uses the test deployment's CL for resource discovery. Tests pass in the context of ARQ, but would not in a normal usage scenario when TCCL is not set or set to something else. > This shadows potential problems when TCCL is not set or set to something else. > Related: https://github.com/wildfly-extras/wildfly-camel/issues/292 -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4392) Make use of TCCL in ARQ ManagedContainer configurable

by Thomas Diesler (JIRA)

[ https://issues.jboss.org/browse/WFLY-4392?page=com.atlassian.jira.plugin.... ] Thomas Diesler reassigned WFLY-4392: ------------------------------------ Assignee: Thomas Diesler > Make use of TCCL in ARQ ManagedContainer configurable > ----------------------------------------------------- > > Key: WFLY-4392 > URL: https://issues.jboss.org/browse/WFLY-4392 > Project: WildFly > Issue Type: Feature Request > Components: Test Suite > Reporter: Thomas Diesler > Assignee: Thomas Diesler > Fix For: 9.0.0.Beta1 > > > In WildFly it is considerred intended behaviour that test code gets called with the TCCL set to the test deployment. IMHO this shadows potential problems when the functionality under test is not called from an ARQ test case (i.e. from an normal javaee endpoint) > For Camel integration this behaviour is not acceptable. > CrossLink: https://github.com/wildfly-extras/wildfly-camel/issues/340 -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ELY-161) Deprecated Reflection in security manager

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/ELY-161?page=com.atlassian.jira.plugin.sy... ] Jan Kalina updated ELY-161: --------------------------- Description: WildFly security manager use deprecated API for getting of caller. Currently only public API to look at the call stack as Class instances, which will not be removed in future, is {{SecurityManager.getClassContext()}}, which is inefficient to use in performance critical parts. Efficient replacement of this API not exist yet, should be added in Java 9: https://bugs.openjdk.java.net/browse/JDK-8043814 *This task can be resolved only after resolving JDK-8043814.* When mentioned enhancement proposial will be implemented, it shoudl replace current {{SecurityManager.getClassContext()}} fallback. But this new API only replace current fallback for Java 9 - deprecated API must stay for Java 8. This issue is related to following build warning: (mentioned for search) {code} WildFlySecurityManager.java:[117,32] getCallerClass(int) in sun.reflect.Reflection has been deprecated {code} was: WildFly security manager use deprecated API for getting of caller. Currently only public API to look at the call stack as Class instances, which will not be removed in future, is {{SecurityManager.getClassContext()}}, which is inefficient to use in performance critical parts. Efficient replacement of this API not exist yet, should be added in Java 9: https://bugs.openjdk.java.net/browse/JDK-8043814 When mentioned enhancement proposial will be implemented, it shoudl replace current {{SecurityManager.getClassContext()}} fallback. But this new API only replace current fallback for Java 9 - deprecated API must stay for Java 8. This issue is related to following build warning: (mentioned for search) {code} WildFlySecurityManager.java:[117,32] getCallerClass(int) in sun.reflect.Reflection has been deprecated {code} > Deprecated Reflection in security manager > ----------------------------------------- > > Key: ELY-161 > URL: https://issues.jboss.org/browse/ELY-161 > Project: WildFly Elytron > Issue Type: Task > Components: Security Manager > Reporter: Jan Kalina > Priority: Minor > > WildFly security manager use deprecated API for getting of caller. > Currently only public API to look at the call stack as Class instances, which will not be removed in future, is {{SecurityManager.getClassContext()}}, which is inefficient to use in performance critical parts. > Efficient replacement of this API not exist yet, should be added in Java 9: > https://bugs.openjdk.java.net/browse/JDK-8043814 > *This task can be resolved only after resolving JDK-8043814.* > When mentioned enhancement proposial will be implemented, it shoudl replace current {{SecurityManager.getClassContext()}} fallback. But this new API only replace current fallback for Java 9 - deprecated API must stay for Java 8. > This issue is related to following build warning: (mentioned for search) > {code} > WildFlySecurityManager.java:[117,32] getCallerClass(int) in sun.reflect.Reflection has been deprecated > {code} -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4392) Make use of TCCL in ARQ ManagedContainer configurable

by Thomas Diesler (JIRA)

Thomas Diesler created WFLY-4392: ------------------------------------ Summary: Make use of TCCL in ARQ ManagedContainer configurable Key: WFLY-4392 URL: https://issues.jboss.org/browse/WFLY-4392 Project: WildFly Issue Type: Feature Request Components: Test Suite Reporter: Thomas Diesler Fix For: 9.0.0.Beta1 In WildFly it is considerred intended behaviour that test code gets called with the TCCL set to the test deployment. IMHO this shadows potential problems when the functionality under test is not called from an ARQ test case (i.e. from an normal javaee endpoint) For Camel integration this behaviour is not acceptable. CrossLink: https://github.com/wildfly-extras/wildfly-camel/issues/340 -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4389) Upgrade HAL to 2.6.4.Final

by Harald Pehl (JIRA)

[ https://issues.jboss.org/browse/WFLY-4389?page=com.atlassian.jira.plugin.... ] Harald Pehl updated WFLY-4389: ------------------------------ Git Pull Request: (was: https://github.com/wildfly/wildfly/pull/7199) > Upgrade HAL to 2.6.4.Final > -------------------------- > > Key: WFLY-4389 > URL: https://issues.jboss.org/browse/WFLY-4389 > Project: WildFly > Issue Type: Component Upgrade > Components: Web Console > Reporter: Harald Pehl > Assignee: Harald Pehl > Fix For: 9.0.0.Beta1 > > -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4391) When testing with WildFly Full, the WSTestCase is randomly unstable

by ehsavoie Hugonnet (JIRA)

[ https://issues.jboss.org/browse/WFLY-4391?page=com.atlassian.jira.plugin.... ] ehsavoie Hugonnet moved WFCORE-550 to WFLY-4391: ------------------------------------------------ Project: WildFly (was: WildFly Core) Key: WFLY-4391 (was: WFCORE-550) Affects Version/s: 9.0.0.Alpha1 (was: 1.0.0.Alpha18) Component/s: Test Suite (was: Test Suite) > When testing with WildFly Full, the WSTestCase is randomly unstable > ------------------------------------------------------------------- > > Key: WFLY-4391 > URL: https://issues.jboss.org/browse/WFLY-4391 > Project: WildFly > Issue Type: Bug > Components: Test Suite > Affects Versions: 9.0.0.Alpha1 > Reporter: ehsavoie Hugonnet > Assignee: ehsavoie Hugonnet > > Sometimes the WSTestCase will fail without any reason. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-569) Clean the DiscoveryOption API

by ehsavoie Hugonnet (JIRA)

[ https://issues.jboss.org/browse/WFCORE-569?page=com.atlassian.jira.plugin... ] ehsavoie Hugonnet updated WFCORE-569: ------------------------------------- Summary: Clean the DiscoveryOption API (was: Clean the DiscoveryIOption API) > Clean the DiscoveryOption API > ----------------------------- > > Key: WFCORE-569 > URL: https://issues.jboss.org/browse/WFCORE-569 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management > Affects Versions: 1.0.0.Alpha19 > Reporter: ehsavoie Hugonnet > Assignee: ehsavoie Hugonnet > > DiscoveryOption discover should return a list of connection parameters to a DC instead of only one value set into the DiscoveryOption. > Add a ConnectionParameter class with protocol, host and post and returns a list of those when discovering so that we may have multiple options ofr S3 for example. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 2 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 February 2015