March 2007 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBFORUMS-191) Make Forums work with JBoss Portal 2.6 Beta1

by Ryszard Kozmik (JIRA)

Make Forums work with JBoss Portal 2.6 Beta1 -------------------------------------------- Key: JBFORUMS-191 URL: http://jira.jboss.com/jira/browse/JBFORUMS-191 Project: JBoss Forums Issue Type: Task Components: Portlet Productization Reporter: Ryszard Kozmik Assigned To: Przemyslaw Dej Fix For: 1.0.0 GA We have to test whether Forums work with newest release of JBoss Portal which is 2.6 Beta1 and eventually make it compatible. -- 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

19 years, 3 months

2
1
0 / 0

[JBoss JIRA] Created: (JGRP-341) Extend FLUSH to fully support virtual synchrony

by Bela Ban (JIRA)

Extend FLUSH to fully support virtual synchrony ----------------------------------------------- Key: JGRP-341 URL: http://jira.jboss.com/jira/browse/JGRP-341 Project: JGroups Issue Type: Feature Request Affects Versions: 2.4 Reporter: Bela Ban Assigned To: Vladimir Blagojevic Fix For: 2.5 Currently, FLUSH makes sure that all members 'flush' their pending messages and then stop sending new ones until the join or state transfer is over. However, FLUSH does *not* (unlike the old version) make sure that - on JOIN - all members have seen the same set of messages before installing a new view. Example: P sends M, but immediately after sending M crashes. If another member Q received M, but R didn't see M, then - with the current FLUSH - R will *not* see M. We need to run a messages exchange phase, as part of FLUSH, which makes sure that all member have seen the same set of messages in the same view, before installing a new view. Whether to run this or not could be made configurable. If enabled, we could piggyback the message exchange on START_FLUSH/FLUSH_OK etc. A simple (but costly) solution would be to simply multicast all messages received from other members before multicasting the FLUSH_OK. A better solution would be to exchange digests with highest sequence numbers seen for all members, and then only multicast the missing messages. This *might* require an additional phase though. -- 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

19 years, 3 months

3
2
0 / 0

[JBoss JIRA] Created: (JBAS-3691) NoClassDefFoundError performing remote lookup of dynamic proxy using IBM JDK

by Darran Lofthouse (JIRA)

NoClassDefFoundError performing remote lookup of dynamic proxy using IBM JDK ---------------------------------------------------------------------------- Key: JBAS-3691 URL: http://jira.jboss.com/jira/browse/JBAS-3691 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: JBossAS-4.0.4.GA Environment: IBM JDK 1.5 32bit and 64bit IBM JDK 1.4 64bit Reporter: Darran Lofthouse Assigned To: Darran Lofthouse Fix For: JBossAS-4.0.6.CR1 Using the IBM JDKs listed in the environment, performing a remote lookup of a dynamic proxy from within JBoss cases a NoClassDefFoundError. -- 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

19 years, 3 months

9
26
0 / 0

[JBoss JIRA] Created: (JBRULES-758) Move RuleModel (ROM) to compiler

by Michael Neale (JIRA)

Move RuleModel (ROM) to compiler -------------------------------- Key: JBRULES-758 URL: http://jira.jboss.com/jira/browse/JBRULES-758 Project: JBoss Rules Issue Type: Sub-task Security Level: Public (Everyone can see) Reporter: Michael Neale Assigned To: Michael Neale -- 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

19 years, 3 months

1
1
0 / 0

[JBoss JIRA] Created: (JBCACHE-876) Region marker in region-based marshalling message should be region fqn

by Brian Stansberry (JIRA)

Region marker in region-based marshalling message should be region fqn ---------------------------------------------------------------------- Key: JBCACHE-876 URL: http://jira.jboss.com/jira/browse/JBCACHE-876 Project: JBoss Cache Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: Brian Stansberry Assigned To: Brian Stansberry Fix For: 1.4.1.GA When region based marshalling is used, the replication message first has a serialized Fqn to identify the region, followed by a separately serialized method call. Receiver deserializes the identifier fqn and uses it to find the classloader to use to deserialize the main message. Problem is the region identifier Fqn is the full Fqn of a node. This prevents the use in Fqns of classes that require the custom classloader to deserialize. This can be mitigated by changing the marker Fqn to simply identify the Region, not some subnode. Now the restriction on use of custom classes is limited to the region Fqn; portions of Fqns below the region level can be of any serializable class. This is needed to solve JBCLUSTER-150. Downside is the node marshalling the message now needs to do a Region lookup to get the region Fqn. Upsides are a reduced message size, since the shorter region fqn is marshalled, as well as a possibly faster region lookup time on the recipient nodes, since extraneous data can be ignored. -- 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

19 years, 3 months

2
6
0 / 0

[JBoss JIRA] Created: (JBCACHE-733) Fine-grained JDOM replication effort

by Ben Wang (JIRA)

Fine-grained JDOM replication effort ------------------------------------ Key: JBCACHE-733 URL: http://jira.jboss.com/jira/browse/JBCACHE-733 Project: JBoss Cache Issue Type: Task Security Level: Public (Everyone can see) Components: PojoCache Reporter: Ben Wang Assigned To: Ben Wang Fix For: POJOCache This is efforts made to "apectizing" JDOM library under branch JBossCache_1_4_JDOM: 1. Check in additional jdom library: saxpath.jar, jdom.jar, and jaxen-*.jar 2. Re-factored to introduce NonTransient tag. 3. Unit test for jdom -- 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

19 years, 3 months

2
3
0 / 0

[JBoss JIRA] Created: (JBCACHE-741) Create a jdom replication GUI example

by Ben Wang (JIRA)

Create a jdom replication GUI example ------------------------------------- Key: JBCACHE-741 URL: http://jira.jboss.com/jira/browse/JBCACHE-741 Project: JBoss Cache Issue Type: Sub-task Security Level: Public (Everyone can see) Components: PojoCache Reporter: Ben Wang Assigned To: Ben Wang Fix For: 2.0.0 We will need to have a JDOM gui that can demonstrate the fine-grained replication using the "aspectized" jdom library. -- 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

19 years, 3 months

2
10
0 / 0

[JBoss JIRA] Created: (JBCACHE-977) PojoCache annotated50 run.loadtime.example failed

by Ben Wang (JIRA)

PojoCache annotated50 run.loadtime.example failed ------------------------------------------------- Key: JBCACHE-977 URL: http://jira.jboss.com/jira/browse/JBCACHE-977 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Components: PojoCache Affects Versions: 1.4.1.SP1 Reporter: Ben Wang Assigned To: Ben Wang Fix For: PojoCache Reported by a user. The root cause seems to be in jboss aop since it fails when a subclass (in this Student from Person) is put into PojoCache and instrumented during loadtime (note that compile mode works correctly). I have checked PojoCache2.0. It works fine there with jboss aop 2.0. I ahve checked in an example in NewReplicatedAopTest. Will have Kabir take a look. -- 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

19 years, 3 months

2
2
0 / 0

[JBoss JIRA] Created: (JBCACHE-893) Create a pluggable PojoCache Collection class implementation

by Ben Wang (JIRA)

Create a pluggable PojoCache Collection class implementation ------------------------------------------------------------ Key: JBCACHE-893 URL: http://jira.jboss.com/jira/browse/JBCACHE-893 Project: JBoss Cache Issue Type: Feature Request Security Level: Public (Everyone can see) Components: PojoCache Reporter: Ben Wang Assigned To: Ben Wang Fix For: PojoCache Currently PojoCache only supports a single flavor of Collection classes, e.g., HashMap, HashSet, and ArrayList. To fully support different flavor of Collection implementation, we can either: 1. Enable array interception from Jboss Aop such that we can instrument all Collection implementation classes (including java.util.*). But JBoss Aop currently doesn't support it yet, and issues of instrumenting the Sun system classes also is problematic. 2. Create a pluggable architecture for different flavor of Collection implementation. I think Option #2 is more realistic now. What I propose is this: 1. Will need to implement a specific flavor of collection interceptor and cache impl. E.g., in the case of List, it will be CachedListInterceptor and CachedListImpl. 2. Register the specific impl and the corresponding Collection class name to a registry During runtime, when we encounter Collection classes, we will check the registry first to see which interceptor (and the corresponding cache impl) that we will use for this case. Performance impact should be minimal since this is needed only for attach phase. -- 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

19 years, 3 months

2
1
0 / 0

[JBoss JIRA] Created: (JBCACHE-750) PojoCache to deal with POJO without no-arg constructor

by Ben Wang (JIRA)

PojoCache to deal with POJO without no-arg constructor ------------------------------------------------------ Key: JBCACHE-750 URL: http://jira.jboss.com/jira/browse/JBCACHE-750 Project: JBoss Cache Issue Type: Task Security Level: Public (Everyone can see) Components: PojoCache Reporter: Ben Wang Assigned To: Ben Wang Fix For: PojoCache This came up from a forum post that uses SynchronizedCollection. Here is the problem that Professor Chiba pointed out: ------ Ben, SynchronizedRandomAccessList class has only the following constructors: static class SynchronizedRandomAccessList<E> extends SynchronizedList<E> implements RandomAccess { SynchronizedRandomAccessList(List<E> list) { super(list); } SynchronizedRandomAccessList(List<E> list, Object mutex) { super(list, mutex); } : } I can modify Javassist so that the above constructors (visible only within the pacakge) will be copied to the generated class. But I am not sure that PojoCache can work with that generated class since it does not have a no-arg constructor. Chiba -------- No easy solution to this problem now. Maybe use the exisiting serialization for once during replication? -- 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

19 years, 3 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