September 2009 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBREM-1149) Do not include samples in the JAR

by Ondrej Medek (JIRA)

Do not include samples in the JAR --------------------------------- Key: JBREM-1149 URL: https://jira.jboss.org/jira/browse/JBREM-1149 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Environment: JBoss AS 5.1.0GA Reporter: Ondrej Medek Priority: Minor We have a Java swing application using session beans. We have to distribute jboss-remoting.jar (1,14MB) to our clients. I have found that when I delete samples from the jboss-remoting.jar, it has only 0,86MB. It saves some download time for our clients behind a thin line. Please, remove the samples and all not-necessary code from the jboss-remoting.jar. -- 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

14 years, 8 months

2
5
0 / 0

[JBoss JIRA] Created: (JBPORTAL-2455) DTD for Theme Descriptors

by Fernando Ribeiro (JIRA)

DTD for Theme Descriptors ------------------------- Key: JBPORTAL-2455 URL: https://jira.jboss.org/jira/browse/JBPORTAL-2455 Project: JBoss Portal Issue Type: Feature Request Security Level: Public (Everyone can see) Affects Versions: 2.7.2 Final Reporter: Fernando Ribeiro Like other descriptors, theme descriptors should have a DTD included in the product. -- 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

14 years, 8 months

1
0
0 / 0

[JBoss JIRA] Created: (JBREM-1151) Correct dependency discussion in Chapter 4 of Remoting Guide

by Ron Sigal (JIRA)

Correct dependency discussion in Chapter 4 of Remoting Guide ------------------------------------------------------------ Key: JBREM-1151 URL: https://jira.jboss.org/jira/browse/JBREM-1151 Project: JBoss Remoting Issue Type: Task Security Level: Public (Everyone can see) Affects Versions: 2.2.3, 2.5.1 (Flounder) Reporter: Ron Sigal Assignee: Ron Sigal Fix For: 2.5.2 (Flounder), 2.2.3.SP1 The discussion is misleading and possibly incorrect. -- 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

14 years, 8 months

1
1
0 / 0

[JBoss JIRA] Created: (JBREM-1152) If MicroSocketClientInvoker gets a SocketException in getConnection(), it should retry

by Ron Sigal (JIRA)

If MicroSocketClientInvoker gets a SocketException in getConnection(), it should retry -------------------------------------------------------------------------------------- Key: JBREM-1152 URL: https://jira.jboss.org/jira/browse/JBREM-1152 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.2.3, 2.5.1 (Flounder) Reporter: Ron Sigal Assignee: Ron Sigal Fix For: 2.5.2 (Flounder), 2.2.3.SP1 If a SocketException is thrown in the main loop in org.jboss.remoting.transport.socket.MicroSocketClientInvoker.transport(), the invocation will be retried (if "numberOfCallRetries" is set to a value > 1). The same should apply if a SocketConnection is thrown in the preliminary attempt to create a socket. This issue is particularly relevant to the bisocket transport, where the attempt by a callback client to create a socket involves a write on the control connection. -- 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

14 years, 8 months

1
6
0 / 0

[JBoss JIRA] Closed: (JBAS-7032) Getting invalid deployment on what appears to be valid, a webbeans ear file.

by Jason T. Greene (JIRA)

[ https://jira.jboss.org/jira/browse/JBAS-7032?page=com.atlassian.jira.plug... ] Jason T. Greene closed JBAS-7032. --------------------------------- Resolution: Done EAR isolation is now on by default, so this should be resolved. > Getting invalid deployment on what appears to be valid, a webbeans ear file. > ---------------------------------------------------------------------------- > > Key: JBAS-7032 > URL: https://jira.jboss.org/jira/browse/JBAS-7032 > Project: JBoss Application Server > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Deployers > Environment: JBoss AS 5.1 > JDK 1.6 u 13 > OpenSuSe 11.1 / SLES 10.2 > Reporter: John Ament > Assignee: Shelly McGowan > Fix For: JBossAS-5.2.0.Beta1 > > Attachments: jboss-app.xml, PrintResourcePathContextListener.class, PrintResourcePathContextListener.java, WhatUpDawg.ear, WhatUpDawg.ear > > > The best description I can give is from the forum. > Basically, I have an EAR that appears to be completely valid, it's 2 war's and 1 ejb module. It's built using web beans. I get the described stack trace when either deploying via the UI or just dropping the EAR file in deploy. However, I get different results. When I drop the ear in and restart, it loads perfectly (my app) but embedded jopr fails. -- 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

14 years, 8 months

1
0
0 / 0

[JBoss JIRA] Created: (JBAS-7143) Upgrade AS 5.2 to JSF 2.0.0-Beta2

by Stan Silvert (JIRA)

Upgrade AS 5.2 to JSF 2.0.0-Beta2 --------------------------------- Key: JBAS-7143 URL: https://jira.jboss.org/jira/browse/JBAS-7143 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Components: JSF Affects Versions: JBossAS-5.1.0.GA Reporter: Stan Silvert Assignee: Stan Silvert Fix For: JBossAS-5.2.0.Beta1 Upgrade AS 5.2 to JSF 2.0.0-Beta2 -- 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

14 years, 8 months

3
3
0 / 0

[JBoss JIRA] Created: (JBAS-7217) Upgrade JSF to 2.0.0-RC

by Stan Silvert (JIRA)

Upgrade JSF to 2.0.0-RC ----------------------- Key: JBAS-7217 URL: https://jira.jboss.org/jira/browse/JBAS-7217 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Affects Versions: JBossAS-5.2.0.Beta1, JBossAS-6.0.0.Alpha1 Reporter: Stan Silvert Assignee: Stan Silvert Fix For: JBossAS-5.2.0.Beta1, JBossAS-6.0.0.Alpha1 -- 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

14 years, 8 months

3
6
0 / 0

[JBoss JIRA] Created: (JBAS-7227) too many vhost MBeans deployed for the root context path

by John Mazzitelli (JIRA)

too many vhost MBeans deployed for the root context path -------------------------------------------------------- Key: JBAS-7227 URL: https://jira.jboss.org/jira/browse/JBAS-7227 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: JBossAS-4.2.3.GA Reporter: John Mazzitelli See the two attachments. The first is a text war - deploy it to the /deploy directory of a stock JBossAS distro. Start the server. (i tested on 4.2.3.GA) The second attachment is the JMX console for this server with the war deployed. JBossAS deploys MBeans for each vhost and context-path pair in this pattern (these are the MBean ObjectNames): jboss.web:host=<hostname>,path=<context-path>,type=Manager Look at the attached JMX console html and you will see three of them (I see this too on my box): jboss.web:host=snert.home.bsd.de,path=/,type=Manager jboss.web:host=snert.home.pilhuhn.de,path=/,type=Manager jboss.web:host=localhost,path=/,type=Manager The first two show vhosts that are only defined in the test .war. But the context root of "/" is only defined in ROOT.war. I believe there should only be one MBean here where path=/ - that being the one where host=localhost. But with these three MBeans, this tells me that JBoss is telling us that the context-path of "/" (of which ROOT.war will be handling) is on three vhosts (the three host= values). That does not seem to be correct. This affects Jopr because we now think there are three ROOT.war contexts - one per vhost. But two of those vhosts are only valid for the test.war See http://jira.rhq-project.org/browse/RHQ-2404 for how this affects Jopr/RHQ. -- 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

14 years, 8 months

2
3
0 / 0

[JBoss JIRA] Created: (JGRP-1034) NAKACK: backport from head

by Bela Ban (JIRA)

NAKACK: backport from head -------------------------- Key: JGRP-1034 URL: https://jira.jboss.org/jira/browse/JGRP-1034 Project: JGroups Issue Type: Task Reporter: Bela Ban Assignee: Bela Ban Fix For: 2.6.13 Brian needs the CAS stuff; the HTTP perf tests showed a heavy number of threads queued up for the same lock -- 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

14 years, 8 months

1
1
0 / 0

[JBoss JIRA] Commented: (JGRP-155) TP.loopback should always be used

by Bela Ban (JIRA)

[ https://jira.jboss.org/jira/browse/JGRP-155?page=com.atlassian.jira.plugi... ] Bela Ban commented on JGRP-155: ------------------------------- enabling loopback="true" degrades performance, possibly because of the additional work to be handled by the thread pool > TP.loopback should always be used > --------------------------------- > > Key: JGRP-155 > URL: https://jira.jboss.org/jira/browse/JGRP-155 > Project: JGroups > Issue Type: Task > Affects Versions: 2.2.8, 2.2.9 > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 3.x > > > Investigate the 3 potential problem areas below: > - Memory leak caused by FC when credits are received too quickly > - Deadlocks caused by same threads calling themselves (e.g. VIEW_OK ack msgs) > - Preemption doesn't work: Scheduler is meaningless here -- 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

14 years, 8 months

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 September 2009