November 2006 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBREM-549) remove dependancy on concurrent.jar within remoting client

by Tom Elrod (JIRA)

remove dependancy on concurrent.jar within remoting client ---------------------------------------------------------- Key: JBREM-549 URL: http://jira.jboss.com/jira/browse/JBREM-549 Project: JBoss Remoting Issue Type: Task Security Level: Public (Everyone can see) Components: general Affects Versions: 2.0.0.Beta2 (Boon) Reporter: Tom Elrod Assigned To: Tom Elrod Fix For: 2.0.0.CR1 (Boon) Currently, the remoting clients will require concurrent.jar to be on the classpath because org.jboss.util.id.GUID is used to create the client session id. Problem is that org.jboss.util.id.GUID is what requires concurrent.jar. So will either need to modify the code within jboss common repository or find another class to use for generating the client session id. java.lang.NoClassDefFoundError: EDU/oswego/cs/dl/util/concurrent/SynchronizedLong at org.jboss.util.id.UID.<clinit>(UID.java:56) at org.jboss.util.id.VMID.create(VMID.java:259) at org.jboss.util.id.VMID.getInstance(VMID.java:223) at org.jboss.util.id.GUID.<init>(GUID.java:65) at org.jboss.remoting.Client.<init>(Client.java:133) at org.jboss.remoting.Client.<init>(Client.java:210) at org.jboss.remoting.Client.<init>(Client.java:191) at org.jboss.test.remoting.transport.InvokerClientTest.init(InvokerClientTest.java:80) -- 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, 1 month

3
12
0 / 0

[JBoss JIRA] Created: (JBREM-577) Investigate failure of org.jboss.test.remoting.transport.multiplex.MultiplexInvokerTestCase, jdk 1.4, on cruisecontrol

by Ron Sigal (JIRA)

Investigate failure of org.jboss.test.remoting.transport.multiplex.MultiplexInvokerTestCase, jdk 1.4, on cruisecontrol ---------------------------------------------------------------------------------------------------------------------- Key: JBREM-577 URL: http://jira.jboss.com/jira/browse/JBREM-577 Project: JBoss Remoting Issue Type: Task Security Level: Public (Everyone can see) Affects Versions: 2.0.0.GA (Boon) Reporter: Ron Sigal Assigned To: Ron Sigal Fix For: 2.0.0.GA (Boon) This test is failing rather consistently in testRule4ServerFirst() on cruisecontrol, even though this particular failure can't be reproduced on any other environment. In case the problem is more than environmental, i.e., a real problem in Multiplex, some additional log statements will be added to MultiplexServerInvoker and OutputMultiplexor. What is happening is that in runPushCallbackTests(), the message "stopped callback Connector" appears, but then the test dies before the callback Connector completes its shut down. It would be nice to believe that there is a deadlock, but none is evident, unless it's due to a problem with Collections.synchronizedMap in jdk 1.4. Note that this problem never occurs in the jdk 1.5 cruisecontrol tests. -- 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, 1 month

3
10
0 / 0

[JBoss JIRA] Created: (JBREM-639) Allow stream factory to specified for all transports

by Tim Fox (JIRA)

Allow stream factory to specified for all transports ---------------------------------------------------- Key: JBREM-639 URL: http://jira.jboss.com/jira/browse/JBREM-639 Project: JBoss Remoting Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: Tim Fox Assigned To: Tom Elrod Normally marshallers will receive the raw underlying transport Input/OuputStream. In some cases we want to wrap this in a different stream, e.g.in the case of JBossMessaging we want this wrapped in a DataInput/DataOutputStream. This is accomplished by specifiying a new Client/ServerSocketWrapper in the socket transport URI params which creates the DataInput/OutputStream. This works fine for the socket transport, but does not work for other transports which do not use SocketWrappers. E.g. JBM needs to use the HTTP transport too, and needs the underlying stream wrapped in a DataOutput/InputStream. The current remoting implementation will pass in the underlying stream to the marshaller when the HTTP transport is used, which means we have create and wrap a new DataInput/OuputStream on each invocation request and response which may have performance implications. Suggestion is to allow a InputStream/OuputStream factory to be specified for ANY transport, not just the socket transport. This would allow how streams are wrapped to be determined in a much more consistent way. Suggestion is to allow the stream factory to be specified in the URI params, e.g. &streamFactoryClass=org.jboss.tim.MyStreamFactory, and this to be allowed for any transport. If factory is not specified then raw stream is passed into marshaller. -- 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, 1 month

3
12
0 / 0

[JBoss JIRA] Created: (JBREM-554) Let virtual MultiplexServerInvokers share master MultiplexServerInvoker's thread pool.

by Ron Sigal (JIRA)

Let virtual MultiplexServerInvokers share master MultiplexServerInvoker's thread pool. -------------------------------------------------------------------------------------- Key: JBREM-554 URL: http://jira.jboss.com/jira/browse/JBREM-554 Project: JBoss Remoting Issue Type: Task Security Level: Public (Everyone can see) Affects Versions: 2.2.0.Beta1 (Bluto) Reporter: Ron Sigal Assigned To: Ron Sigal Fix For: 2.2.0.Beta1 (Bluto) This is JBREM-402, broken out from JBREM-390. -- 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, 1 month

3
8
0 / 0

[JBoss JIRA] Created: (JBREM-599) remoting doc does not cover enabling or configuring leasing from the client side

by Tom Elrod (JIRA)

remoting doc does not cover enabling or configuring leasing from the client side -------------------------------------------------------------------------------- Key: JBREM-599 URL: http://jira.jboss.com/jira/browse/JBREM-599 Project: JBoss Remoting Issue Type: Task Security Level: Public (Everyone can see) Components: docs Affects Versions: 2.0.0.GA (Boon) Reporter: Tom Elrod Assigned To: Tom Elrod Priority: Minor Fix For: 2.2.0.Beta1 (Bluto) -- 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, 2 months

2
5
0 / 0

[JBoss JIRA] Created: (EJBTHREE-799) Remove EJBTHREE-798 workaround once issue is fixed in Hibernate

by Brian Stansberry (JIRA)

Remove EJBTHREE-798 workaround once issue is fixed in Hibernate --------------------------------------------------------------- Key: EJBTHREE-799 URL: http://jira.jboss.com/jira/browse/EJBTHREE-799 Project: EJB 3.0 Issue Type: Sub-task Components: Clustering Reporter: Brian Stansberry Assigned To: Brian Stansberry Fix For: EJB 3.0 RC10 - 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

18 years, 2 months

3
4
0 / 0

[JBoss JIRA] Created: (JBAS-3877) The JMX HtmlAdaptor does not display the exception message

by Lior Shamir (JIRA)

The JMX HtmlAdaptor does not display the exception message ---------------------------------------------------------- Key: JBAS-3877 URL: http://jira.jboss.com/jira/browse/JBAS-3877 Project: JBoss Application Server Issue Type: Feature Request Security Level: Public (Everyone can see) Components: JMX Affects Versions: JBossAS-4.0.4.GA Reporter: Lior Shamir Assigned To: Scott M Stark Priority: Minor In JBoss 3.2.x when exception occurred, the HtmlAdaptor display the exception message. In JBoss 4.0.x the HtmlAdaptor display only a generic error message. This is obviously a regression. Can you add the message back? Here is an example: 4.0.4: javax.servlet.ServletException: Failed to invoke operation org.jboss.jmx.adaptor.html.HtmlAdaptorServlet.invokeOp(HtmlAdaptorServlet.java:269) org.jboss.jmx.adaptor.html.HtmlAdaptorServlet.processRequest(HtmlAdaptorServlet.java:100) org.jboss.jmx.adaptor.html.HtmlAdaptorServlet.doPost(HtmlAdaptorServlet.java:82) javax.servlet.http.HttpServlet.service(HttpServlet.java:717) javax.servlet.http.HttpServlet.service(HttpServlet.java:810) org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96) root cause javax.management.MBeanException org.jboss.mx.interceptor.ReflectedDispatcher.handleInvocationExceptions(ReflectedDispatcher.java:180) org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:163) org.jboss.mx.server.Invocation.dispatch(Invocation.java:94) org.jboss.mx.server.Invocation.invoke(Invocation.java:86) org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264) org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659) org.jboss.jmx.adaptor.control.Server.invokeOpByName(Server.java:258) org.jboss.jmx.adaptor.control.Server.invokeOp(Server.java:223) org.jboss.jmx.adaptor.html.HtmlAdaptorServlet.invokeOp(HtmlAdaptorServlet.java:262) org.jboss.jmx.adaptor.html.HtmlAdaptorServlet.processRequest(HtmlAdaptorServlet.java:100) org.jboss.jmx.adaptor.html.HtmlAdaptorServlet.doPost(HtmlAdaptorServlet.java:82) javax.servlet.http.HttpServlet.service(HttpServlet.java:717) javax.servlet.http.HttpServlet.service(HttpServlet.java:810) org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96) 3.2.6: javax.servlet.ServletException: Failed to invoke operation org.jboss.jmx.adaptor.html.HtmlAdaptorServlet.invokeOp(HtmlAdaptorServlet.java:248) org.jboss.jmx.adaptor.html.HtmlAdaptorServlet.processRequest(HtmlAdaptorServlet.java:79) org.jboss.jmx.adaptor.html.HtmlAdaptorServlet.doPost(HtmlAdaptorServlet.java:61) javax.servlet.http.HttpServlet.service(HttpServlet.java:717) javax.servlet.http.HttpServlet.service(HttpServlet.java:810) org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:75) root cause MBeanException: com.koko.KOKOException: Invalid type Cause: com.koko.KOKOException: Invalid type org.jboss.mx.server.ReflectedDispatcher.handleInvocationExceptions(ReflectedDispatcher.java:91) org.jboss.mx.server.ReflectedDispatcher.dispatch(ReflectedDispatcher.java:64) org.jboss.mx.server.Invocation.dispatch(Invocation.java:62) org.jboss.mx.server.Invocation.dispatch(Invocation.java:54) org.jboss.mx.server.Invocation.invoke(Invocation.java:82) org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:197) org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:473) org.jboss.jmx.adaptor.control.Server.invokeOpByName(Server.java:236) org.jboss.jmx.adaptor.control.Server.invokeOp(Server.java:202) org.jboss.jmx.adaptor.html.HtmlAdaptorServlet.invokeOp(HtmlAdaptorServlet.java:241) org.jboss.jmx.adaptor.html.HtmlAdaptorServlet.processRequest(HtmlAdaptorServlet.java:79) org.jboss.jmx.adaptor.html.HtmlAdaptorServlet.doPost(HtmlAdaptorServlet.java:61) javax.servlet.http.HttpServlet.service(HttpServlet.java:717) javax.servlet.http.HttpServlet.service(HttpServlet.java:810) org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:75) -- 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, 2 months

2
1
0 / 0

[JBoss JIRA] Created: (EJBTHREE-790) Include partition name in cluster name of caches

by Ortwin Glück (JIRA)

Include partition name in cluster name of caches ------------------------------------------------ Key: EJBTHREE-790 URL: http://jira.jboss.com/jira/browse/EJBTHREE-790 Project: EJB 3.0 Issue Type: Bug Components: Clustering Affects Versions: EJB 3.0 RC8 - FD Reporter: Ortwin Glück For ejb3-entity-cache-service.xml and ejb3-clustered-sfsbcache-service.xml the ClusterName should include the partition name. Here is why: We have 3 test instances and the two production cluster nodes within the same subnet (VLAN). The test instances have unique partition names (TEST1, TEST2, TEST3) and the production nodes share a common partition name (PROD). In the default configuration all five nodes would form a cluster for the entity and SFSB clusters. This would severely disrupt data consistency! We have solved this by including the partition name in the cluster name in the cache MBeans: <attribute name="ClusterName">EJB3-entity-cache-${jboss.partition.name:DefaultPartition}</attribute> -- 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, 2 months

4
7
0 / 0

[JBoss JIRA] Created: (JBAS-3707) HA/Failover RAR Functionality should be implemented in non-HA RARS.

by Weston Price (JIRA)

HA/Failover RAR Functionality should be implemented in non-HA RARS. ------------------------------------------------------------------- Key: JBAS-3707 URL: http://jira.jboss.com/jira/browse/JBAS-3707 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Affects Versions: JBossAS-4.0.6.CR1 Reporter: Weston Price Assigned To: Weston Price Priority: Optional The HA/DB failover functionality for JDBC RARs currently exists in seperated deployments (ha/xa rars). This functionality should be put into the regular RARs as a deployment option and not as a standalone configuration which is unnecessary. -- 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, 2 months

4
6
0 / 0

[JBoss JIRA] Created: (EJBTHREE-698) Exception serialization issue when remotely accessing stateless session bean

by David Green (JIRA)

Exception serialization issue when remotely accessing stateless session bean ---------------------------------------------------------------------------- Key: EJBTHREE-698 URL: http://jira.jboss.com/jira/browse/EJBTHREE-698 Project: EJB 3.0 Issue Type: Bug Reporter: David Green Accessing a remote EJB (Session bean) results in exception. Stack trace follows: 13:54:39,546 ERROR [SocketClientInvoker] Got marshalling exception, exiting java.lang.ClassNotFoundException: [Ljava.lang.StackTraceElement; at java.net.URLClassLoader$1.run(URLClassLoader.java:200) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:188) at java.lang.ClassLoader.loadClass(ClassLoader.java:306) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:276) at java.lang.ClassLoader.loadClass(ClassLoader.java:251) at org.jboss.remoting.loading.RemotingClassLoader.loadClass(RemotingClassLoader.java:50) at org.jboss.remoting.loading.ObjectInputStreamWithClassLoader.resolveClass(ObjectInputStreamWithClassLoader.java:139) at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1575) at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1496) at java.io.ObjectInputStream.readArray(ObjectInputStream.java:1624) at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1323) at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1945) at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1869) at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753) at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329) at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1945) at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1869) at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753) at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351) at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObject(JavaSerializationManager.java:128) at org.jboss.remoting.marshal.serializable.SerializableUnMarshaller.read(SerializableUnMarshaller.java:66) at org.jboss.remoting.transport.socket.SocketClientInvoker.transport(SocketClientInvoker.java:279) at org.jboss.remoting.RemoteClientInvoker.invoke(RemoteClientInvoker.java:143) at org.jboss.remoting.Client.invoke(Client.java:525) at org.jboss.remoting.Client.invoke(Client.java:488) at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:55) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101) at org.jboss.aspects.tx.ClientTxPropagationInterceptor.invoke(ClientTxPropagationInterceptor.java:61) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101) at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:55) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101) at org.jboss.ejb3.remoting.IsLocalInterceptor.invoke(IsLocalInterceptor.java:65) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101) at org.jboss.ejb3.stateless.StatelessRemoteProxy.invoke(StatelessRemoteProxy.java:102) at $Proxy0.postNotification(Unknown Source) at com.hgea.hch.service.HchClientDelegate.postNotification(HchClientDelegate.java:99) at com.hgea.hch.client.RemoteHchClientTest.testRemotePostNotification(RemoteHchClientTest.java:38) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at junit.framework.TestCase.runTest(TestCase.java:154) at junit.framework.TestCase.runBare(TestCase.java:127) at junit.framework.TestResult$1.protect(TestResult.java:106) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.framework.TestResult.run(TestResult.java:109) at junit.framework.TestCase.run(TestCase.java:118) at junit.framework.TestSuite.runTest(TestSuite.java:208) at junit.framework.TestSuite.run(TestSuite.java:203) at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:297) at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.launch(JUnitTestRunner.java:672) at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main(JUnitTestRunner.java:567) -- 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, 2 months

7
7
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 November 2006