October 2007 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBCACHE-1127) Switch to jboss-javaee.jar

by Brian Stansberry (JIRA)

Switch to jboss-javaee.jar -------------------------- Key: JBCACHE-1127 URL: http://jira.jboss.com/jira/browse/JBCACHE-1127 Project: JBoss Cache Issue Type: Task Security Level: Public (Everyone can see) Reporter: Brian Stansberry Assigned To: Manik Surtani Carlo de Wolf has pulled the JEE APIs out of the AS codebase and into a separate project that produces a jboss-javaee.jar. Right now it's only produced a snapshot, but once it produces a GA release JBC should switch to it from jboss-j2ee.jar. -- 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

16 years, 11 months

2
5
0 / 0

[JBoss JIRA] Updated: (JBCACHE-549) Override GET_ALL and timeout for synchronous requests

by Manik Surtani (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-549?page=all ] Manik Surtani updated JBCACHE-549: ---------------------------------- Fix Version/s: 2.1.0.BETA1 > Override GET_ALL and timeout for synchronous requests > ----------------------------------------------------- > > Key: JBCACHE-549 > URL: http://jira.jboss.com/jira/browse/JBCACHE-549 > Project: JBoss Cache > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Affects Versions: 1.2, 1.2.1, 1.2.2, 1.2.3, 1.2.4beta, 1.3.0.GA, 1.2.4, 1.2.4SP1, 1.2.4SP2 > Reporter: Bela Ban > Assigned To: Manik Surtani > Fix For: 2.1.0.GA, 2.1.0.BETA1 > > > Currently, when executing a *synchronous* method call across a cluster, the caller has to wait until all recipients send the reply, so the default mode is always GroupRequest.GET_ALL. However, we should provide more options (possibly in an Option), e.g. > - GET_ALL > - GET_FIRST > - GET_N (where N < number of recipients) > - GET_MAJORITY > We may also want to be able to set the timeout for the call in an Options parameter, and combine this with the mode. > So Options (used e.g. by put(), remove() etc) should have additional parameters, and *use* them in the relevant interceptors -- 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

16 years, 11 months

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

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

16 years, 11 months

4
7
0 / 0

[JBoss JIRA] Created: (JBCACHE-1155) Invalidation with optimistic versioning could cause cache to write stale data

by Manik Surtani (JIRA)

Invalidation with optimistic versioning could cause cache to write stale data ----------------------------------------------------------------------------- Key: JBCACHE-1155 URL: http://jira.jboss.com/jira/browse/JBCACHE-1155 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Components: Replication Affects Versions: 1.4.1.GA, 1.4.0.GA, 2.0.0.GA Reporter: Manik Surtani Assigned To: Manik Surtani Fix For: 2.1.0.GA The root of the problem is that invalidation evicts remote nodes which may mean that remote nodes are removed completely, losing all historic versioning data 1) Svr 1 generates state for node (data version 1) 2) Svr 2 generates newer state for same node (data version 2) 3) Svr 2 commits (data version 2), invalidates state on cache 1 4) Svr 1 commits, and this is allowed to proceed since it seems cache 1 created this data new, and it does not exist in cache 1. 5) Svr 1 will attempt to invalidate this remotely, but this will fail - but it will still be applied locally. 6) Inconsistency!!! Solution: Invalidation not to remove nodes, but evict nodes as though they had children (remove data maps and set dataInitialised to false), and (if optimistic) attach the version of the invalidation to the node. Eviction to have, in addition to maxTTL, a minTTL as well so that nodes spend at least a certain amount of time in the cache even if scheduled for eviction since even if we have the above eviction may come along and remove the node altogether. MinTTL to be configured to be greater than the max length of transactions. -- 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

16 years, 11 months

1
2
0 / 0

[JBoss JIRA] Created: (JBXB-111) unmarshalling Map with XmlJavaTypeAdapter

by Alexey Loubyansky (JIRA)

unmarshalling Map with XmlJavaTypeAdapter ----------------------------------------- Key: JBXB-111 URL: http://jira.jboss.com/jira/browse/JBXB-111 Project: JBoss XML Binding (JBossXB) Issue Type: Bug Affects Versions: JBossXB-2.0.0.CR4 Reporter: Alexey Loubyansky Assigned To: Alexey Loubyansky Fix For: JBossXB-2.0.0.CR5 The use-case was taken from http://java.sun.com/javaee/5/docs/api/javax/xml/bind/annotation/adapters/... but simplified in the test case package org.jboss.test.xb.builder.object.element.javatypeadapter.test; public class JavaTypeAdapterUnitTestCase extends AbstractBuilderTest -- 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

16 years, 11 months

1
1
0 / 0

[JBoss JIRA] Created: (JBRULES-1266) Composite facts types (OR, AND) not rendering correctly

by Michael Neale (JIRA)

Composite facts types (OR, AND) not rendering correctly ------------------------------------------------------- Key: JBRULES-1266 URL: http://jira.jboss.com/jira/browse/JBRULES-1266 Project: JBoss Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: Drl Parser/Builder Affects Versions: 4.0.2 Reporter: Michael Neale Assigned To: Michael Neale Fix For: 4.0.3, 4.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

16 years, 11 months

1
1
0 / 0

[JBoss JIRA] Created: (JBRULES-1263) Mark xml-apis/xercesImpl as optional dependencies in drools-compiler pom.xml

by Tuomas Kiviaho (JIRA)

Mark xml-apis/xercesImpl as optional dependencies in drools-compiler pom.xml ---------------------------------------------------------------------------- Key: JBRULES-1263 URL: http://jira.jboss.com/jira/browse/JBRULES-1263 Project: JBoss Drools Issue Type: Sub-task Security Level: Public (Everyone can see) Affects Versions: 4.0.2 Reporter: Tuomas Kiviaho Assigned To: Mark Proctor As commented in JBRULES-992 jdk provides xml-apis already so the declaration could be marked as optional or dropped completely. Marking of xercesImpl as optional requires compile time dependency check. Dropping it completely requires also verification that it isn't used anywhere at runtime. -- 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

16 years, 11 months

2
1
0 / 0

[JBoss JIRA] Created: (JBRULES-1265) literal/formula could be clearer in guided editor RHS

by Michael Neale (JIRA)

literal/formula could be clearer in guided editor RHS ----------------------------------------------------- Key: JBRULES-1265 URL: http://jira.jboss.com/jira/browse/JBRULES-1265 Project: JBoss Drools Issue Type: Feature Request Security Level: Public (Everyone can see) Affects Versions: 4.0.2 Reporter: Michael Neale Assigned To: Michael Neale Fix For: 4.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

16 years, 11 months

1
1
0 / 0

[JBoss JIRA] Created: (JBPORTAL-1454) Redo the CMS Action Menu for the CMS Admin tool

by Sohil Shah (JIRA)

Redo the CMS Action Menu for the CMS Admin tool ----------------------------------------------- Key: JBPORTAL-1454 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1454 Project: JBoss Portal Issue Type: Task Security Level: Public (Everyone can see) Components: Portal CMS Affects Versions: 2.6.CR2 Reporter: Sohil Shah Assigned To: Sohil Shah Fix For: 2.6 Final The select Action drop down has a small triangle to the left of it, along with all of the items in the drop down. These should be removed. -- 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

16 years, 11 months

2
4
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira October 2007