September 2009 - jboss-jira - Jboss List Archives

[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

16 years, 10 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

16 years, 10 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

16 years, 10 months

1
0
0 / 0

[JBoss JIRA] Created: (SECURITY-436) Synchronise Library Versions with EAP 5

by Darran Lofthouse (JIRA)

Synchronise Library Versions with EAP 5 --------------------------------------- Key: SECURITY-436 URL: https://jira.jboss.org/jira/browse/SECURITY-436 Project: JBoss Security and Identity Management Issue Type: Task Security Level: Public (Everyone can see) Components: Negotiation Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: Negotiation_2.0.3.SP2 -- 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

16 years, 10 months

1
1
0 / 0

[JBoss JIRA] Commented: (JGRP-1037) Ergonomics: size thread pools dynamically

by Bela Ban (JIRA)

[ https://jira.jboss.org/jira/browse/JGRP-1037?page=com.atlassian.jira.plug... ] Bela Ban commented on JGRP-1037: -------------------------------- ConcurrentHashMap initial size, load factor and concurrency level should also be set dynamically, e.g. based on the cluster size > Ergonomics: size thread pools dynamically > ----------------------------------------- > > Key: JGRP-1037 > URL: https://jira.jboss.org/jira/browse/JGRP-1037 > Project: JGroups > Issue Type: Feature Request > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 2.9 > > > Ergonomics are a step towards less configuration and more dynamic setting of values. Example: a thread pool's min and max sizes can be dynamically changed, based on observations. When we have a min size of 10, but the thread pool is always 75, then we should set the min size to 75 and possibly change the idle time too. > This is just a first step towards ergonomics and needs to be expanded on in 3.x releases -- 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

16 years, 10 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBWEB-3) Using JAAS to affect forwarded web requests

by Remy Maucherat (JIRA)

[ https://jira.jboss.org/jira/browse/JBWEB-3?page=com.atlassian.jira.plugin... ] Remy Maucherat updated JBWEB-3: ------------------------------- Fix Version/s: JBossWeb-2.1.5.GA (was: JBossWeb-2.1.4.GA) > Using JAAS to affect forwarded web requests > ------------------------------------------- > > Key: JBWEB-3 > URL: https://jira.jboss.org/jira/browse/JBWEB-3 > Project: JBoss Web > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Core > Reporter: Scott M Stark > Assignee: Remy Maucherat > Priority: Minor > Fix For: JBossWeb-2.1.5.GA > > > As described for the following case: > http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3857340 > users commonly seem to want to be able to affect the web container security context through JAAS login and/or Subject.doAs to set/change the security context for subsequent web requests. We need to look into whether this can be supported. -- 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

16 years, 10 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBWEB-19) Make isUserInRole() and getUserPrincipal() available on unsecured pages

by Remy Maucherat (JIRA)

[ https://jira.jboss.org/jira/browse/JBWEB-19?page=com.atlassian.jira.plugi... ] Remy Maucherat updated JBWEB-19: -------------------------------- Fix Version/s: JBossWeb-2.1.5.GA (was: JBossWeb-2.1.4.GA) > Make isUserInRole() and getUserPrincipal() available on unsecured pages > ----------------------------------------------------------------------- > > Key: JBWEB-19 > URL: https://jira.jboss.org/jira/browse/JBWEB-19 > Project: JBoss Web > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Core > Environment: Any > Reporter: Jeff Schnitzer > Assignee: Remy Maucherat > Fix For: JBossWeb-2.1.5.GA > > > Currently getUserPrincipal() returns null and ServletRequest.isUserInRole() always returns false on unsecured pages, even after the user has been authenticated. > It would be much more useful if these always returned proper values. This confusion comes up on the JAAS forums frequently. -- 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

16 years, 10 months

1
0
0 / 0

[JBoss JIRA] Created: (EJBTHREE-1915) Update plugin to as-int 1.1.16 snapshots

by jaikiran pai (JIRA)

Update plugin to as-int 1.1.16 snapshots ---------------------------------------- Key: EJBTHREE-1915 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1915 Project: EJB 3.0 Issue Type: Task Reporter: jaikiran pai Assignee: jaikiran pai Fix For: Plugin 1.0.15 Move to as-int 1.1.16 SNAPSHOT -- 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

16 years, 10 months

1
1
0 / 0

[JBoss JIRA] Created: (GPD-361) analyse impact of jpdl changes on gpd

by Tom Baeyens (JIRA)

analyse impact of jpdl changes on gpd ------------------------------------- Key: GPD-361 URL: https://jira.jboss.org/jira/browse/GPD-361 Project: JBoss jBPM GPD Issue Type: Task Reporter: Tom Baeyens Assignee: Koen Aers Fix For: jBPM jPDL Designer 4.1 what type of changes can we have in jpdl that affect the gpd ? how will gpd deal with these changes ? -- 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

16 years, 10 months

2
3
0 / 0

[JBoss JIRA] Created: (JBPORTAL-2453) additional parameters for gadgets are lost when the gadgets are displayed

by Toshiya Kobayashi (JIRA)

additional parameters for gadgets are lost when the gadgets are displayed ------------------------------------------------------------------------- Key: JBPORTAL-2453 URL: https://jira.jboss.org/jira/browse/JBPORTAL-2453 Project: JBoss Portal Issue Type: Bug Security Level: Public (Everyone can see) Components: Portal Widget Affects Versions: 2.7.2 Final, 2.7.0 Final, 2.7.1 Final Reporter: Toshiya Kobayashi Assignee: Magesh Kumar B There are some gadgets which require additional parameters when you add the gadget to your dashboard. For instance, these gadgets of Google Apps for hosted domain: url=http://hosting.gmodules.com/ig/gadgets/file/117808631063490062819/hos... url=http://hosting.gmodules.com/ig/gadgets/file/117808631063490062819/hos... url=http://hosting.gmodules.com/ig/gadgets/file/117808631063490062819/hos... But the values of the parameters which you have input will be lost when those gadgets are displayed. ## script tags that jboss-portal-2.7.2 generates ## <script src="http://gmodules.com/ig/ifr?url=http://hosting.gmodules.com/ig/gadgets/fil..."></script> <script src="http://gmodules.com/ig/ifr?url=http://hosting.gmodules.com/ig/gadgets/fil..."></script> <script src="http://gmodules.com/ig/ifr?url=http://hosting.gmodules.com/ig/gadgets/fil..."></script> ## script tags that jboss-portal-2.6.6 generates ## <script src="http://gmodules.com/ig/ifr?url=http://hosting.gmodules.com/ig/gadgets/fil..."></script> <script src="http://gmodules.com/ig/ifr?url=http://hosting.gmodules.com/ig/gadgets/fil..."></script> <script src="http://gmodules.com/ig/ifr?url=http://hosting.gmodules.com/ig/gadgets/fil..."></script> Note: In order to reproduce it, first, you should fix org.jboss.portal.widget.google.provider.GGWidgetInfoBuilder in jboss-portal in the same way as JBEPP-109. https://jira.jboss.org/jira/browse/JBEPP-109 If you want to reproduce it easily, use epp-4.3.0.GA CP02 to which JBEPP-109 has been already applyed. As you see, script tags which jboss-portal-2.7.2 generates don't have parameters which you have input (e.g. up_Domain). Those values seem to be stored in JBP_PORTAL_OBJECT_PROPS table. Checked versions: NG : 2.7.2, 2.7.1, 2.7.0, epp-4.3.0.GA CP02 OK : 2.6.8, 2.6.6 This problem seems to be introduced from 2.7.x -- 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

16 years, 10 months

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