January 2008 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (EJBTHREE-989) Can't inject resources of type URL

by Carlo de Wolf (JIRA)

Can't inject resources of type URL ---------------------------------- Key: EJBTHREE-989 URL: http://jira.jboss.com/jira/browse/EJBTHREE-989 Project: EJB 3.0 Issue Type: Bug Reporter: Carlo de Wolf Assigned To: Carlo de Wolf Fix For: EJB 3.0 RC11 - FD -- 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

15 years, 7 months

2
5
0 / 0

[JBoss JIRA] Created: (JGRP-659) Merge and UNICAST sequencing problem

by Vladimir Blagojevic (JIRA)

Merge and UNICAST sequencing problem ------------------------------------ Key: JGRP-659 URL: http://jira.jboss.com/jira/browse/JGRP-659 Project: JGroups Issue Type: Bug Affects Versions: 2.6, 2.5, 2.4 Reporter: Vladimir Blagojevic Assigned To: Bela Ban The problem is related to trashing of connection table in UNICAST during merge. Consider following scenario: There are 4 nodes in a cluster A,B,C, and D. After network split we have two islands A,B and C,D. When the network healing starts eventually MergeView gets installed in both islands. MergeView installation causes trashing of UNICAST connection table [1]. However if we have a scenario where MergeView gets installed in A,B island at time T and it gets installed in island C,D at time T+N msec and a node from island A,B sends a unicast message in this N msec time window then we'll run into problems with unicast sequencing at C and D. Why? Because next message coming from island A,B into C,D will be will with sequence number > 1 and sequencing in UNICAST of C,D after connection trashing (from merge) expects starting sequence of 1. This causes UNICAST in C and/or D to wait forever for missing messages. Final outcome is thus that no more unicast message coming from A and/or B will ever be delivered at C and/or D! [1]http://jira.jboss.com/jira/browse/JGRP-348 -- 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

15 years, 8 months

3
16
0 / 0

[JBoss JIRA] Created: (JBAS-5146) com.sun.faces.serializeServerState , java.lang.ClassNotFoundException: boolean

by Dave Chen (JIRA)

com.sun.faces.serializeServerState , java.lang.ClassNotFoundException: boolean ------------------------------------------------------------------------------- Key: JBAS-5146 URL: http://jira.jboss.com/jira/browse/JBAS-5146 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: JSF Affects Versions: JBossAS-4.2.2.GA Environment: JBoss 4.2.2.GA, using JSF RI with Tomahawk. Reporter: Dave Chen Assigned To: Stan Silvert Priority: Critical I am using <t:saveState>, and set com.sun.faces.serializeServerState to true in web.xml. <context-param> <param-name>javax.faces.STATE_SAVING_METHOD</param-name> <param-value>server</param-value> </context-param> <context-param> <param-name>com.sun.faces.serializeServerState</param-name> <param-value>true</param-value> </context-param> I got the following exception. java.lang.ClassNotFoundException: boolean at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1358) at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1204) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:242) at com.sun.faces.renderkit.ApplicationObjectInputStream.resolveClass(ApplicationObjectInputStream.java:74) at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1544) at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1466) at java.io.ObjectInputStream.readClass(ObjectInputStream.java:1433) at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1288) at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1908) at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1832) at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1719) at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1305) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:348) at java.util.ArrayList.readObject(ArrayList.java:591) -- 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

15 years, 8 months

2
4
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-1186) maxBatchTime stops working after the connection between source and target servers is lost

by Maurice Zeijen (JIRA)

maxBatchTime stops working after the connection between source and target servers is lost ----------------------------------------------------------------------------------------- Key: JBMESSAGING-1186 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1186 Project: JBoss Messaging Issue Type: Bug Affects Versions: 1.4.0.SP1 Environment: Windows XP 64 Java 6 JBoss 4.2.2 Reporter: Maurice Zeijen Assigned To: Tim Fox We have the following Situation: A bridge MBean is setup to bridge between a local source and a remote target. The MaxBatchSize attribute is set to 5 and the MaxBatchTime is set to 10000. So the configuration looks like this: <mbean code="org.jboss.jms.server.bridge.BridgeService" name="jboss.messaging:service=Bridge,name=wai_sync_customer_bridge" xmbean-dd="xmdesc/Bridge-xmbean.xml"> <depends optional-attribute-name="SourceProviderLoader">jboss.messaging:service=JMSProviderLoader,name=JMSProvider</depends> <depends optional-attribute-name="TargetProviderLoader">jboss.messaging:service=JMSProviderLoader,name=RemoteJMSProvider</depends> <attribute name="SourceDestinationLookup">/queue/local</attribute> <attribute name="TargetDestinationLookup">/queue/remote</attribute> <attribute name="QualityOfServiceMode">0</attribute> <attribute name="MaxBatchSize">5</attribute> <attribute name="MaxBatchTime">10000</attribute> <attribute name="FailureRetryInterval">5000</attribute> <attribute name="MaxRetries">-1</attribute> <attribute name="AddMessageIDInHeader">false</attribute> <depends>jboss.messaging.destination:name=local,service=Queue</depends> </mbean> If the connection between the two servers is available then the MaxBatchTime works fine. After 10 seconds all messages are moved from local queue to remote queue if there are less then 5 messages in the queue. But when for some reason the connection is lost and after a while restored again then the MaxBatchTime doesn't work any more. Luckily the MaxBatchSize still works. Also the MaxBatchSize doesn't work when the remote server isn't available when the bridge on the local server is started. Restarting the bridge makes the MaxBatchTime work again. -- 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

15 years, 8 months

4
6
0 / 0

[JBoss JIRA] Created: (JBRULES-1219) Using DSL and accumulate in Drools BRMS leads to unexpected results

by Cristiano Giuffrida (JIRA)

Using DSL and accumulate in Drools BRMS leads to unexpected results ------------------------------------------------------------------- Key: JBRULES-1219 URL: http://jira.jboss.com/jira/browse/JBRULES-1219 Project: JBoss Rules Issue Type: Bug Security Level: Public (Everyone can see) Components: Drl Parser/Builder Affects Versions: 4.0.1 Environment: HP-UX java version "1.5.0.05" Reporter: Cristiano Giuffrida Assigned To: Mark Proctor Details of this problem are described in the following thread: http://www.nabble.com/Using-DSL-and-accumulate-in-Drools-BRMS-leads-to-un... -- 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

15 years, 8 months

5
7
0 / 0

[JBoss JIRA] Created: (EJBTHREE-1056) Redo NestedBeanUnitTestCase.testConsistentPassivatedState()

by Brian Stansberry (JIRA)

Redo NestedBeanUnitTestCase.testConsistentPassivatedState() ----------------------------------------------------------- Key: EJBTHREE-1056 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1056 Project: EJB 3.0 Issue Type: Sub-task Components: Clustering Reporter: Brian Stansberry Assigned To: Brian Stansberry Priority: Minor NestedBeanUnitTestCase.testConsistentPassivatedState() is a pretty weak test for the EJBTHREE-1053 condition; when the parent issue is fixed, replace this test with something better. -- 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

15 years, 8 months

1
3
0 / 0

[JBoss JIRA] Created: (EJBTHREE-922) Handle merging of clustered SFSB state if a MergeView is received

by Brian Stansberry (JIRA)

Handle merging of clustered SFSB state if a MergeView is received ----------------------------------------------------------------- Key: EJBTHREE-922 URL: http://jira.jboss.com/jira/browse/EJBTHREE-922 Project: EJB 3.0 Issue Type: Task Components: Clustering Affects Versions: AS 4.2.0 CR1 Reporter: Brian Stansberry Assigned To: Brian Stansberry The JBCACHE-8 solution will provide a notification of when a cluster merge occurs. Need to work with the JBC team to design the callback and to implement a solution that will allow merging of clustered SFSB state. -- 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

15 years, 8 months

1
3
0 / 0

[JBoss JIRA] Created: (EJBTHREE-895) Allow clustered tests to run with -u set

by Brian Stansberry (JIRA)

Allow clustered tests to run with -u set ---------------------------------------- Key: EJBTHREE-895 URL: http://jira.jboss.com/jira/browse/EJBTHREE-895 Project: EJB 3.0 Issue Type: Task Components: Clustering Reporter: Brian Stansberry Assigned To: Brian Stansberry Need to use the local.properties "udpGroup" stuff that the AS uses. Allows running with less concern for impactt from / impacting other running servers. -- 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

15 years, 8 months

1
1
0 / 0

[JBoss JIRA] Created: (EJBTHREE-857) Include and use buddy group topology information in clustered SFSB proxies

by Brian Stansberry (JIRA)

Include and use buddy group topology information in clustered SFSB proxies -------------------------------------------------------------------------- Key: EJBTHREE-857 URL: http://jira.jboss.com/jira/browse/EJBTHREE-857 Project: EJB 3.0 Issue Type: Feature Request Components: Clustering Reporter: Brian Stansberry Assigned To: Brian Stansberry Look into including the replicated SFSB cache's buddy replication group topology in clustered SFSB proxies, and using that information in fail over decisions. This is basically an optimization such that when a failover occurs, data gravitation can occur in VM rather than over the network. -- 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

15 years, 8 months

2
1
0 / 0

[JBoss JIRA] Created: (EJBTHREE-848) ClusteredStatefulCacheListener should be a singleton

by Brian Stansberry (JIRA)

ClusteredStatefulCacheListener should be a singleton ---------------------------------------------------- Key: EJBTHREE-848 URL: http://jira.jboss.com/jira/browse/EJBTHREE-848 Project: EJB 3.0 Issue Type: Task Components: Clustering Reporter: Brian Stansberry Assigned To: Brian Stansberry Priority: Minor Fix For: EJB 3.0 RC11 - FD Currently, each SFSB Container registers an instance of ClusteredStatefulCacheListener with the SFSB cache. This is inefficient if there are many containers, as each gets passivation/activation callbacks and has to filter for the ones it's interested in. The callbacks don't do anything container-specific, so it should be possible to use a quasi-singleton ClusteredStatefulCacheListener and eliminate the filtering. Quasi-singleton, because it's possible to have multiple SFSB caches; need one listener per cache. -- 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

15 years, 8 months

3
2
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira January 2008