[JBoss JIRA] Created: (JBREM-955) CLONE [JBREM-954] - InterruptException should not be rethrown as CannotConnectionException
by Ron Sigal (JIRA)
CLONE [JBREM-954] - InterruptException should not be rethrown as CannotConnectionException
------------------------------------------------------------------------------------------
Key: JBREM-955
URL: http://jira.jboss.com/jira/browse/JBREM-955
Project: JBoss Remoting
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: transport
Affects Versions: 2.2.2.SP4, 2.2.2.SP7
Reporter: Galder Zamarreno
Assigned To: Ron Sigal
Fix For: 2.2.2.SP8
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
15 years, 12 months
[JBoss JIRA] Created: (JBREM-966) CLONE [JBREM-965] - Fix PortUtil.getRandomStartingPort()
by Ron Sigal (JIRA)
CLONE [JBREM-965] - Fix PortUtil.getRandomStartingPort()
--------------------------------------------------------
Key: JBREM-966
URL: http://jira.jboss.com/jira/browse/JBREM-966
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
15 years, 12 months
[JBoss JIRA] Created: (JBREM-956) Client side does not detect connection drop when LeasePinger is active.
by Guy Nir (JIRA)
Client side does not detect connection drop when LeasePinger is active.
-----------------------------------------------------------------------
Key: JBREM-956
URL: http://jira.jboss.com/jira/browse/JBREM-956
Project: JBoss Remoting
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: transport
Affects Versions: 2.2.2.SP2, 2.2.2.SP1, 2.2.2.GA, 2.2.1.GA, 2.2.0.GA (Bluto)
Environment: JBoss 4.2.1, Windows XP SP2, Redhat Enterprise Linux 3.0
Reporter: Guy Nir
When a client and server resides on different machines and server suddenly disconnected from the network (i.e.: cable disconnected or host is cord-reseted/power down brutely) the client side does not recognize this situation and remains blocking.
The main reason for this behavior is that TCP does not provide direct indication that a connection is dropped (unless a probe such as KeepAlive is activated).
The LeasePinger class should resolve this issue, however, the invocation of sendClientPing() method remains blocking as well.
A different shorter timeout should be placed for sendClientPing() (perhaps timeout-per-invocation approach ?).
For example, instead of using the following implementation (taken from sendClientPing) :
Map clientsClone = new ConcurrentHashMap(clients);
Map requestClients = new ConcurrentHashMap();
requestClients.put(ClientHolder.CLIENT_HOLDER_KEY, clientsClone);
InvocationRequest ir = new InvocationRequest(invokerSessionID, null, "$PING$", requestClients, null, null);
invoker.invoke(ir);
It is possible to use:
int clientPingLeaseTimeout = ......;
Map clientsClone = new ConcurrentHashMap(clients);
Map requestClients = new ConcurrentHashMap();
requestClients.put(ClientHolder.CLIENT_HOLDER_KEY, clientsClone);
requestClients.put(ServerInvoker.TIMEOUT, clientPingLeaseTimeout);
InvocationRequest ir = new InvocationRequest(invokerSessionID, null, "$PING$", requestClients, null, null);
invoker.invoke(ir);
--
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, 12 months
[JBoss JIRA] Created: (JBREM-953) CLONE [JBREM-945] - Allow ServerThread to keep running after SocketTImeoutException
by Ron Sigal (JIRA)
CLONE [JBREM-945] - Allow ServerThread to keep running after SocketTImeoutException
-----------------------------------------------------------------------------------
Key: JBREM-953
URL: http://jira.jboss.com/jira/browse/JBREM-953
Project: JBoss Remoting
Issue Type: Task
Security Level: Public (Everyone can see)
Affects Versions: 2.2.2.SP4
Reporter: Ron Sigal
Assigned To: Ron Sigal
Priority: Minor
Fix For: 2.2.2.SP7
Currently, org.jboss.remoting.transport.socket.ServerThread will close its socket and return itself to the threadpool in the event of a SocketTimeoutException. However, it could simply continue trying to read the next invocation. The javadoc for java.net.Socket.setSoTimeout() states:
Enable/disable SO_TIMEOUT with the specified timeout, in milliseconds. With this option set to a non-zero timeout, a read() call on the InputStream associated with this Socket will block for only this amount of time. If the timeout expires, a java.net.SocketTimeoutException is raised, though the Socket is still valid.
If the timeout is due to transitory circumstances, then it would be much more efficient to allow the ServerThread to continue, rather than forcing the client to start over with a new socket.
--
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, 12 months
[JBoss JIRA] Created: (JBREM-951) CLONE [JBREM-942] - A deadlock encountered on ConnectionValidator
by Ron Sigal (JIRA)
CLONE [JBREM-942] - A deadlock encountered on ConnectionValidator
------------------------------------------------------------------
Key: JBREM-951
URL: http://jira.jboss.com/jira/browse/JBREM-951
Project: JBoss Remoting
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: transport
Affects Versions: 2.2.2.SP5
Environment: JBoss-EAP-4.2, JBossMessaging-1.4.0-SP3, JBossRemoting-2.2.2-SP5
Reporter: Tyronne Wickramarathne
Assigned To: Ron Sigal
Priority: Critical
Fix For: 2.2.2.SP7
This deadlock occurred on JBREM when a JBossMessaging Bridge was set and consuming messages. here's the StackTrace :
Found one Java-level deadlock:
=============================
"Thread-278":
waiting to lock monitor 0x08128544 (object 0xce8b25e0, a java.lang.Object),
which is held by "Timer-4"
"Timer-4":
waiting to lock monitor 0x08129160 (object 0xce89f508, a java.util.ArrayList),
which is held by "Thread-278"
Java stack information for the threads listed above:
===================================================
"Thread-278":
at org.jboss.remoting.ConnectionValidator.doStop(ConnectionValidator.java:526)
- waiting to lock <0xce8b25e0> (a java.lang.Object)
at org.jboss.remoting.ConnectionValidator.stop(ConnectionValidator.java:252)
at org.jboss.remoting.ConnectionValidator.removeConnectionListener(ConnectionValidator.java:344)
- locked <0xce89f508> (a java.util.ArrayList)
at org.jboss.remoting.Client.removeConnectionListener(Client.java:398)
at org.jboss.jms.client.remoting.JMSRemotingConnection.removeConnectionListener(JMSRemotingConnection.java:493)
- locked <0xce8b18c8> (a org.jboss.jms.client.remoting.JMSRemotingConnection)
at org.jboss.jms.client.container.ConnectionAspect.handleClose(ConnectionAspect.java:184)
at sun.reflect.GeneratedMethodAccessor134.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.jboss.aop.advice.PerInstanceAdvice.invoke(PerInstanceAdvice.java:121)
at org.jboss.jms.client.delegate.ClientConnectionDelegate$close_N4742752445160157748.invokeNext(ClientConnectionDelegate$close_N4742752445160157748.java)
at org.jboss.jms.client.container.FailoverValveInterceptor.invoke(FailoverValveInterceptor.java:92)
at org.jboss.aop.advice.PerInstanceInterceptor.invoke(PerInstanceInterceptor.java:105)
at org.jboss.jms.client.delegate.ClientConnectionDelegate$close_N4742752445160157748.invokeNext(ClientConnectionDelegate$close_N4742752445160157748.java)
at org.jboss.jms.client.container.ClosedInterceptor.invoke(ClosedInterceptor.java:170)
at org.jboss.aop.advice.PerInstanceInterceptor.invoke(PerInstanceInterceptor.java:105)
at org.jboss.jms.client.delegate.ClientConnectionDelegate$close_N4742752445160157748.invokeNext(ClientConnectionDelegate$close_N4742752445160157748.java)
at org.jboss.jms.client.delegate.ClientConnectionDelegate.close(ClientConnectionDelegate.java)
at org.jboss.jms.client.JBossConnection.close(JBossConnection.java:132)
at org.jboss.jms.server.bridge.Bridge.cleanup(Bridge.java:1098)
at org.jboss.jms.server.bridge.Bridge.access$1100(Bridge.java:66)
at org.jboss.jms.server.bridge.Bridge$FailureHandler.run(Bridge.java:1496)
at java.lang.Thread.run(Thread.java:619)
"Timer-4":
at org.jboss.remoting.ConnectionValidator.notifyListeners(ConnectionValidator.java:553)
- waiting to lock <0xce89f508> (a java.util.ArrayList)
at org.jboss.remoting.ConnectionValidator.run(ConnectionValidator.java:286)
- locked <0xce8b25e0> (a java.lang.Object)
at java.util.TimerThread.mainLoop(Timer.java:512)
at java.util.TimerThread.run(Timer.java:462)
Found 1 deadlock.
--
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, 12 months
[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.CR2
(was: 2.4.0.GA)
> 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.CR2
>
>
> 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
[JBoss JIRA] Commented: (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=comments#action_12409701 ]
Ron Sigal commented on JBREM-920:
---------------------------------
Four policy files have been created in the src/etc directory:
* remoting.security.policy.core: these are the permissions needed to run all of the Remoting facilities, i.e., the code in src/main
* remoting.security.policy.tests: these are the permissions needed to run most of the Remoting test suite, i.e., the code in src/tests, with the following exceptions
* remoting.security.policy.tests.marshal: these are the permissions used to run ant target "tests.marshal"
* remoting.security.policy.tests.minimal: these are the permissions used to run ant target "tests.functional.main.security" and "tests.functional.main.http.security"
Many of the tests require more permissions than the typical application code, e.g., the ability to access a classloader, so it is possible that giving the test suite the necessary permissions could result in failing to uncover a permission that should have been granted to the core Remoting code. Therefore, the "tests.functional.main.http.security" target was created, which runs a single test for each of the Remoting transports. These particular tests run with a very small set of permissions.
> 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