April 2008 - jboss-remoting-issues

[JBoss JIRA] Created: (JBREM-954) InterruptException should not be rethrown as CannotConnectionException

by Galder Zamarreno (JIRA)

InterruptException should not be rethrown as CannotConnectionException ---------------------------------------------------------------------- Key: JBREM-954 URL: http://jira.jboss.com/jira/browse/JBREM-954 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Components: transport Reporter: Galder Zamarreno Fix For: 2.2.2.SP4 Let's say you have a Swing GUI application that calls an EJB remotely and the client code is waiting to get entry to client side pool (controlled by clientMaxPoolSize). While waiting, the user decides to cancel the operation by interrupting the thread. In that case, the Remoting code does not make a difference between an InterruptedException and any other Exception: MicroSocketClientInvoker.java: protected SocketWrapper getConnection(Marshaller marshaller, UnMarshaller unmarshaller, int timeAllowed) throws Exception { long start = System.currentTimeMillis(); long timeToWait = (timeAllowed > 0) ? timeAllowed : 30000; boolean timedout = !semaphore.attempt(timeToWait); Any Exception thrown from getConnection() is treated as a CannotConnectException try { socketWrapper = getConnection(marshaller, unmarshaller, timeLeft); } catch (Exception e) { // if (bailOut) // return null; semaphore.release(); if (trace) log.trace(this + " released semaphore: " + semaphore.permits()); throw new CannotConnectException( "Can not get connection to server. Problem establishing " + "socket connection for " + locator, e); } The EJB3 layer wraps this in CannotConnectException in a RuntimeException like: throw new RuntimeException("cluster invocation failed, last exception was: ", lastException); This is misleading on the Remoting side. Semantically, the fact that the thread attempting to connect is interrupted shouldn't be translated into a CannotConnectException. Please find attached a test case I've created. -- 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, 5 months

2
22
0 / 0

[JBoss JIRA] Created: (JBREM-959) CLONE [JBREM-920] - Create build.xml target to run test suite with a Security Manager

by Ron Sigal (JIRA)

CLONE [JBREM-920] - Create build.xml target to run test suite with a Security Manager ------------------------------------------------------------------------------------- Key: JBREM-959 URL: http://jira.jboss.com/jira/browse/JBREM-959 Project: JBoss Remoting Issue Type: Task Security Level: Public (Everyone can see) Reporter: Ron Sigal Assigned To: David Lloyd Fix For: 2.4.0.GA >From Anil Saldana: Presuming that you have a test suite and either use ANT or Maven, I recommend an extra target to run the test suite in a Java Security Manager with minimal permissions. So for ANT, you will have an additional target. For MAVEN, you can use a profile. The idea is that you have a Java Security Policy file in which you provide unlimited permission to third party libraries and minimal permissions to your own code. This exercise is to detect critical sections of code that need special privileges and get into privileged blocks. If you have an extra target for the security manager and your test runs happen on hudson, you can detect issues with security manager as new code gets added. Please do not have one test that does System.setSecurityManager but run your entire test suite via the security manager (-Djava.security.manager -Djava.security.policy=somefile). Example: (Take a look by clicking "Configure" on the LHS) http://hudson.qa.jboss.com/hudson/job/JBossSX_SecurityManager/ http://anonsvn.jboss.org/repos/jbossas/projects/security/security-jboss-s... Now if your head is spinning or you do not care about security or do not have the time to do it, please tell me. I can engage myself, someone from JBoss Security Team or the QA person handling your project to add a JIRA issue (and make the build.xml/pom.xml changes for your project). Why is this important? * Because many customers run JBAS in a security manager and we need to detect issues in our own code. Also during a recent integration work with JBoss Messaging for the SOA platform, there was one issue with remoting (JBREM-811) that gave some head ache to Clebert and Ron (who is still reeling). It took some cycles from me also. * We need to have tests running in a security manager on an ongoing basis. I understand that there are resource issues in various projects. But that does not discount the work that we need to do before we ship JBAS. ;) -- 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, 5 months

1
2
0 / 0

[JBoss JIRA] Created: (JBREM-958) CLONE -Put code subject to a security manager in privileged blocks

by Ron Sigal (JIRA)

CLONE -Put code subject to a security manager in privileged blocks ------------------------------------------------------------------ Key: JBREM-958 URL: http://jira.jboss.com/jira/browse/JBREM-958 Project: JBoss Remoting Issue Type: Task Security Level: Public (Everyone can see) Reporter: Ron Sigal Assigned To: Ron Sigal Priority: Critical Fix For: 2.4.0.GA To run in a the Application Server, which might be run in a security manager, Remoting code must wrap all code that needs security privileges in AccessController.doPrivileged() calls. -- 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, 5 months

1
2
0 / 0

[JBoss JIRA] Created: (JBREM-960) Remoting configured with Servlet invoker can return misleading Exceptions when Servlet path is incorrect

by Galder Zamarreno (JIRA)

Remoting configured with Servlet invoker can return misleading Exceptions when Servlet path is incorrect -------------------------------------------------------------------------------------------------------- Key: JBREM-960 URL: http://jira.jboss.com/jira/browse/JBREM-960 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Components: transport Affects Versions: 2.4.0.GA, 2.2.2.SP8, 2.4.1.Beta Reporter: Galder Zamarreno Assigned To: Galder Zamarreno I've been struggling to set up a ServletInvoker in Remoting to be able to use the unified invoker to talk to EJB2 beans in AS/EAP 4.x. I had the Connector set up like this: <mbean code="org.jboss.remoting.transport.Connector" name="jboss.remoting:service=connector,transport=servlet" display-name="Servlet transport Connector"> <attribute name="Configuration"> <config> <invoker transport="servlet"> <attribute name="dataType" isParam="true">invocation</attribute> <attribute name="marshaller" isParam="true">org.jboss.invocation.unified.marshall.InvocationMarshaller</attribute> <attribute name="unmarshaller" isParam="true">org.jboss.invocation.unified.marshall.InvocationUnMarshaller</attribute> <attribute name="serverBindAddress">${jboss.bind.address}</attribute> <attribute name="serverBindPort">8080</attribute> <attribute name="path">unified-http-invoker/ServerInvokerServlet</attribute> </invoker> <handlers> <handler subsystem="invoker">jboss:service=invoker,type=unified-http</handler> </handlers> </config> </attribute> </mbean> But the path attribute was incorrect. Remoting was coming back with something like this: org.jboss.remoting.CannotConnectException: Can not connect http client invoker. at org.jboss.remoting.transport.http.HTTPClientInvoker.useHttpURLConnection(HTTPClientInvoker.java:333) at org.jboss.remoting.transport.http.HTTPClientInvoker.transport(HTTPClientInvoker.java:135) at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:122) at org.jboss.remoting.Client.invoke(Client.java:1634) at org.jboss.remoting.Client.invoke(Client.java:548) at org.jboss.invocation.unified.interfaces.UnifiedInvokerProxy.invoke(UnifiedInvokerProxy.java:183) at org.jboss.invocation.InvokerInterceptor.invokeInvoker(InvokerInterceptor.java:365) at org.jboss.invocation.InvokerInterceptor.invoke(InvokerInterceptor.java:197) at org.jboss.proxy.TransactionInterceptor.invoke(TransactionInterceptor.java:61) at org.jboss.proxy.SecurityInterceptor.invoke(SecurityInterceptor.java:70) at org.jboss.proxy.ejb.HomeInterceptor.invoke(HomeInterceptor.java:184) at org.jboss.proxy.ClientContainer.invoke(ClientContainer.java:100) at $Proxy0.create(Unknown Source) at com.acme.ejb2.slsb.TimerEnquirerHttpTest.test000(TimerEnquirerHttpTest.java:34) 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:585) at junit.framework.TestCase.runTest(TestCase.java:164) at junit.framework.TestCase.runBare(TestCase.java:130) 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:120) at junit.framework.TestSuite.runTest(TestSuite.java:230) at junit.framework.TestSuite.run(TestSuite.java:225) at org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:130) at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196) Caused by: java.io.StreamCorruptedException: invalid stream header at java.io.ObjectInputStream.readStreamHeader(ObjectInputStream.java:764) at java.io.ObjectInputStream.<init>(ObjectInputStream.java:277) at org.jboss.remoting.loading.ObjectInputStreamWithClassLoader.<init>(ObjectInputStreamWithClassLoader.java:95) at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.createInput(JavaSerializationManager.java:54) at org.jboss.remoting.marshal.serializable.SerializableUnMarshaller.getMarshallingStream(SerializableUnMarshaller.java:72) at org.jboss.remoting.marshal.serializable.SerializableUnMarshaller.read(SerializableUnMarshaller.java:119) at org.jboss.invocation.unified.marshall.InvocationUnMarshaller.read(InvocationUnMarshaller.java:59) at org.jboss.remoting.transport.http.HTTPClientInvoker.readResponse(HTTPClientInvoker.java:471) at org.jboss.remoting.transport.http.HTTPClientInvoker.useHttpURLConnection(HTTPClientInvoker.java:305) ... 31 more Now, to get this Exception is very misleading. It generally means that either you have different client and server side Remoting versions, or you're using different serialization methods on either side. Once I started to dig into what Remoting was doing, I spotted HTTPClientInvoker does the following in useHttpURLConnection() method: if (sendingData) { //POST or PUT conn.setDoOutput(true); conn.setDoInput(true); conn.setRequestMethod(type); OutputStream stream = conn.getOutputStream(); if (marshaller instanceof VersionedMarshaller) ((VersionedMarshaller) marshaller).write(invocation, stream, Version.getDefaultVersion()); else marshaller.write(invocation, stream); responseCode = conn.getResponseCode(); InputStream is = (responseCode < 400) ? conn.getInputStream() : conn.getErrorStream(); Map headers = conn.getHeaderFields(); if (metadata == null) { metadata = new HashMap(); } // sometimes I get headers with "null" keys (I don't know who's fault is it), so I need // to clean the header map, unless I want to get an NPE thrown by metadata.putAll() if (headers != null) { for(Iterator i = headers.entrySet().iterator(); i.hasNext(); ) { Map.Entry e = (Map.Entry)i.next(); if (e.getKey() != null) { metadata.put(e.getKey(), e.getValue()); } } } metadata.put(HTTPMetadataConstants.RESPONSE_CODE_MESSAGE, conn.getResponseMessage()); metadata.put(HTTPMetadataConstants.RESPONSE_CODE, new Integer(responseCode)); result = readResponse(metadata, headers, unmarshaller, is); } The Exception reported is coming from readResponse() but before that if the Servlet was not available, like in my case, conn.getResponseCode() was returning 404. Remoting code should check what the response code was, whether this is an invalid code, i.e. does not exist...etc, and throw an Exception if invalid, like in this case, giving the caller much better clue of what is going on. Thoughts? -- 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, 5 months

2
10
0 / 0

[JBoss JIRA] Created: (JBREM-965) Fix PortUtil.getRandomStartingPort()

by Ron Sigal (JIRA)

Fix PortUtil.getRandomStartingPort() ------------------------------------ Key: JBREM-965 URL: http://jira.jboss.com/jira/browse/JBREM-965 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.2.2.SP7 Reporter: Ron Sigal Assigned To: Ron Sigal Fix For: 2.2.2.SP8 >From support case 176016: Description: While starting JBoss using the "all" configuration we get the following error message: "Problem starting service jboss.messaging:service=Connector,transport=bisocket". Followed in the stack trace by the error: "Caused by: java.lang.NumberFormatException: For input string: "add46e5e"". The JBoss messaging service does not start which prevents other JBoss services from being deployed. Walking through the following stack trace: 2008-04-16 09:29:46,160 WARN [org.jboss.system.ServiceController] Problem starting service jboss.messaging:service=Connector,transport=bisocket java.lang.ExceptionInInitializerError at org.jboss.remoting.transport.bisocket.BisocketServerInvoker.start(BisocketS erverInvoker.java:182) at org.jboss.remoting.transport.Connector.start(Connector.java:322) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:3 9) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImp l.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.jav a:155) at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94) at org.jboss.mx.server.Invocation.invoke(Invocation.java:86) at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:2 64) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659) at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.ja va:995) at $Proxy0.start(Unknown Source) at org.jboss.system.ServiceController.start(ServiceController.java:417) at sun.reflect.GeneratedMethodAccessor8.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImp l.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.jav a:155) at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94) at org.jboss.mx.server.Invocation.invoke(Invocation.java:86) at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:2 64) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659) at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210) at $Proxy4.start(Unknown Source) at org.jboss.deployment.SARDeployer.start(SARDeployer.java:302) at org.jboss.deployment.MainDeployer.start(MainDeployer.java:1025) at org.jboss.deployment.MainDeployer.start(MainDeployer.java:1015) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:819) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:782) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:3 9) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImp l.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.jav a:155) at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94) at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.jav a:133) at org.jboss.mx.server.Invocation.invoke(Invocation.java:88) at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOp erationInterceptor.java:142) at org.jboss.mx.server.Invocation.invoke(Invocation.java:88) at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:2 64) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659) at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210) at $Proxy9.deploy(Unknown Source) at org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymentScann er.java:421) at org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentScanner .java:634) at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.doScan (AbstractDeploymentScanner.java:263) at org.jboss.deployment.scanner.AbstractDeploymentScanner.startService(Abstrac tDeploymentScanner.java:336) at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport .java:289) at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSup port.java:245) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:3 9) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImp l.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.jav a:155) at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94) at org.jboss.mx.server.Invocation.invoke(Invocation.java:86) at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:2 64) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659) at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.ja va:978) at $Proxy0.start(Unknown Source) at org.jboss.system.ServiceController.start(ServiceController.java:417) at sun.reflect.GeneratedMethodAccessor8.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImp l.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.jav a:155) at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94) at org.jboss.mx.server.Invocation.invoke(Invocation.java:86) at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:2 64) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659) at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210) at $Proxy4.start(Unknown Source) at org.jboss.deployment.SARDeployer.start(SARDeployer.java:302) at org.jboss.deployment.MainDeployer.start(MainDeployer.java:1025) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:819) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:782) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:766) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:3 9) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImp l.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.jav a:155) at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94) at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.jav a:133) at org.jboss.mx.server.Invocation.invoke(Invocation.java:88) at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOp erationInterceptor.java:142) at org.jboss.mx.server.Invocation.invoke(Invocation.java:88) at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:2 64) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659) at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210) at $Proxy5.deploy(Unknown Source) at org.jboss.system.server.ServerImpl.doStart(ServerImpl.java:533) at org.jboss.system.server.ServerImpl.start(ServerImpl.java:399) at org.jboss.Main.boot(Main.java:200) at org.jboss.Main$1.run(Main.java:508) at java.lang.Thread.run(Thread.java:602) Caused by: java.lang.NumberFormatException: For input string: "add46e5e" at java.lang.Throwable.<init>(Throwable.java:196) at java.lang.Exception.<init>(Exception.java:41) at java.lang.RuntimeException.<init>(RuntimeException.java:43) at java.lang.IllegalArgumentException.<init>(IllegalArgumentException.ja va:36) at java.lang.NumberFormatException.<init>(NumberFormatException.java:38) at java.lang.NumberFormatException.forInputString(NumberFormatException.java:4 8) at java.lang.Integer.parseInt(Integer.java:459) at org.jboss.remoting.transport.PortUtil.getRandomStartingPort(PortUtil.java:1 47) at org.jboss.remoting.transport.PortUtil.<clinit>(PortUtil.java:49) Gets us to the method "getRandomStartingPort" in the class "PortUtil" in the package "org.jboss.remoting.transport". Which is part of the "jboss-remoting.jar" in the directory jboss430/thirdparty/jboss/remoting/lib. The existing code that is failing is: public static int getRandomStartingPort() { Object o = new Object(); String os = o.toString(); os = os.substring(17); int n = Integer.parseInt(os, 16); int p = Math.abs(new SecureRandom(String.valueOf(System.currentTimeMillis() + n).getBytes()).nextInt(2000)) + 2000; return p; } The issue with this code is that, what an object returns for toString() is platform- and JVM-specific and never guaranteed to be parseable as an integer. There's also no guarantee that toString() will produce anything that's at least 17 characters long. The only time the output of toString() is defined is for instances of java.lang.Object; pretty much all classes override that method. Besides the hard-coding of the 17 in the code is rather naive, converting the hex string suffers from the fact that it may be representing a negative number. The parseInt() method allows only 31 bits of magnitude for the string, since the sign must be given externally (leading '+' or '-', with '+' being the default). In many JVM implementations, the hashCode() method for non-String objects returns a value based on the allocation address of the object. For 32-bit systems, such an address is almost always under the 2 GB boundary, and therefore positive. For architectures that use more than 32 bits for an address (including the Unisys OS 2200), there's no guarantee of any particular sign of the result. We propose that the code be changed to the following: public static int getRandomStartingPort() { int n = new Object().hashCode(); int p = Math.abs(new SecureRandom(String.valueOf(System.currentTimeMillis() + n).getBytes()).nextInt(2000)) + 2000; return p; } -- 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, 5 months

1
3
0 / 0

[JBoss JIRA] Created: (JBREM-930) Fix chronic testsuite failures

by Ron Sigal (JIRA)

Fix chronic testsuite failures ------------------------------ Key: JBREM-930 URL: http://jira.jboss.com/jira/browse/JBREM-930 Project: JBoss Remoting Issue Type: Task Security Level: Public (Everyone can see) Reporter: Ron Sigal Assigned To: Ron Sigal Fix For: 2.4.0.CR1 (Pinto) Several tests fail either always or intermittently: Always: * org.jboss.test.remoting.marshall.http.metadata.HTTPUnMarshallerMetadataTestCase * org.jboss.test.remoting.transport.http.proxy.HTTPInvokerProxyTestCase * org.jboss.test.remoting.transport.http.raw.HTTPInvokerTestCase Intermittently: * org.jboss.test.remoting.deploy.DualDeploymentTestCase * org.jboss.test.remoting.transport.http.keep_alive.StressHTTPInvokerTestCase -- 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, 6 months

1
2
0 / 0

[JBoss JIRA] Updated: (JBREM-908) Make stream detectors pluggable

by David Lloyd (JIRA)

[ http://jira.jboss.com/jira/browse/JBREM-908?page=all ] David Lloyd updated JBREM-908: ------------------------------ Fix Version/s: 3.1.0.GA (was: 3.0.0-M3) Changing to 3.1. This is a non-essential feature; the defaults will be sufficient for the basic use cases, at least for a 3.0 release. > Make stream detectors pluggable > ------------------------------- > > Key: JBREM-908 > URL: http://jira.jboss.com/jira/browse/JBREM-908 > Project: JBoss Remoting > Issue Type: Task > Security Level: Public(Everyone can see) > Components: r3 core, r3 api > Reporter: David Lloyd > Fix For: 3.1.0.GA > > > Right now there's just a fixed singleton list with just the default detector. See org.jboss.cx.remoting.core.CoreSession. -- 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, 7 months

1
0
0 / 0

[JBoss JIRA] Created: (JBREM-968) Release 2.4.0.CR2

by Ron Sigal (JIRA)

Release 2.4.0.CR2 ----------------- Key: JBREM-968 URL: http://jira.jboss.com/jira/browse/JBREM-968 Project: JBoss Remoting Issue Type: Release Security Level: Public (Everyone can see) Reporter: Ron Sigal Assigned To: Ron Sigal Fix For: 2.4.0.CR2 -- 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, 7 months

1
1
0 / 0

[JBoss JIRA] Assigned: (JBREM-920) Create build.xml target to run test suite with a Security Manager

by Ron Sigal (JIRA)

[ http://jira.jboss.com/jira/browse/JBREM-920?page=all ] Ron Sigal reassigned JBREM-920: ------------------------------- Assignee: Ron Sigal (was: David Lloyd) > Create build.xml target to run test suite with a Security Manager > ----------------------------------------------------------------- > > Key: JBREM-920 > URL: http://jira.jboss.com/jira/browse/JBREM-920 > Project: JBoss Remoting > Issue Type: Task > Security Level: Public(Everyone can see) > Reporter: Ron Sigal > Assigned To: Ron Sigal > Fix For: 2.4.0.GA > > > From Anil Saldana: > Presuming that you have a test suite and either use ANT or Maven, I > recommend an extra target to run the test suite in a Java Security > Manager with minimal permissions. So for ANT, you will have an > additional target. For MAVEN, you can use a profile. > The idea is that you have a Java Security Policy file in which you > provide unlimited permission to third party libraries and minimal > permissions to your own code. This exercise is to detect critical > sections of code that need special privileges and get into privileged > blocks. If you have an extra target for the security manager and your > test runs happen on hudson, you can detect issues with security manager > as new code gets added. > Please do not have one test that does System.setSecurityManager but run > your entire test suite via the security manager > (-Djava.security.manager -Djava.security.policy=somefile). > Example: (Take a look by clicking "Configure" on the LHS) > http://hudson.qa.jboss.com/hudson/job/JBossSX_SecurityManager/ > http://anonsvn.jboss.org/repos/jbossas/projects/security/security-jboss-s... > Now if your head is spinning or you do not care about security or do not > have the time to do it, please tell me. I can engage myself, someone > from JBoss Security Team or the QA person handling your project to add a > JIRA issue (and make the build.xml/pom.xml changes for your project). > Why is this important? > * Because many customers run JBAS in a security manager and we need to > detect issues in our own code. Also during a recent integration work > with JBoss Messaging for the SOA platform, there was one issue with > remoting (JBREM-811) that gave some head ache to Clebert and Ron (who is > still reeling). It took some cycles from me also. > * We need to have tests running in a security manager on an ongoing basis. > I understand that there are resource issues in various projects. But > that does not discount the work that we need to do before we ship JBAS. ;) -- 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, 7 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBREM-920) Create build.xml target to run test suite with a Security Manager

by Ron Sigal (JIRA)

[ http://jira.jboss.com/jira/browse/JBREM-920?page=all ] Ron Sigal updated JBREM-920: ---------------------------- Fix Version/s: 2.4.0.GA (was: 2.4.0.CR2) > Create build.xml target to run test suite with a Security Manager > ----------------------------------------------------------------- > > Key: JBREM-920 > URL: http://jira.jboss.com/jira/browse/JBREM-920 > Project: JBoss Remoting > Issue Type: Task > Security Level: Public(Everyone can see) > Reporter: Ron Sigal > Assigned To: David Lloyd > Fix For: 2.4.0.GA > > > From Anil Saldana: > Presuming that you have a test suite and either use ANT or Maven, I > recommend an extra target to run the test suite in a Java Security > Manager with minimal permissions. So for ANT, you will have an > additional target. For MAVEN, you can use a profile. > The idea is that you have a Java Security Policy file in which you > provide unlimited permission to third party libraries and minimal > permissions to your own code. This exercise is to detect critical > sections of code that need special privileges and get into privileged > blocks. If you have an extra target for the security manager and your > test runs happen on hudson, you can detect issues with security manager > as new code gets added. > Please do not have one test that does System.setSecurityManager but run > your entire test suite via the security manager > (-Djava.security.manager -Djava.security.policy=somefile). > Example: (Take a look by clicking "Configure" on the LHS) > http://hudson.qa.jboss.com/hudson/job/JBossSX_SecurityManager/ > http://anonsvn.jboss.org/repos/jbossas/projects/security/security-jboss-s... > Now if your head is spinning or you do not care about security or do not > have the time to do it, please tell me. I can engage myself, someone > from JBoss Security Team or the QA person handling your project to add a > JIRA issue (and make the build.xml/pom.xml changes for your project). > Why is this important? > * Because many customers run JBAS in a security manager and we need to > detect issues in our own code. Also during a recent integration work > with JBoss Messaging for the SOA platform, there was one issue with > remoting (JBREM-811) that gave some head ache to Clebert and Ron (who is > still reeling). It took some cycles from me also. > * We need to have tests running in a security manager on an ongoing basis. > I understand that there are resource issues in various projects. But > that does not discount the work that we need to do before we ship JBAS. ;) -- 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, 7 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

jboss-remoting-issues April 2008