August 2008 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBCACHE-1395) Upgrade to JGroups 2.6.4

by Manik Surtani (JIRA)

Upgrade to JGroups 2.6.4 ------------------------ Key: JBCACHE-1395 URL: https://jira.jboss.org/jira/browse/JBCACHE-1395 Project: JBoss Cache Issue Type: Task Security Level: Public (Everyone can see) Reporter: Manik Surtani Assignee: Manik Surtani Fix For: 3.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, 11 months

1
1
0 / 0

[JBoss JIRA] Created: (JBPORTAL-2099) Patch for [JBPORTAL-2095] Localize CMS Portlet Error Message

by Magesh Kumar B (JIRA)

Patch for [JBPORTAL-2095] Localize CMS Portlet Error Message ------------------------------------------------------------ Key: JBPORTAL-2099 URL: https://jira.jboss.org/jira/browse/JBPORTAL-2099 Project: JBoss Portal Issue Type: Support Patch Security Level: Public (Everyone can see) Components: Portal CMS Affects Versions: 2.6.6 Final Reporter: Magesh Kumar B Assignee: Magesh Kumar B Priority: Critical -- 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, 11 months

1
1
0 / 0

[JBoss JIRA] Created: (JBMETA-86) When jndiName is equal to deploymentScopeBaseName, JNDI Name Collisions occur

by Andrew Lee Rubinger (JIRA)

When jndiName is equal to deploymentScopeBaseName, JNDI Name Collisions occur ----------------------------------------------------------------------------- Key: JBMETA-86 URL: https://jira.jboss.org/jira/browse/JBMETA-86 Project: JBoss Metadata Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 1.0.0.Beta33 Reporter: Andrew Lee Rubinger Assignee: Andrew Lee Rubinger If the deploymentScopeBaseName (==EAR name) is equal to the "jndi-name" specified by the bean provider, JNDI Collisions occur in the BasicJndiBindingPolicy as the name of the EAR is used as a base, and becomes an invalid subcontext as its already bound to the jndi-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, 11 months

2
2
0 / 0

[JBoss JIRA] Created: (JBCL-28) Make ResourceContext interface

by Ales Justin (JIRA)

Make ResourceContext interface ------------------------------ Key: JBCL-28 URL: https://jira.jboss.org/jira/browse/JBCL-28 Project: JBoss ClassLoader Issue Type: Task Components: General Affects Versions: JBossCL.2.0.0.Beta12 Reporter: Ales Justin Assignee: Ales Justin Fix For: JBossCL.2.0.0.CR1 Make ResourceContext interface. It's then up to the impl how it handles information creation, e.g. lazy URL via VirtualFile. -- 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, 11 months

1
1
0 / 0

[JBoss JIRA] Created: (JBCL-29) Allow Module::visit to accept URL roots as parameter

by Ales Justin (JIRA)

Allow Module::visit to accept URL roots as parameter ---------------------------------------------------- Key: JBCL-29 URL: https://jira.jboss.org/jira/browse/JBCL-29 Project: JBoss ClassLoader Issue Type: Feature Request Components: Modules Affects Versions: JBossCL.2.0.0.Beta12 Reporter: Ales Justin Assignee: Ales Justin Fix For: JBossCL.2.0.0.CR1 Module::visit should be allowed to take URL roots. We must then check underlying module root URLs to only use the ones that actually belong to our 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, 11 months

1
1
0 / 0

[JBoss JIRA] Created: (JBCACHE-1322) Optimise Fqn class for performance in equals() and hashcode()

by Manik Surtani (JIRA)

Optimise Fqn class for performance in equals() and hashcode() ------------------------------------------------------------- Key: JBCACHE-1322 URL: http://jira.jboss.com/jira/browse/JBCACHE-1322 Project: JBoss Cache Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: Manik Surtani Assigned To: Manik Surtani Fix For: 2.2.0.GA A part of this will be to mark all constructors as @Deprecated and make them all private (or protected?) in 3.0.0. Provide adequate factory methods that would create Fqns. The main benefit is that we can intern Fqns and not have to construct them each time. Other improvements are a link to the parent and the current "name", rather than the whole list of elements. Hashcodes and equals can be calculated quickly this way, and caching hashcodes/equality tests based on identity become a possibility. Other suggestions in design forum thread. -- 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

17 years, 11 months

1
3
0 / 0

[JBoss JIRA] Created: (JBCACHE-797) Cache to provide a Node implementation that can hide the internal metadata

by Ben Wang (JIRA)

Cache to provide a Node implementation that can hide the internal metadata -------------------------------------------------------------------------- Key: JBCACHE-797 URL: http://jira.jboss.com/jira/browse/JBCACHE-797 Project: JBoss Cache Issue Type: Task Security Level: Public (Everyone can see) Reporter: Ben Wang Assigned To: Manik Surtani Fix For: 2.1.0 This came up from a Forum thread. Can we offer a second node implementation such that we can deposit the metadata into that node that is hiding away from the user? -- 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

17 years, 11 months

4
4
0 / 0

[JBoss JIRA] Resolved: (JBCACHE-611) Optimize modification list before replication

by Manik Surtani (JIRA)

[ https://jira.jboss.org/jira/browse/JBCACHE-611?page=com.atlassian.jira.pl... ] Manik Surtani resolved JBCACHE-611. ----------------------------------- Resolution: Won't Fix > Optimize modification list before replication > --------------------------------------------- > > Key: JBCACHE-611 > URL: https://jira.jboss.org/jira/browse/JBCACHE-611 > Project: JBoss Cache > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Replication > Affects Versions: 1.2, 1.2.1, 1.2.2, 1.2.3, 1.2.4beta, 1.2.4, 1.2.4SP1, 1.2.4SP2, 1.3.0.GA, 1.3.0.SP1 > Reporter: Bela Ban > Assignee: Mircea Markus > Fix For: 3.0.0.GA > > > When we use transactions, all modifications (PUT,REMOVE) are bundled (keyed by TX-ID) and replicated on TX commit. > This is very inefficient if (a) we have many modifications in the TX scope and (b) if the modifications touched the same parts of the cache over and over again. > We need to optimize the modification list before replication. (This maybe enabled/disabled via an attribute). > Example: put(a/b/c) --> put(/a/b/c/d) --> remove(/a/b/c) --> put(a/b/c) should simply result in a PUT modification with *all* of the attributes of /a/b/c, so 1 modification instead of 4 ! > A general algorithm might be: > - Maintain a dirty-node map Map<FQN, status>) (= "dirty", "removed") > - On a put(FQN): add or set FQN to the map, set status="dirty" > - On a remove(FQN): set FQN in map to "removed", needs to mark all subnodes as well, so maybe the dirty-node map needs to be > a tree... > We might get rid of *constructing the modification lists during modifications*, and only populate the dirty-node map. The modification list could only be created at *TX commit time*, from the dirty-node map, e.g in the above example: PUT(a/b/c). > This only applies to pessimistic locking (does it ? can't we optimize optimistic locking in similar ways ?) -- 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, 11 months

1
0
0 / 0

[JBoss JIRA] Commented: (JBCACHE-611) Optimize modification list before replication

by Manik Surtani (JIRA)

[ https://jira.jboss.org/jira/browse/JBCACHE-611?page=com.atlassian.jira.pl... ] Manik Surtani commented on JBCACHE-611: --------------------------------------- We decided that this was unnecesarily expensive (walking the mod list, matching cancelling entries) for little gain if in the end cancelling entries are only found infrequently in a given tx. > Optimize modification list before replication > --------------------------------------------- > > Key: JBCACHE-611 > URL: https://jira.jboss.org/jira/browse/JBCACHE-611 > Project: JBoss Cache > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Replication > Affects Versions: 1.2, 1.2.1, 1.2.2, 1.2.3, 1.2.4beta, 1.2.4, 1.2.4SP1, 1.2.4SP2, 1.3.0.GA, 1.3.0.SP1 > Reporter: Bela Ban > Assignee: Mircea Markus > Fix For: 3.0.0.GA > > > When we use transactions, all modifications (PUT,REMOVE) are bundled (keyed by TX-ID) and replicated on TX commit. > This is very inefficient if (a) we have many modifications in the TX scope and (b) if the modifications touched the same parts of the cache over and over again. > We need to optimize the modification list before replication. (This maybe enabled/disabled via an attribute). > Example: put(a/b/c) --> put(/a/b/c/d) --> remove(/a/b/c) --> put(a/b/c) should simply result in a PUT modification with *all* of the attributes of /a/b/c, so 1 modification instead of 4 ! > A general algorithm might be: > - Maintain a dirty-node map Map<FQN, status>) (= "dirty", "removed") > - On a put(FQN): add or set FQN to the map, set status="dirty" > - On a remove(FQN): set FQN in map to "removed", needs to mark all subnodes as well, so maybe the dirty-node map needs to be > a tree... > We might get rid of *constructing the modification lists during modifications*, and only populate the dirty-node map. The modification list could only be created at *TX commit time*, from the dirty-node map, e.g in the above example: PUT(a/b/c). > This only applies to pessimistic locking (does it ? can't we optimize optimistic locking in similar ways ?) -- 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, 11 months

1
0
0 / 0

[JBoss JIRA] Created: (JBDEPLOY-68) Transient attachments should not be serialized

by Adrian Brock (JIRA)

Transient attachments should not be serialized ---------------------------------------------- Key: JBDEPLOY-68 URL: https://jira.jboss.org/jira/browse/JBDEPLOY-68 Project: JBoss Deployers Issue Type: Task Components: attachments Reporter: Adrian Brock Fix For: JBDEPLOY-2.0.0.CR1 When I refactored the attachments processing, I mistakenly made the transient attachments become serialized. These attachments should not be getting serialized. -- 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, 11 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 August 2008