March 2014 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-2644) Java heap space exceeded looping connect/disconnect cycle

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-2644?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-2644: ----------------------------------------------- Kabir Khan <kkhan(a)redhat.com> changed the Status of [bug 1037574|https://bugzilla.redhat.com/show_bug.cgi?id=1037574] from POST to MODIFIED > Java heap space exceeded looping connect/disconnect cycle > --------------------------------------------------------- > > Key: WFLY-2644 > URL: https://issues.jboss.org/browse/WFLY-2644 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: CLI > Affects Versions: 8.0.0.Beta1 > Reporter: Alexey Loubyansky > Assignee: Alexey Loubyansky > Fix For: 8.0.0.Final > > > CLIModelControllerClient implementation is not cleaning up something related to connection handling which leads to OOME repeating a cycle of ensureConnected(...) and close(). On my laptop it happens after around 1400 iterations. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3099) management authorization throws an exception when an LDAP group contains a slash/backslash character

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-3099?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-3099: ----------------------------------------------- Carlo de Wolf <cdewolf(a)redhat.com> changed the Status of [bug 1075082|https://bugzilla.redhat.com/show_bug.cgi?id=1075082] from MODIFIED to ASSIGNED > management authorization throws an exception when an LDAP group contains a slash/backslash character > ---------------------------------------------------------------------------------------------------- > > Key: WFLY-3099 > URL: https://issues.jboss.org/browse/WFLY-3099 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Domain Management > Affects Versions: 8.0.0.Final > Reporter: Tom Fonteyne > Assignee: Tom Fonteyne > > management authorization throws an exception when an LDAP group contains a slash/backslash character -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3067) Webservices DUP is not scanning all visible classes for @WebService annotation

by Jim Ma (JIRA)

[ https://issues.jboss.org/browse/WFLY-3067?page=com.atlassian.jira.plugin.... ] Jim Ma reassigned WFLY-3067: ---------------------------- Assignee: Jim Ma (was: Alessio Soldano) > Webservices DUP is not scanning all visible classes for @WebService annotation > ------------------------------------------------------------------------------ > > Key: WFLY-3067 > URL: https://issues.jboss.org/browse/WFLY-3067 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Web Services > Affects Versions: 8.0.0.Final > Reporter: Kyle Lape > Assignee: Jim Ma > Fix For: 8.0.1.Final > > > Sample use case: You have a .war in an .ear, and the .war has a web.xml with a {{<servlet-class>}} that refers to a JAX-WS endpoint, so the class is annotated with {{@WebService}}. If that class is packaged in a jar found in the ear's lib directory, the JBossWS DUP won't pick it up, and then Undertow will throw an error like this: > {noformat} > UT010009: Servlet ClientEndpoint of type class com.redhat.gss.jaxws.ClientEndpoint does not implement javax.servlet.Servlet > {noformat} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2644) Java heap space exceeded looping connect/disconnect cycle

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-2644?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-2644: ----------------------------------------------- Kabir Khan <kkhan(a)redhat.com> changed the Status of [bug 1037574|https://bugzilla.redhat.com/show_bug.cgi?id=1037574] from NEW to POST > Java heap space exceeded looping connect/disconnect cycle > --------------------------------------------------------- > > Key: WFLY-2644 > URL: https://issues.jboss.org/browse/WFLY-2644 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: CLI > Affects Versions: 8.0.0.Beta1 > Reporter: Alexey Loubyansky > Assignee: Alexey Loubyansky > Fix For: 8.0.0.Final > > > CLIModelControllerClient implementation is not cleaning up something related to connection handling which leads to OOME repeating a cycle of ensureConnected(...) and close(). On my laptop it happens after around 1400 iterations. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2972) Load vault impls from modules other than org.jboss.security

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFLY-2972?page=com.atlassian.jira.plugin.... ] Brian Stansberry resolved WFLY-2972. ------------------------------------ Resolution: Duplicate Issue > Load vault impls from modules other than org.jboss.security > ----------------------------------------------------------- > > Key: WFLY-2972 > URL: https://issues.jboss.org/browse/WFLY-2972 > Project: WildFly > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Security > Affects Versions: 8.0.0.Final > Reporter: Brian Stansberry > Assignee: Anil Saldhana > > The vault resources in our management model have a "code" attribute that specifies the classname of a custom Vault impl. But there is no "module" attribute to specify the name of the module to load that class from. This means users would have to modify the org.jboss.security module's module.xml to statically declare their module as a dependency. > There should be a "module" attribute and org.jboss.security.vault.SecurityVaultFactory should expose a "get" variant that takes a ClassLoader so the appropriate module classloader can be used. > I only looked at the core model but I suspect the security subsystem has the same issue. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-449) Does not download the artifacts with Firefox.

by Davide Sottara (JIRA)

[ https://issues.jboss.org/browse/DROOLS-449?page=com.atlassian.jira.plugin... ] Davide Sottara commented on DROOLS-449: --------------------------------------- Could you please specify which artifact(s) and which repository? Thanks > Does not download the artifacts with Firefox. > ---------------------------------------------- > > Key: DROOLS-449 > URL: https://issues.jboss.org/browse/DROOLS-449 > Project: Drools > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 6.0.1.Final, 6.1.0.Beta1 > Environment: Windows 7 Professional 64 bits > JDK 1.7.45 > Firefox 25.0.1 > Reporter: Rogério Disciolli > Assignee: Mark Proctor > Labels: Firefox, artifact, download > > When try download an Artifact from repository with browser Firefox nothing does. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1808) Mac OS: no multicast route for 127.0.0.1

by Bela Ban (JIRA)

Bela Ban created JGRP-1808: ------------------------------ Summary: Mac OS: no multicast route for 127.0.0.1 Key: JGRP-1808 URL: https://issues.jboss.org/browse/JGRP-1808 Project: JGroups Issue Type: Task Reporter: Bela Ban Assignee: Bela Ban Fix For: 3.5 On Mac OS (Mavericks), there is no multicast route in the routing table. So the default route is used (say 192.168.1.1). However, this doesn't work for nodes bound to 127.0.0.1 (don't know why). So for loopback, an mcast route has to be added, e.g. {noformat} sudo route add -net 224.0.0.0/4 127.0.0.1 {noformat} This adds a default route to all class D (multicast) addresses via loopback. However, this doesn't work if the node is bound to 192.168.1.x ! TODO: * See if we can get a default multicast route through 192.168.1.1 and make nodes bound to 127.0.0.1 use it * If this doesn't work, define multiple mcast routes for different mcast addresses, e.g. {noformat} sudo route add -net 224.0.0.0/4 127.0.0.1 sudo route add -net 230.0.0.0/8 192.168.1.0 {noformat} This adds loopback as default mcast route, but uses en0 if a multicast address starts with 230.x.x.x. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1808) Mac OS: no multicast route for 127.0.0.1

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1808?page=com.atlassian.jira.plugin.... ] Bela Ban updated JGRP-1808: --------------------------- Priority: Minor (was: Major) > Mac OS: no multicast route for 127.0.0.1 > ---------------------------------------- > > Key: JGRP-1808 > URL: https://issues.jboss.org/browse/JGRP-1808 > Project: JGroups > Issue Type: Task > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Minor > Fix For: 3.5 > > > On Mac OS (Mavericks), there is no multicast route in the routing table. So the default route is used (say 192.168.1.1). However, this doesn't work for nodes bound to 127.0.0.1 (don't know why). > So for loopback, an mcast route has to be added, e.g. > {noformat} > sudo route add -net 224.0.0.0/4 127.0.0.1 > {noformat} > This adds a default route to all class D (multicast) addresses via loopback. However, this doesn't work if the node is bound to 192.168.1.x ! > TODO: > * See if we can get a default multicast route through 192.168.1.1 and make nodes bound to 127.0.0.1 use it > * If this doesn't work, define multiple mcast routes for different mcast addresses, e.g. > {noformat} > sudo route add -net 224.0.0.0/4 127.0.0.1 > sudo route add -net 230.0.0.0/8 192.168.1.0 > {noformat} > This adds loopback as default mcast route, but uses en0 if a multicast address starts with 230.x.x.x. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1807) UNICAST: skipping of seqnos

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1807?page=com.atlassian.jira.plugin.... ] Bela Ban resolved JGRP-1807. ---------------------------- Resolution: Done > UNICAST: skipping of seqnos > --------------------------- > > Key: JGRP-1807 > URL: https://issues.jboss.org/browse/JGRP-1807 > Project: JGroups > Issue Type: Bug > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 3.2.13, 3.5 > > > {noformat} > The log starts with: > 10-Mar-2014 13:21:47 WARN [org.jgroups.protocols.UNICAST2] (OOB-105,shared=tcp) AS_DR_IBE03/web: (requester=AS_DR_IBE06/web) message AS_DR_IBE06/web::1511786 not found in retransmission table of AS_DR_IBE06/web: > [1511785 | 1511785 | 1511857] (53 elements, 19 missing) > The numbers are 1511786-1511804 for "not found in retransmission...." > And end: > 10-Mar-2014 14:48:26 WARN [org.jgroups.protocols.UNICAST2] (OOB-118,shared=tcp) AS_DR_IBE03/web: (requester=AS_DR_IBE06/web) message AS_DR_IBE06/web::1511804 not found in retransmission table of AS_DR_IBE06/web: > [1511785 | 1511785 | 1514802] (2998 elements, 19 missing) > {noformat} > It seems that 03 is missing messages 1511785-1511804 which it sent to 06. Since a null message cannot be added to the sender table (due to the {{msg.isFlagSet()}} which would throw an NPE), I asume we're skipping a seqno: > In {{UNICAST}}, {{UNICAST2}} and {{UNICAST3}} {{down()}}, if a seqno is skipped, we get endless retransmissions. Example: > * We get the next seqno 1, add the message to the table and send it > * We get the next seqno 2. However, if {{running}} is false, we don't add the message > * We get the next seqno 3. Now {{running}} is true, and we add 3 to the table > --> Now we have a missing message 2 which will always be null as it hasn't been added to the table > This is highly unlikely, as I haven't been able to find a scenario where running flips from true to false to true quickly. If it flips from true to false, this is because {{stop()}} has been called. Also, in {{down()}}, we actually check {{running}} and return if false. > In this scenario, the connections are all removed, so seqno is reset to 1. > Anyway, I'm going to replace the {{while(running)}} loop with a {{do while(running)}} loop, so we always add the message to the table, even if running=false. > [1] https://github.com/belaban/JGroups/blob/Branch_JGroups_3_2/src/org/jgroup... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBEE-150) The jboss-jstl-api_1.2_spec artifact depends on xalan artifact that is not present in Maven Central

by Tomas Repel (JIRA)

[ https://issues.jboss.org/browse/JBEE-150?page=com.atlassian.jira.plugin.s... ] Tomas Repel commented on JBEE-150: ---------------------------------- [~shelly.mcgowan] Thanks for pointing me to that issues. Using that BOMs will probably help (I didn't try), but still if we push something to Maven Central, that something should depend on stuff that is available on Maven Central as well. But this issue is clearly duplicate of https://issues.jboss.org/browse/JBEE-118 (sorry for that, I haven't noticed), you can mark it so. > The jboss-jstl-api_1.2_spec artifact depends on xalan artifact that is not present in Maven Central > --------------------------------------------------------------------------------------------------- > > Key: JBEE-150 > URL: https://issues.jboss.org/browse/JBEE-150 > Project: JBoss JavaEE Spec APIs > Issue Type: Bug > Reporter: Tomas Repel > Assignee: Shelly McGowan > > The org.jboss.spec.javax.servlet.jstl:jboss-jstl-api_1.2_spec:1.1.0.Final depends on xalan:xalan:2.7.1.jbossorg-2 artifact, this one is not present in Maven Central. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 10 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 March 2014