March 2007 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBPORTAL-1038) Allow export of database to xml

by William DeCoste (JIRA)

Allow export of database to xml ------------------------------- Key: JBPORTAL-1038 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1038 Project: JBoss Portal Issue Type: Feature Request Security Level: Public (Everyone can see) Affects Versions: 2.4 Final Reporter: William DeCoste Priority: Minor This feature was requested by Intuit. -- 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

18 years, 6 months

2
2
0 / 0

[JBoss JIRA] Created: (JBAS-4059) JBoss5 RARDeployer deploys RAR's twice

by Weston Price (JIRA)

JBoss5 RARDeployer deploys RAR's twice -------------------------------------- Key: JBAS-4059 URL: http://jira.jboss.com/jira/browse/JBAS-4059 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: JCA service Affects Versions: JBossAS-5.0.0.Beta1 Reporter: Weston Price Assigned To: Weston Price Fix For: JBossAS-5.0.0.Beta2 Because of the new deployment structure in JBoss5, the RAR deployer is now deploying RAR's twice. I assume this has to do with the RARDeployer using a deprecated API of the DeploymentUnit. As a result, the JMX console records deployments such as: # name='jboss-ha-local-jdbc.rar#jboss-ha-local-jdbc.rar',service=RARDeployment # name='jboss-ha-local-jdbc.rar',service=RARDeployment This is causing issues with programmatic deployment, as well as the new metadata repository. -- 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

18 years, 7 months

2
1
0 / 0

[JBoss JIRA] Created: (JBREM-687) allow binding to 0.0.0.0

by Tom Elrod (JIRA)

allow binding to 0.0.0.0 ------------------------ Key: JBREM-687 URL: http://jira.jboss.com/jira/browse/JBREM-687 Project: JBoss Remoting Issue Type: Task Security Level: Public (Everyone can see) Components: transport Affects Versions: 1.4.6.GA, 2.0.0.GA (Boon) Reporter: Tom Elrod Assigned To: Tom Elrod Fix For: 2.2.0.Beta2 (Boon) Need to be able to really bind to 0.0.0.0. Currently, remoting will swap out 0.0.0.0 with local host name or address. Although this is about only way to be able to provide an invoker locator url that can be used by anyone else externally, means that only one network interface can ever be used. For things such as JNDI, may want to use all interfaces and need to add back in ability to do 0.0.0.0 binding. -- 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

18 years, 7 months

2
9
0 / 0

[JBoss JIRA] Created: (JBCACHE-751) ignoreModifications cache loader flag to be extended to all cache loaders, not just ones configured in a chaining cache loader

by Manik Surtani (JIRA)

ignoreModifications cache loader flag to be extended to all cache loaders, not just ones configured in a chaining cache loader ------------------------------------------------------------------------------------------------------------------------------ Key: JBCACHE-751 URL: http://jira.jboss.com/jira/browse/JBCACHE-751 Project: JBoss Cache Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Cache loaders Affects Versions: 1.4.0, 1.3.0 Reporter: Manik Surtani Assigned To: Manik Surtani Fix For: 2.1.0 -- 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

18 years, 7 months

2
2
0 / 0

[JBoss JIRA] Created: (JBCACHE-957) Allow per-node configuration of LockParentForChildInsertRemove

by Brian Stansberry (JIRA)

Allow per-node configuration of LockParentForChildInsertRemove -------------------------------------------------------------- Key: JBCACHE-957 URL: http://jira.jboss.com/jira/browse/JBCACHE-957 Project: JBoss Cache Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: Brian Stansberry Assigned To: Manik Surtani Fix For: 2.0.0.BETA2 Use the new LockParentForChildInsertRemove as a global default that sets a per-node behavior. Expose an API in Node (not NodeSPI) that allows the application to change the behavior for an individual node. Use case: session replication, which stores data in a structure like this: /SESSION/webapp/session1/.../... /SESSION/webapp/session2/.../... The session managment layer wants the greater correctness that comes with enforcing LockParentForChildInsertRemove="true" with the sessionX node and below. But requiring a WL on /SESSION/webapp before any session could be added or removed will greatly disrupt session creation and expiration. This feature allows the best of both worlds, by allowing the application to set LockParentForChildInsertRemove="false" on /SESSION and /SESSION/webapp. This is a simple alternative to lock striping in the node's children map. -- 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

18 years, 7 months

4
8
0 / 0

[JBoss JIRA] Created: (JBCACHE-910) TreeCache.createSubtreeRootNode(Fqn subtree) ugliness

by Elias Ross (JIRA)

TreeCache.createSubtreeRootNode(Fqn subtree) ugliness ----------------------------------------------------- Key: JBCACHE-910 URL: http://jira.jboss.com/jira/browse/JBCACHE-910 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Reporter: Elias Ross Assigned To: Manik Surtani This method is called by the region manager. There's a bunch of Voodoo taking place here, legacy bits mixed with some newer stuff. One thing that strikes me as wrong already is this code: child = factory.createDataNode(type, name, subtree.getFqnChild(i + 1), parent, lock_table, coordinator, null, this.rootSpi); For some reason, it is passing the lock_table into the Node as the data to initialize the node with. Somehow I think the right way to fix this would be to do a Cache.addChild(Fqn) call in RegionManager and remove this method. -- 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

18 years, 7 months

4
7
0 / 0

[JBoss JIRA] Created: (JBAS-3441) Request to include log4j version 1.2.13 in next JBoss AS release

by Khiem Tang (JIRA)

Request to include log4j version 1.2.13 in next JBoss AS release ---------------------------------------------------------------- Key: JBAS-3441 URL: http://jira.jboss.com/jira/browse/JBAS-3441 Project: JBoss Application Server Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Logging Affects Versions: JBossAS-4.0.4.GA Environment: All OS's. Reporter: Khiem Tang Assigned To: Scott M Stark We have one component that depends on log4j-1.2.13 but the one that ships with JBoss is older. We currently use this log4j version in our JBoss stack and it seems to work fine. It would help us if JBoss put the same version (1.2.13) in the packages. -- 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

18 years, 7 months

2
1
0 / 0

[JBoss JIRA] Created: (SECURITY-36) SASL Authentication

by Michael Barker (JIRA)

SASL Authentication ------------------- Key: SECURITY-36 URL: http://jira.jboss.com/jira/browse/SECURITY-36 Project: JBoss Security and Identity Management Issue Type: Patch Security Level: Public (Everyone can see) Components: JBossSX Environment: JBossAS: 4.0 Reporter: Michael Barker Assigned To: Anil Saldhana This patch (against the 4.0 branch) adds SASL authentication support for JBoss Security. Currently only supports CRAM-MD5. -- 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

18 years, 7 months

2
9
0 / 0

[JBoss JIRA] Created: (SECURITY-38) Container Task for JBoss SEAM Integration with JBoss Security

by Anil Saldhana (JIRA)

Container Task for JBoss SEAM Integration with JBoss Security ------------------------------------------------------------- Key: SECURITY-38 URL: http://jira.jboss.com/jira/browse/SECURITY-38 Project: JBoss Security and Identity Management Issue Type: Task Security Level: Public (Everyone can see) Components: JEMS Integration Affects Versions: 1.x Reporter: Anil Saldhana Assigned To: Anil Saldhana Fix For: 2.0.1 Container Task to link all the issues that are related to JBoss Seam's integration with JBoss Security. -- 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

18 years, 7 months

1
1
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-880) Non persistent messages can be sent one way

by Tim Fox (JIRA)

Non persistent messages can be sent one way ------------------------------------------- Key: JBMESSAGING-880 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-880 Project: JBoss Messaging Issue Type: Sub-task Reporter: Tim Fox Assigned To: Tim Fox Fix For: 1.2.1 When sending non persistent messages from client to server. They can be sent oneway, i.e. no need to wait for a response that the message has been receive on the server. This should massively increase performance since we will not be hostage to networks with large RTT. -- 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

18 years, 7 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 March 2007