September 2010 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JGRP-1237) Remove print stacktrace from Tunnel warning when backup gossip router is not available

by vivek v (JIRA)

Remove print stacktrace from Tunnel warning when backup gossip router is not available --------------------------------------------------------------------------------------- Key: JGRP-1237 URL: https://jira.jboss.org/browse/JGRP-1237 Project: JGroups Issue Type: Bug Affects Versions: 2.10 Environment: Linux, JGroups 2.10 GA Reporter: vivek v Assignee: Bela Ban This is the issue with JGroups 2.10 GA when using Tunnel with multiple Gossip Routers. In our case the nodes start sequentially. Two of the nodes have Gossip Router running. As each node is configured to talk to two GR via Tunnel, the first one starting always throws a big stacktrace when not able to connect to the second GR. We don't need to print the stacktrace when failed to connect to other GRs - we can simply put the warning with stacktrace. File: Tunnel.java Line: 421 (inside connect method) {noformat} catch (Exception e) { if (log.isWarnEnabled()) log.warn("Failed connecting to GossipRouter at " + stub.getGossipRouterAddress()); //no stacktrace stubManager.startReconnecting(stub); } {noformat} -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 9 months

2
3
0 / 0

[JBoss JIRA] Created: (HIBERNATE-123) Cannot install hibernate tool in eclipse Helios because of conflicting dependency.

by Alexis Morillo (JIRA)

Cannot install hibernate tool in eclipse Helios because of conflicting dependency. ---------------------------------------------------------------------------------- Key: HIBERNATE-123 URL: https://jira.jboss.org/browse/HIBERNATE-123 Project: Hibernate Integration Issue Type: Bug Environment: Eclipse Java EE IDE for Web Developers (Helios Release, Build id: 20100617-1415) Jboss Update site : http://download.jboss.org/jbosstools/updates/JBossTools-3.1.1.GA Reporter: Alexis Morillo Assignee: Steve Ebersole Get the error message : Cannot complete the install because of a conflicting dependency. Software being installed: Hibernate Tools 3.3.1.v201006011046R-H111-GA (org.hibernate.eclipse.feature.feature.group 3.3.1.v201006011046R-H111-GA) Software currently installed: Eclipse IDE for Java EE Developers 1.3.0.20100617-0521 (epp.package.jee 1.3.0.20100617-0521) Only one of the following can be installed at once: JavaServer Faces Tools - Common UI 1.2.0.v20100329 (org.eclipse.jst.jsf.common.ui 1.2.0.v20100329) JavaServer Faces Tools - Common UI 1.1.1.v20081209 (org.eclipse.jst.jsf.common.ui 1.1.1.v20081209) Only one of the following can be installed at once: Common Frameworks 1.2.0.v201003040800 (org.eclipse.wst.common.frameworks 1.2.0.v201003040800) Common Frameworks 1.1.300.v200904160730 (org.eclipse.wst.common.frameworks 1.1.300.v200904160730) Cannot satisfy dependency: From: Eclipse IDE for Java EE Developers 1.3.0.20100617-0521 (epp.package.jee 1.3.0.20100617-0521) To: org.eclipse.epp.package.jee.feature.feature.group [1.3.0.20100617-0521] Cannot satisfy dependency: From: Java EE IDE Feature 1.3.0.20100617-0521 (org.eclipse.epp.package.jee.feature.feature.group 1.3.0.20100617-0521) To: org.eclipse.jsf.feature.feature.group 0.0.0 Cannot satisfy dependency: From: Java EE IDE Feature 1.3.0.20100617-0521 (org.eclipse.epp.package.jee.feature.feature.group 1.3.0.20100617-0521) To: org.eclipse.jst.web_ui.feature.feature.group 0.0.0 Cannot satisfy dependency: From: Dali Java Persistence Tools - Core 2.2.1.v200908270220 (org.eclipse.jpt.core 2.2.1.v200908270220) To: bundle org.eclipse.wst.common.frameworks [1.1.200,1.2.0) Cannot satisfy dependency: From: JavaServer Faces Tools (JSF) Project 3.2.0.v20100526-7E7I-F9JgLWLMBYy3114 (org.eclipse.jsf.feature.feature.group 3.2.0.v20100526-7E7I-F9JgLWLMBYy3114) To: org.eclipse.jst.jsf.common.ui [1.2.0.v20100329] Cannot satisfy dependency: From: Common JST UI Plug-in 1.0.0.v201005270700 (org.eclipse.jst.common.ui 1.0.0.v201005270700) To: bundle org.eclipse.wst.common.frameworks 1.2.0 Cannot satisfy dependency: From: JST Web UI 3.1.1.v200908121609-7E77FBfDlwYa_9sdy2q77doi14gl (org.eclipse.jst.web_ui.feature.feature.group 3.1.1.v200908121609-7E77FBfDlwYa_9sdy2q77doi14gl) To: org.eclipse.jst.jsf.common.ui [1.1.1.v20081209] Cannot satisfy dependency: From: JST Web UI 3.1.1.v200908121609-7E77FBiDlwYcICNdz-5z-9PGqZCy (org.eclipse.jst.web_ui.feature.feature.group 3.1.1.v200908121609-7E77FBiDlwYcICNdz-5z-9PGqZCy) To: org.eclipse.jst.jsf.common.ui [1.1.1.v20081209] Cannot satisfy dependency: From: JST Web UI 3.2.0.v201005250611-7F77FJJC25Skdw1pheuO_q6p-Idh (org.eclipse.jst.web_ui.feature.feature.group 3.2.0.v201005250611-7F77FJJC25Skdw1pheuO_q6p-Idh) To: org.eclipse.jst.common.ui [1.0.0.v201005270700] Cannot satisfy dependency: From: Hibernate Tools 3.3.1.v201006011046R-H111-GA (org.hibernate.eclipse.feature.feature.group 3.3.1.v201006011046R-H111-GA) To: org.jboss.tools.hibernate.jpt.core [3.3.1.v201006011046R-H111-GA] Cannot satisfy dependency: From: Hibernate Jdt Core 3.3.1.v201006011046R-H111-GA (org.jboss.tools.hibernate.jpt.core 3.3.1.v201006011046R-H111-GA) To: bundle org.eclipse.jpt.core [2.2.0,2.2.2) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 9 months

2
4
0 / 0

[JBoss JIRA] Created: (JBAS-4435) WebAppClassLoader.getResource() fails when the war is deployed as part of an ear

by Thomas Diesler (JIRA)

WebAppClassLoader.getResource() fails when the war is deployed as part of an ear -------------------------------------------------------------------------------- Key: JBAS-4435 URL: http://jira.jboss.com/jira/browse/JBAS-4435 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: ClassLoading Reporter: Thomas Diesler Assigned To: Scott M Stark For some reason WebAppClassLoader.getResource("WEB-INF/wsdl/TestEndpoint.wsdl") fails when the war is deployed as part of an ear deployment. I use this workaround in static class VirtualFileClassLoader extends ClassLoader { private UnifiedVirtualFile vFile; public VirtualFileClassLoader(UnifiedVirtualFile file, ClassLoader parent) { super(parent); vFile = file; } @Override public URL getResource(String name) { URL url = super.getResource(name); if (url == null) { try { url = vFile.findChild(name).toURL(); } catch (IOException e) { // ignore } } return url; } } -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 9 months

1
1
0 / 0

[JBoss JIRA] Created: (JBAS-3970) NPE in JBossTestCase

by Thomas Diesler (JIRA)

NPE in JBossTestCase -------------------- Key: JBAS-3970 URL: http://jira.jboss.com/jira/browse/JBAS-3970 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Test Suite Reporter: Thomas Diesler Assigned To: Scott M Stark getServerHost() throws a NPE, because the delegate is not initialized before setUp() is called public class SimpleJSETestCase extends JBossTestCase { private String WSDL_LOCATION = "http://" + getServerHost() + ":8080/ws4ee-simple?wsdl"; private String NAMESPACE = "http://test.jboss.org/ws4eesimple"; private QName SERVICE_NAME = new QName(NAMESPACE, "HelloService"); .... } This is quite common in the webservice test suite -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 9 months

2
1
0 / 0

[JBoss JIRA] Created: (JGRP-1233) TCPPING fails to connect with different server because sender thread is interrupted too soon?

by Karthik Abram (JIRA)

TCPPING fails to connect with different server because sender thread is interrupted too soon? --------------------------------------------------------------------------------------------- Key: JGRP-1233 URL: https://jira.jboss.org/browse/JGRP-1233 Project: JGroups Issue Type: Bug Affects Versions: 2.10 Reporter: Karthik Abram Assignee: Bela Ban The configuration file I'm using is in the comment below. The log output is below that. The system works just fine if I run two instances of the program on the same machine. However, when I run it on different machines (only 1 port is open between them), I see connection-established, and then I get this in the log: TRACE TCPConnectionMap$TCPConnection - TCPConnection.Sender thread terminated at 0.0.0.0:9043 Looking at the code, it seems the sender thread gets interrupted before it gets data from the other program? We cannot using MPING for discovery in our environment and this is a major issue for us. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 9 months

2
13
0 / 0

[JBoss JIRA] Created: (JBWEB-180) Make JSP DEFAULT_BUFFER_SIZE configurable by system property

by James Livingston (JIRA)

Make JSP DEFAULT_BUFFER_SIZE configurable by system property ------------------------------------------------------------ Key: JBWEB-180 URL: https://jira.jboss.org/browse/JBWEB-180 Project: JBoss Web Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Tomcat Affects Versions: JBossWeb-3.0.0.Beta6, JBossWeb-2.1.8.GA Reporter: James Livingston Assignee: Remy Maucherat Many of the other options in org.apache.jasper.Constants are configurable via system properties, and it would be nice if DEFAULT_BUFFER_SIZE was too, so you didn't have to add <%@page buffer="..."%> to each individual page. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 9 months

2
2
0 / 0

[JBoss JIRA] Created: (JGRP-1181) PING messages to entire cluster limit scalability.

by Jonathan Oddy (JIRA)

PING messages to entire cluster limit scalability. -------------------------------------------------- Key: JGRP-1181 URL: https://jira.jboss.org/jira/browse/JGRP-1181 Project: JGroups Issue Type: Feature Request Reporter: Jonathan Oddy Assignee: Bela Ban PING messages generate a response from every node that receives them. In a large cluster this will lead to a large number of responses needing to be processed. Making PINGs target-able (e.g. ping to only coordinators, ping to anyone with a view not matching ViewID N) could significantly reduce the number of nodes responding to a request. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 9 months

2
8
0 / 0

[JBoss JIRA] Created: (JGRP-1049) Concurrent hashmaps: set parameters via system properties

by Bela Ban (JIRA)

Concurrent hashmaps: set parameters via system properties --------------------------------------------------------- Key: JGRP-1049 URL: https://jira.jboss.org/jira/browse/JGRP-1049 Project: JGroups Issue Type: Feature Request Reporter: Bela Ban Assignee: Bela Ban Fix For: 2.9 ConcurrentHashMap ----------------- CCHMs have a default initial capacity (16), load factor (0.75) and concurrency level (16). These are OK for most scenarios, but we have to investigate whether these values are sufficient for 1000 node clusters. When for example 1000 threads from different senders access the same CCHM, we need to make sure we don't have high contention, ie. by spreading a 1000 senders over 16 buckets. Investigate whether we should add CCHM initial sizes, load factors and concurrency levels as system properties. With ergonomics [1], we could for example set bucket sizes for CCHMs dynamically, e.g. based on cluster size. [1] https://jira.jboss.org/jira/browse/JGRP-1037 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 9 months

1
3
0 / 0

[JBoss JIRA] Created: (JBAS-8244) Fix org.jboss.test.ws.jaxws.ejb3Integration.WebServiceTestCase

by Brian Stansberry (JIRA)

Fix org.jboss.test.ws.jaxws.ejb3Integration.WebServiceTestCase -------------------------------------------------------------- Key: JBAS-8244 URL: https://jira.jboss.org/browse/JBAS-8244 Project: JBoss Application Server Issue Type: Sub-task Security Level: Public (Everyone can see) Components: Test Suite, Web Services Reporter: Brian Stansberry Fix For: 6.0.0.Final http://hudson.qa.jboss.com/hudson/view/JBoss%20AS/job/JBoss-AS-6.0.x-test... -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 9 months

4
4
0 / 0

[JBoss JIRA] Created: (EJBTHREE-2151) Global interceptor in ejb-jar.xml ignores @Asynchronous

by Juergen Zimmermann (JIRA)

Global interceptor in ejb-jar.xml ignores @Asynchronous ------------------------------------------------------- Key: EJBTHREE-2151 URL: https://jira.jboss.org/browse/EJBTHREE-2151 Project: EJB 3.0 Issue Type: Bug Environment: JBossAS 6.0.0.M4 Reporter: Juergen Zimmermann In ejb-jar.xml I'm having a global interceptor (it's for logging all public methods of an EJB during the development phase). However, when I annotate a method using @Asynchronous, the annotated public method is just ignored. There is no stacktrace or anything else in the log file. Declaration in ejb-jar.xml: <ejb-jar ...version="3.1"> ... <assembly-descriptor> <interceptor-binding> <ejb-name>*</ejb-name> <interceptor-class> de.hska.util.LoggingInterceptor </interceptor-class> </interceptor-binding> -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 9 months

2
5
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira September 2010