November 2008 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBBOOT-2) Apply changes from AS "bootstrap" module to Bootstrap Project

by Andrew Lee Rubinger (JIRA)

Apply changes from AS "bootstrap" module to Bootstrap Project ------------------------------------------------------------- Key: JBBOOT-2 URL: https://jira.jboss.org/jira/browse/JBBOOT-2 Project: JBoss Bootstrap Issue Type: Task Reporter: Andrew Lee Rubinger Assignee: Andrew Lee Rubinger Fix For: 0.1.0 Changes have been made into the AS "bootstrap" module since it was broken out into its own project in r80819. As the project is still an (unusued) fork, reconcile with current revision: 81177. -- 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

17 years, 8 months

1
2
0 / 0

[JBoss JIRA] Created: (JBAS-6205) Make server.log logging level configurable via system property

by Brian Stansberry (JIRA)

Make server.log logging level configurable via system property -------------------------------------------------------------- Key: JBAS-6205 URL: https://jira.jboss.org/jira/browse/JBAS-6205 Project: JBoss Application Server Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Logging Reporter: Brian Stansberry Assignee: Brian Stansberry Fix For: JBossAS-5.0.0.GA Add <param name="Threshold" value="${jboss.server.log.level}"/> to the FILE appender config in jboss-log4j.xml. Log4j performs a system property substitution (see org.apache.log4j.xml.DomConfigurator.subst()). It doesn't seem to support our default value syntax, e.g. {jboss.server.log.level:DEBUG}, but starting the AS w/o setting the system property results in DEBUG logging. If we want a default other than DEBUG (or don't like counting on log4j to use DEBUG if the property isn't set), we can check the system property in Log4jService and set it if not set. -- 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

17 years, 8 months

1
3
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-1454) Libaio Native Layer would crash on close if it failed opening a file

by Clebert Suconic (JIRA)

Libaio Native Layer would crash on close if it failed opening a file -------------------------------------------------------------------- Key: JBMESSAGING-1454 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1454 Project: JBoss Messaging Issue Type: Bug Affects Versions: 2.0.0 Alpha Reporter: Clebert Suconic Assignee: Clebert Suconic Fix For: 2.0.0 Beta -- 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

17 years, 8 months

1
2
0 / 0

[JBoss JIRA] Created: (HIBERNATE-108) support hibernate.hbm2ddl.auto for WAS JTA enabled environment

by Peter Kovgan (JIRA)

support hibernate.hbm2ddl.auto for WAS JTA enabled environment -------------------------------------------------------------- Key: HIBERNATE-108 URL: https://jira.jboss.org/jira/browse/HIBERNATE-108 Project: Hibernate Issue Type: Feature Request Environment: WAS 6.1, websphere 6.1, IBM VM, Windows XP Reporter: Peter Kovgan Assignee: Steve Ebersole ERROR SchemaExport - Unsuccessful: create sequence hibernate_sequence ERROR SchemaExport - ORA-02089: COMMIT is not allowed in a subordinate session in JTA supported environment hibernate.hbm2ddl.auto=create fails to work. Probably schema creation attempt made out of global transaction scope. -- 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

17 years, 8 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.2.GA (was: JBossWeb-2.1.1.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.2.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

17 years, 8 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.2.GA (was: JBossWeb-2.1.1.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.2.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

17 years, 8 months

1
0
0 / 0

[JBoss JIRA] Created: (JBAS-6161) Two ears with a same named jar fails to deploy

by Carlo de Wolf (JIRA)

Two ears with a same named jar fails to deploy ---------------------------------------------- Key: JBAS-6161 URL: https://jira.jboss.org/jira/browse/JBAS-6161 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: EJB3 Reporter: Carlo de Wolf Assignee: Carlo de Wolf Priority: Critical Fix For: JBossAS-5.0.0.GA -- 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

17 years, 8 months

1
1
0 / 0

[JBoss JIRA] Created: (JBDEPLOY-131) Create jboss-scanning.xml and its ScanningMetaData

by Ales Justin (JIRA)

Create jboss-scanning.xml and its ScanningMetaData -------------------------------------------------- Key: JBDEPLOY-131 URL: https://jira.jboss.org/jira/browse/JBDEPLOY-131 Project: JBoss Deployers Issue Type: Feature Request Components: deployer Affects Versions: JBDEPLOY-2.0.0.CR5 Reporter: Ales Justin Assignee: Ales Justin Priority: Minor Fix For: JBDEPLOY-2.0.0.GA We should allow for declarative annotation scanning information. e.g. META-INF/jboss-scanning.xml --> ScanningMetaData Depending on this info, AnnotationEnvironmentDeployer should decide whether to scan at all, or delegate proper filtering to Module. -- 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

17 years, 8 months

1
1
0 / 0

[JBoss JIRA] Created: (JGRP-863) GroupRequest: only remove don't add members on view changes

by Bela Ban (JIRA)

GroupRequest: only remove don't add members on view changes ----------------------------------------------------------- Key: JGRP-863 URL: https://jira.jboss.org/jira/browse/JGRP-863 Project: JGroups Issue Type: Bug Reporter: Bela Ban Assignee: Bela Ban Fix For: 2.6.7, 2.7 When we have cluster {A,B,C} and invoke an RPC (via RpcDispatcher), then the target membership will be {A,B,C} and we block until we have responses from A, B and C (or a timeout). If the timeout is 0 (= wait forever), and we created a GroupRequest in MessageDispatcher.castMessage() (called from RpcDispatcher.callRemoteMethods()), then the request is sent down the stack. If just at this moment - after the request was sent, but before we received all responses - a new member D joined and we get {A,B,C,D}, then the expected responses hashmap in GroupRequest is modified and D *added*. This means, we will wait for D's response although it never actually received the request, resulting in a block ! SOLUTION: view changes can only *remove* but not *add* elements in the GroupRequest's hashmap, e.g. if B left while waiting for responses, then B's entry would be removed (or marked as 'received' or 'suspected', TBD). Another thing to look into is whether we want to ship the target destination list with a request and have members drop the request if they are not part of that list. One could argue that this should only be done at the caller's side -- 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

17 years, 8 months

1
8
0 / 0

[JBoss JIRA] Moved: (GPD-273) CLONE -Wizard uses inconsistent label compared to rest of eclipse wizards

by Koen Aers (JIRA)

[ https://jira.jboss.org/jira/browse/GPD-273?page=com.atlassian.jira.plugin... ] Koen Aers moved JBIDE-3203 to GPD-273: -------------------------------------- Project: JBoss jBPM GPD (was: Tools (JBoss Tools)) Key: GPD-273 (was: JBIDE-3203) Component/s: jpdl (was: jbpm) Fix Version/s: jBPM jPDL Designer 3.1.6 (was: 3.0.0.cr1) Affects Version/s: jBPM jPDL Designer 3.1.5 (was: 2.0.0.GA) > CLONE -Wizard uses inconsistent label compared to rest of eclipse wizards > ------------------------------------------------------------------------- > > Key: GPD-273 > URL: https://jira.jboss.org/jira/browse/GPD-273 > Project: JBoss jBPM GPD > Issue Type: Bug > Components: jpdl > Affects Versions: jBPM jPDL Designer 3.1.5 > Reporter: Koen Aers > Assignee: Koen Aers > Priority: Minor > Fix For: jBPM jPDL Designer 3.1.6 > > > Wizard 'New Page Flow' contains an instruction preceding input fields. That's not bad though sounds rather redundant, but other wizards do not have such an instruction, which creates unnecessary difference in style. > 'Choose a source folder and enter a file name.' Just below this instruction are inputs 'Source folder' and 'Enter file name' (and why not just 'File name'?). -- 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

17 years, 8 months

1
0
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 November 2008