February 2015 - jboss-jira - Jboss List Archives

[JBoss JIRA] (JBJCA-1245) Custom URL selector doesn't take effect

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JBJCA-1245?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on JBJCA-1245: ------------------------------------------------ Martin Simka <msimka(a)redhat.com> changed the Status of [bug 1182879|https://bugzilla.redhat.com/show_bug.cgi?id=1182879] from ON_QA to VERIFIED > Custom URL selector doesn't take effect > --------------------------------------- > > Key: JBJCA-1245 > URL: https://issues.jboss.org/browse/JBJCA-1245 > Project: IronJacamar > Issue Type: Bug > Components: JDBC > Affects Versions: 1.0.30.Final, 1.1.9.Final, 1.2.2.Final > Reporter: Jesper Pedersen > Assignee: Jesper Pedersen > Fix For: 1.0.31.Final, 1.1.10.Final, 1.2.3.Final > > -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-544) Inconsistent handling of system properties.

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFCORE-544?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on WFCORE-544: ------------------------------------------------ Martin Simka <msimka(a)redhat.com> changed the Status of [bug 1192467|https://bugzilla.redhat.com/show_bug.cgi?id=1192467] from ON_QA to VERIFIED > Inconsistent handling of system properties. > -------------------------------------------- > > Key: WFCORE-544 > URL: https://issues.jboss.org/browse/WFCORE-544 > Project: WildFly Core > Issue Type: Bug > Reporter: ehsavoie Hugonnet > Assignee: ehsavoie Hugonnet > Fix For: 1.0.0.Alpha19 > > > Description of problem: > Having a domain with a single server group and two eap hosts (all on localhost), following system property cause server to fail on startup: > <property name="org.jbpm.designer.perspective" value="${org.jbpm.designer.perspective:full}"/> > The problem occurs only in definition with possibility to override default value - <property name="X" value="${Y:default}"/>, where X = Y > Please see the error message in attached server log excerpt. > More interesting is the fact that the issue shows with domain mode only, standalone mode works with properties defined as above. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-4356) build.sh fails on OS X

by Carlo de Wolf (JIRA)

[ https://issues.jboss.org/browse/WFLY-4356?page=com.atlassian.jira.plugin.... ] Carlo de Wolf reassigned WFLY-4356: ----------------------------------- Assignee: Carlo de Wolf (was: Paul Gier) > build.sh fails on OS X > ----------------------- > > Key: WFLY-4356 > URL: https://issues.jboss.org/browse/WFLY-4356 > Project: WildFly > Issue Type: Bug > Components: Build System > Reporter: Jeff Mesnil > Assignee: Carlo de Wolf > > the build.sh script fails on Mac OS X: > {noformat} > $ ./build.sh clean install > Maven already exists > Maven is correct version > ./build.sh: line 107: ulimit: open files: cannot modify limit: Invalid argument > {noformat} > The ulimit error was already present before but since WFLY-4305, the build.sh script will exit after this error instead of continuing. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-567) Invoking shutdown command for slave HC results in CLI disconnecting

by Alexey Loubyansky (JIRA)

[ https://issues.jboss.org/browse/WFCORE-567?page=com.atlassian.jira.plugin... ] Alexey Loubyansky commented on WFCORE-567: ------------------------------------------ This was supposed to be fixed before. https://github.com/aloubyansky/wildfly-core/commit/a2d3bc62188df66e61f42a... introduced boolean isMaster(ModelControllerClient client, String host) method for that. > Invoking shutdown command for slave HC results in CLI disconnecting > ------------------------------------------------------------------- > > Key: WFCORE-567 > URL: https://issues.jboss.org/browse/WFCORE-567 > Project: WildFly Core > Issue Type: Bug > Components: CLI > Affects Versions: 1.0.0.Alpha19 > Reporter: Brian Stansberry > Assignee: Alexey Loubyansky > > Connect the CLI to the master in a domain with a slave HC and shut down the slave. CLI disconnects: > {code} > [domain@localhost:9990 /] shutdown --host=slave > [disconnected /] > {code} -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 1 month

1
0
0 / 0

[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)

9 years, 1 month

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)

9 years, 1 month

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)

9 years, 1 month

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)

9 years, 1 month

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)

9 years, 1 month

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)

9 years, 1 month

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira February 2015