May 2007 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBAS-3613) failing test in org.jboss.test.iiop.test.ParameterPassingStressTestCase

by Dimitris Andreadis (JIRA)

failing test in org.jboss.test.iiop.test.ParameterPassingStressTestCase ----------------------------------------------------------------------- Key: JBAS-3613 URL: http://jira.jboss.com/jira/browse/JBAS-3613 Project: JBoss Application Server Issue Type: Sub-task Security Level: Public (Everyone can see) Components: IIOP service, Test Suite Environment: Java Version 1.5.0_05 Java Vendor Sun Microsystems Inc. Java VM Name Java HotSpot(TM) Server VM Java VM Version 1.5.0_05-b05 Java VM Info mixed mode OS Name Linux OS Version 2.6.9-34.0.2.ELsmp OS Arch i386 Reporter: Dimitris Andreadis Assigned To: Francisco Reverbel Fix For: JBossAS-4.0.5.GA test_getException Error Invalid indirection to offset 1704 java.io.IOException: Invalid indirection to offset 1704 at com.sun.corba.se.impl.io.IIOPInputStream$ActiveRecursionManager.getObject(IIOPInputStream.java:2684) at com.sun.corba.se.impl.io.IIOPInputStream.inputClassFields(IIOPInputStream.java:2218) at com.sun.corba.se.impl.io.IIOPInputStream.inputObject(IIOPInputStream.java:1221) at com.sun.corba.se.impl.io.IIOPInputStream.simpleReadObject(IIOPInputStream.java:400) at com.sun.corba.se.impl.io.ValueHandlerImpl.readValueInternal(ValueHandlerImpl.java:327) at com.sun.corba.se.impl.io.ValueHandlerImpl.readValue(ValueHandlerImpl.java:293) at org.jacorb.util.ValueHandler.readValue(ValueHandler.java:25) at org.jacorb.orb.CDRInputStream.read_untyped_value(CDRInputStream.java:2695) at org.jacorb.orb.CDRInputStream.read_typed_value(CDRInputStream.java:2753) at org.jacorb.orb.CDRInputStream.read_value(CDRInputStream.java:2438) at com.sun.corba.se.impl.io.ValueHandlerImpl.read_Array(ValueHandlerImpl.java:756) at com.sun.corba.se.impl.io.ValueHandlerImpl.readValueInternal(ValueHandlerImpl.java:325) at com.sun.corba.se.impl.io.ValueHandlerImpl.readValue(ValueHandlerImpl.java:293) at org.jacorb.util.ValueHandler.readValue(ValueHandler.java:25) at org.jacorb.orb.CDRInputStream.read_untyped_value(CDRInputStream.java:2695) at org.jacorb.orb.CDRInputStream.read_typed_value(CDRInputStream.java:2753) at org.jacorb.orb.CDRInputStream.read_value(CDRInputStream.java:2438) at com.sun.corba.se.impl.io.IIOPInputStream.inputObjectField(IIOPInputStream.java:1989) at com.sun.corba.se.impl.io.IIOPInputStream.inputClassFields(IIOPInputStream.java:2213) at com.sun.corba.se.impl.io.IIOPInputStream.inputObject(IIOPInputStream.java:1221) at com.sun.corba.se.impl.io.IIOPInputStream.simpleReadObject(IIOPInputStream.java:400) at com.sun.corba.se.impl.io.ValueHandlerImpl.readValueInternal(ValueHandlerImpl.java:327) at com.sun.corba.se.impl.io.ValueHandlerImpl.readValue(ValueHandlerImpl.java:293) at org.jacorb.util.ValueHandler.readValue(ValueHandler.java:25) at org.jacorb.orb.CDRInputStream.read_untyped_value(CDRInputStream.java:2695) at org.jacorb.orb.CDRInputStream.read_typed_value(CDRInputStream.java:2753) at org.jacorb.orb.CDRInputStream.read_value(CDRInputStream.java:2310) at org.jacorb.orb.Any.read_value(Any.java:816) at org.jacorb.orb.CDRInputStream.read_any(CDRInputStream.java:673) at com.sun.corba.se.impl.javax.rmi.CORBA.Util.readAny(Util.java:401) at javax.rmi.CORBA.Util.readAny(Util.java:92) at org.jboss.iiop.rmi.marshal.CDRStream$ObjectReader.read(CDRStream.java:618) at org.jboss.iiop.rmi.marshal.strategy.StubStrategy.readRetval(StubStrategy.java:226) at org.jboss.proxy.ejb.DynamicIIOPStub.invoke(DynamicIIOPStub.java:128) at org.jboss.test.iiop.interfaces._StatelessSession_Stub.getException(Unknown Source) at org.jboss.test.iiop.test.ParameterPassingStressTestCase.test_getException(ParameterPassingStressTestCase.java:355) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.extensions.TestSetup.run(TestSetup.java:23) -- 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, 10 months

4
21
0 / 0

[JBoss JIRA] Created: (JBPORTAL-1167) Improve error handling in WSRP to be more informative

by Chris Laprun (JIRA)

Improve error handling in WSRP to be more informative ----------------------------------------------------- Key: JBPORTAL-1167 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1167 Project: JBoss Portal Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Portal WSRP Affects Versions: 2.4.1 Final, 2.6.DR1 Reporter: Chris Laprun Assigned To: Chris Laprun Fix For: 2.6 Final -- 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, 10 months

4
7
0 / 0

[JBoss JIRA] Created: (EJBTHREE-689) support XMBean @Service beans

by William DeCoste (JIRA)

support XMBean @Service beans ----------------------------- Key: EJBTHREE-689 URL: http://jira.jboss.com/jira/browse/EJBTHREE-689 Project: EJB 3.0 Issue Type: Feature Request Affects Versions: EJB 3.0 RC8 - FD Reporter: William DeCoste Assigned To: William DeCoste -- 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, 10 months

2
2
0 / 0

[JBoss JIRA] Created: (JGRP-446) When using an extremely simple protocol stack the app will respond with a NullPointerException.

by Anders Persson (JIRA)

When using an extremely simple protocol stack the app will respond with a NullPointerException. ----------------------------------------------------------------------------------------------- Key: JGRP-446 URL: http://jira.jboss.com/jira/browse/JGRP-446 Project: JGroups Issue Type: Bug Affects Versions: 2.4.1 SP1 Environment: Windows XP java version "1.5.0_11" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_11-b03) Java HotSpot(TM) Client VM (build 1.5.0_11-b03, mixed mode) Reporter: Anders Persson Assigned To: Bela Ban Priority: Minor When using an extremely simple protocol stack the app will respond with a NullPointerException. The communication will however work (at least when running all parties on the same machine). The stack used: <protocol_stacks> <stack name="standard" description="Multicast stack intended for usage on internal highspeed networks."> <config> <UDP mcast_addr="228.15.15.15" mcast_port="45566"/> <PING timeout="2000"/> </config> </stack> <stack name="slow" description="Multicast stack intended for usage on external slow connections."> <config> <UDP mcast_addr="228.15.15.15" mcast_port="45567"/> <PING timeout="2000"/> </config> </stack> </protocol_stacks> Starting DrawMultiplexer using the stack above will generate the following stack trace 2007-mar-26 16:51:24 org.jgroups.JChannelFactory connect SEVERE: failed sending SERVICE_UP message java.lang.NullPointerException at org.jgroups.mux.Multiplexer.generateServiceView(Multiplexer.java:953) at org.jgroups.mux.Multiplexer.handleServiceUp(Multiplexer.java:781) at org.jgroups.mux.Multiplexer.sendServiceUpMessage(Multiplexer.java:224) at org.jgroups.JChannelFactory.connect(JChannelFactory.java:372) at org.jgroups.mux.MuxChannel.connect(MuxChannel.java:126) at org.jgroups.demos.DrawMultiplexer.start(DrawMultiplexer.java:44) at org.jgroups.demos.DrawMultiplexer.main(DrawMultiplexer.java:29) I traced the "problem" to be the lack of a pbcast.GMS entry. (You can try it by removing that entry in the conf/stacks.xml file in your distribution.) Some additional information: In order to get DrawMultiplexer to "communicate" you will have to start two instances using the stack above. Then press "leave" in the window that pops up as a result of the FIRST instance started. (Don't know the inner workings of the DrawMultiplexer app, I don't have to resort to these kinds of actions to get my own app to communicate.) The reason I would like to see this fixed is that I don't want to have NullPointerExceptions in the log file when deploying this at the customer. The reason for my very simple protocol is that we intend to use JGroups in a configuration where one server pumps out data in a stream to a varying number of clients and we don't care if the data was received correctly or not since the stream of data is repeated every six seconds. -- 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, 10 months

2
4
0 / 0

[JBoss JIRA] Created: (JBRULES-683) Document solver in the manual

by Geoffrey De Smet (JIRA)

Document solver in the manual ----------------------------- Key: JBRULES-683 URL: http://jira.jboss.com/jira/browse/JBRULES-683 Project: JBoss Rules Issue Type: Task Security Level: Public (Everyone can see) Components: Solver Reporter: Geoffrey De Smet Assigned To: Geoffrey De Smet Priority: Trivial concepts of: - move - step - recaller - decider - selecter - accepter - evaluator - score calculator - score comperator -- 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, 10 months

1
1
0 / 0

[JBoss JIRA] Created: (JBRULES-834) Setup decent svn:ignore on all modules

by Geoffrey De Smet (JIRA)

Setup decent svn:ignore on all modules -------------------------------------- Key: JBRULES-834 URL: http://jira.jboss.com/jira/browse/JBRULES-834 Project: JBoss Rules Issue Type: Task Security Level: Public (Everyone can see) Reporter: Geoffrey De Smet Assigned To: Mark Proctor The parent project dir doesn't have target dir & eclipse files ignored, none have idea and netbeans ignored. It's nice to have intellij idea and netbeans files excluded too. The svn:ignore property should be equal on every folder that contains a pom.xml: parent pom dir, module pom dirs etc. Here's an advisable list, it includes the build map, and project configuration of eclipse, idea and netbeans, and a local map, which is handy for a notepad.txt file etc ================ target *.log *.log.* .classpath .project .settings .wtpmodules *.ipr *.iws *.iml nbproject local -- 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, 10 months

3
10
0 / 0

[JBoss JIRA] Created: (JBPORTAL-1101) Replace WSRPUtils.createOperationFailedFault by WSRPUtils.throwOperationFailedFault

by Chris Laprun (JIRA)

Replace WSRPUtils.createOperationFailedFault by WSRPUtils.throwOperationFailedFault ----------------------------------------------------------------------------------- Key: JBPORTAL-1101 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1101 Project: JBoss Portal Issue Type: Task Security Level: Public (Everyone can see) Components: Portal WSRP Reporter: Chris Laprun Assigned To: Chris Laprun Priority: Minor Fix For: 2.6.Alpha1 so that we don't have to throw the newly created exception each time... -- 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, 10 months

3
5
0 / 0

[JBoss JIRA] Created: (JBAS-4428) Method org.jboss.web.tomcat.tc5.session.ClusteredSession.calcMaxUnreplicatedInterval incorrectly treats maxInactiveInterval as milliseconds

by Stephen Burdeau (JIRA)

Method org.jboss.web.tomcat.tc5.session.ClusteredSession.calcMaxUnreplicatedInterval incorrectly treats maxInactiveInterval as milliseconds ------------------------------------------------------------------------------------------------------------------------------------------- Key: JBAS-4428 URL: http://jira.jboss.com/jira/browse/JBAS-4428 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: JBossAS-4.0.5.GA Environment: Windows XP and Unisys MCP system Reporter: Stephen Burdeau When running the testsuite test org.jboss.test.cluster.test.ScopedSetTriggerTestCase, the test fails on the following assertion: junit.framework.ComparisonFailure: Attributes should be the same expected:<...Ben...> but was:<...Joe...> at org.jboss.test.cluster.test.ScopedSetTriggerTestCase.testNonPrimitiveModify(ScopedSetTriggerTestCase.java:94) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.extensions.TestSetup.run(TestSetup.java:23) This failure occurs when running on the Unisys MCP system, which demonstrates different timings than when running on a system like Windows. After analyzing the results and the code, the following appears to be the root cause of the test failure: org.jboss.web.tomcat.tc5.session.ClusteredSession has a method calcMaxUnreplicatedInterval that is used to calculate maxUnreplicatedInterval. maxUnreplicatedInterval is the maximum time interval before a session is replicated to the other cluster nodes. When this time period is exceeded, the session is replicated even if the session is not "dirty". maxUnreplicatedInterval is in milliseconds, but maxInactiveInterval is in seconds. However, calcMaxUnreplicatedInterval computes maxUnreplicatedInterval as follows: maxUnreplicatedInterval = maxInactiveInterval * maxUnreplicatedFactor / 100; where maxUnreplicatedFactor is 80. Since maxInactiveInterval is in seconds, the correct computation should be: maxUnreplicatedInterval = maxInactiveInterval * 1000 * maxUnreplicatedFactor / 100; As a result of the incorrect computation of maxUnreplicatedInterval, the session is automatically replicated much more often than was intended. In this case, the session timeout was configured as 30 minutes or 1800 seconds. So, maxUnreplicatedInterval becomes 1440 milliseconds. Therefore, if the test takes more than about a second and a half to run, the test will not produce the expected results. -- 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, 10 months

2
2
0 / 0

[JBoss JIRA] Created: (JBAS-4380) Deployers are not working when deploying/undeploying different JARS with the same name

by Clebert Suconic (JIRA)

Deployers are not working when deploying/undeploying different JARS with the same name -------------------------------------------------------------------------------------- Key: JBAS-4380 URL: http://jira.jboss.com/jira/browse/JBAS-4380 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: ClassLoading Affects Versions: JBossAS-5.0.0.Beta3 Reporter: Clebert Suconic Assigned To: Scott M Stark Priority: Blocker Fix For: JBossAS-5.0.0.Beta3 Suppose you have two distinct jars with the same name.. You deploy the first one (using deployers on JMX) and undeploy it. You deploy the second one (using deployers on JMX again)... you will get an exception... and the first jar will be deployed sometimes, as something is cached somewhere. (I will add a replication test for this issue, and a description for how to do it) -- 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, 10 months

2
5
0 / 0

[JBoss JIRA] Created: (JGRP-504) Support direct injection of MBeanServer into JChannelFactory

by Brian Stansberry (JIRA)

Support direct injection of MBeanServer into JChannelFactory ------------------------------------------------------------ Key: JGRP-504 URL: http://jira.jboss.com/jira/browse/JGRP-504 Project: JGroups Issue Type: Feature Request Reporter: Brian Stansberry Assigned To: Brian Stansberry Priority: Minor Currently org.jgroups.JChannelFactory finds the MBeanServer it should use via a "discovery" algorithm that will: 1) Use the server registered as "jboss" if one exists 2) Else use the first mbean server found, which will be the platform mbean server in a JDK env. This will break if the target mbean server isn't the platform mbean server and isn't named "jboss". I don't see any reason org.jgroups.JChannelFactory can't expose a setter for this. The usage for this would be: The org.jgroups.jmx.JChannelFactory class should implement javax.management.MBeanRegistration. This is the object that external code (e.g. microcontainer or AS 4.x ServiceController, or custom user code) initially registers in JMX. Via the MBeanRegistration.preRegister(MBeanServer server, ObjectName name) callback the org.jgroups.jmx.JChannelFactory is made aware of exactly what mbean server is being used. The org.jgroups.jmx.JChannelFactory then passes this into the org.jgroups.JChannelFactory via the setter. -- 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, 10 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 May 2007