July 2008 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (SECURITY-176) Implement JBossRequestContext.asElement(Document)

by Anil Saldhana (JIRA)

Implement JBossRequestContext.asElement(Document) ------------------------------------------------- Key: SECURITY-176 URL: http://jira.jboss.com/jira/browse/SECURITY-176 Project: JBoss Security and Identity Management Issue Type: Task Security Level: Public (Everyone can see) Components: JBossXACML Affects Versions: 2.0.2-BETA6 Reporter: Anil Saldhana Assigned To: Anil Saldhana Fix For: 2.0.2.GA If provided a Document, then create an element with the request details. Pretty cumbersome process. -- 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

13 years, 1 month

4
4
0 / 0

[JBoss JIRA] Created: (SECURITY-177) Implement JBossResponseContext.asElement(Document)

by Anil Saldhana (JIRA)

Implement JBossResponseContext.asElement(Document) -------------------------------------------------- Key: SECURITY-177 URL: http://jira.jboss.com/jira/browse/SECURITY-177 Project: JBoss Security and Identity Management Issue Type: Sub-task Security Level: Public (Everyone can see) Components: JBossXACML Affects Versions: 2.0.2-BETA6 Reporter: Anil Saldhana Assigned To: Anil Saldhana Fix For: 2.0.2.GA -- 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

13 years, 1 month

3
3
0 / 0

[JBoss JIRA] Created: (JGRP-809) Copyless stack

by Bela Ban (JIRA)

Copyless stack -------------- Key: JGRP-809 URL: https://jira.jboss.org/jira/browse/JGRP-809 Project: JGroups Issue Type: Feature Request Reporter: Bela Ban Assignee: Bela Ban Fix For: 2.8 Currently (as of 2.7), the transport reads the contents of a received packet into a buffer, then passes a *copy* of the buffer to a thread from the OOB or incoming thread pools. To prevent this copy, we can - have the receiver read only the version and OOB flag (to see which thread pool to dispatch the packet to) - pass a ref to the socket to a thread from the incoming of OOB pool, have that thread read the packet and return - each thread in the pool has its own buffer into which the buffer is read from the socket Possibly use NIO: we can install a selector and get woken up whenever data to be read is present. At that point, we can pass the ref to the socket to the handler thread and return immediately. NIO with channels for multicast sockets is available only in JDK 7 (or 8?), so this is a bit off... However, we can already implement this with reading the version and flags bytes and then passing the socket to the handler -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 1 month

2
6
0 / 0

[JBoss JIRA] Created: (JBREM-902) InvocationRequest need SSLSession for certificates and principal in sslsocket transport

by ya xiang (JIRA)

InvocationRequest need SSLSession for certificates and principal in sslsocket transport --------------------------------------------------------------------------------------- Key: JBREM-902 URL: http://jira.jboss.com/jira/browse/JBREM-902 Project: JBoss Remoting Issue Type: Feature Request Security Level: Public (Everyone can see) Components: security Reporter: ya xiang In a SSL context, there is a real need for check principal and certificates. There are ways to do this, but current jboss remoting not provide it, just provider socket remote address as sessionId. seems not enough. -- 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

13 years, 1 month

2
5
0 / 0

[JBoss JIRA] Created: (JBREM-857) transporterclient not thread-safe for failover

by craig bordelon (JIRA)

transporterclient not thread-safe for failover ---------------------------------------------- Key: JBREM-857 URL: http://jira.jboss.com/jira/browse/JBREM-857 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Components: transporter Affects Versions: 1.4.6.GA Environment: solaris 10 and java 5 Reporter: craig bordelon Fix For: 2.2.2.GA_CP02 the jboss 1.4.1 transporterclient used by multithreaded program was giving strange results on a clustered server when failing over so i found lack of synchronization in the code. I made these changes and seems to be helping. changes to TransporterClient.java. I would like this fixed in the 2.x and 3.x versions (hello developers). I think i know how to fix the 2.x version of this code too as it has some new stuff but is likewise broken. (developers send me an email to bord(a)iscp.telcordia.com if you need it. thx Craig) @@ -93,11 +93,12 @@ /** * Disconnects the remoting client */ - private void disconnect() + private synchronized void disconnect() { if(remotingClient != null) { remotingClient.disconnect(); + remotingClient = null; } } @@ -232,14 +233,18 @@ do { + Client rcl = null; + synchronized(this) { rcl = remotingClient; } + if (rcl == null) throw new CannotConnectException("Client has been dis connected."); try { failOver = false; - response = remotingClient.invoke(request); + response = rcl.invoke(request); } catch(CannotConnectException cnc) { - failOver = findAlternativeTarget(); + failOver = findAlternativeTarget(rcl); + if (log.isDebugEnabled()) log.error("on CannotConnectException failO ver is "+failOver+" for "+rcl.getInvoker().getLocator()); if(!failOver) { throw cnc; @@ -264,7 +269,7 @@ * * @return */ - private boolean findAlternativeTarget() + private boolean findAlternativeTarget(Client rcl) { boolean failover = false; @@ -287,12 +292,19 @@ { // finally found server with target handler InvokerLocator newLocator = data.getInvokerLocator(); - if(!remotingClient.getInvoker().getLocator().equals(new Locator)) + if(!rcl.getInvoker().getLocator().equals(newLocator)) { try { - remotingClient = new Client(newLocator); - remotingClient.connect(); + synchronized(this) { + if (rcl == remotingClient) { + disconnect(); + remotingClient = new Client(newLocator); + } + //otherwise have to assume some other thread + //has meanwhile changed it + //including even disconnecting + } return true; } catch(Exception e) @@ -300,6 +312,8 @@ log.warn("Problem connecting to newly found alter nate target.", e); } } + else if (log.isDebugEnabled()) + log.error(rcl.getInvoker().getLocator()+" == "+newLoc ator); } } } @@ -333,4 +347,4 @@ } -- 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

13 years, 1 month

3
3
0 / 0

[JBoss JIRA] Created: (JBREM-906) NoSuchObjectException on Server Restart Using RMI Transport & Unified Invoker

by John Reynolds (JIRA)

NoSuchObjectException on Server Restart Using RMI Transport & Unified Invoker ----------------------------------------------------------------------------- Key: JBREM-906 URL: http://jira.jboss.com/jira/browse/JBREM-906 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Components: unifiedinvoker Affects Versions: 2.2.2.GA Environment: Server Running Windows XP or Redhat - Swing Client on Windows XP Reporter: John Reynolds Using a Swing client to connect to the JBoss server, configured with RMI Transport Connector and Unified Invoker, I receive the following StackTrace when, after successfully connecting to the server and executing a few EJB transactions, I shut the server down and then bring it back up. Upon attempting to do any further invocations, it appears cached information is causing the client to fail. ------------- (rmi.RMIClientInvoker 272 ) java.rmi.NoSuchObjectException: no such object in table galaxy.framework.model.domain.services.util.SLCommunicationException: Error making invocation in RMI client invoker. at galaxy.framework.model.domain.services.util.ServiceLocator.authenticateUser(ServiceLocator.java:738) at galaxy.framework.model.domain.services.util.ServiceLocator.initializeWithLDAP(ServiceLocator.java:435) at galaxy.application.view.swing.presentation.util.ClientConnectionManager$1.run(ClientConnectionManager.java:51) Caused by: org.jboss.remoting.CannotConnectException: Error making invocation in RMI client invoker. at org.jboss.remoting.transport.rmi.RMIClientInvoker.transport(RMIClientInvoker.java:273) at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:122) at org.jboss.remoting.Client.invoke(Client.java:1550) at org.jboss.remoting.Client.invoke(Client.java:530) 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.StatelessSessionInterceptor.invoke(StatelessSessionInterceptor.java:112) at org.jboss.proxy.ClientContainer.invoke(ClientContainer.java:100) at $Proxy1.authenticateSwingUserWithLDAP(Unknown Source) at galaxy.framework.model.domain.services.util.ServiceLocator.authenticateUser(ServiceLocator.java:725) ... 2 more Caused by: java.rmi.NoSuchObjectException: no such object in table at sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(StreamRemoteCall.java:247) at sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:223) at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:126) at org.jboss.remoting.transport.rmi.RMIServerInvoker_Stub.transport(Unknown Source) at org.jboss.remoting.transport.rmi.RMIClientInvoker.transport(RMIClientInvoker.java:238) ... 14 more ------------ Seems potentially similar to this issue fixed in 4.0.5 in non-remoting-RMI code: http://www.jboss.com/index.html?module=bb&op=viewtopic&t=116027 -- 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

13 years, 1 month

2
1
0 / 0

[JBoss JIRA] Created: (JBREM-802) TransporterHandler should not use Class.forName

by Julien Viet (JIRA)

TransporterHandler should not use Class.forName ----------------------------------------------- Key: JBREM-802 URL: http://jira.jboss.com/jira/browse/JBREM-802 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Components: transporter Affects Versions: 2.2.1.GA, 2.2.0.SP4 Reporter: Julien Viet line: classSig[x] = Class.forName(sig[x]); should probably be replaced by classSig[x] = targetPOJO.getClass().getClassLoader().loadClass(sig[x]); to provide a correct class lookup -- 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

13 years, 1 month

4
4
0 / 0

[JBoss JIRA] Created: (JBREM-808) Remove dependencies on ObjectNameFactory from JBoss JMX

by Julien Viet (JIRA)

Remove dependencies on ObjectNameFactory from JBoss JMX ------------------------------------------------------- Key: JBREM-808 URL: http://jira.jboss.com/jira/browse/JBREM-808 Project: JBoss Remoting Issue Type: Task Security Level: Public (Everyone can see) Reporter: Julien Viet It happens when my POJO has not been bound on the transporter server, it looks like the transporter client is trying to do some fail over. This make JBoss Remoting depends on the JBoss JMX implementation. That makes JBoss Remoting more difficult to embed and reuse. I think that the ObjectNameFactory class could be easily ported to JBoss Remoting without any harm done. However perhaps JBoss Remoting has more dependencies on JBoss JMX that I don't know that would prevent to remove such dependency. [junit_] Exception in thread "main" java.lang.NoClassDefFoundError: org/jboss/mx/util/ObjectNameFactory [junit_] at org.jboss.remoting.transporter.InternalTransporterServices.<clinit>(InternalTransporterServices.java:41) [junit_] at org.jboss.remoting.transporter.TransporterClient.findAlternativeTarget(TransporterClient.java:330) [junit_] at org.jboss.remoting.transporter.TransporterClient.invoke(TransporterClient.java:301) [junit_] at $Proxy0.getInfo(Unknown Source) [junit_] at org.jboss.portal.test.framework.driver.remote.RemoteTestDriverClient.getInfo(RemoteTestDriverClient.java:107) -- 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

13 years, 1 month

3
3
0 / 0

[JBoss JIRA] Created: (JBREM-762) Deadlock bug in socket invoker

by Tim McCune (JIRA)

Deadlock bug in socket invoker ------------------------------ Key: JBREM-762 URL: http://jira.jboss.com/jira/browse/JBREM-762 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Components: transport Affects Versions: 1.4.6.GA Environment: JBoss 4.0.4 EJB 3.0-rc9-patch1 JDK 1.6.0 Reporter: Tim McCune There is a potential thread leak in ServerThread.java that causes ServerThreads to stick around, but to disappear from the thread pool as the accept() thread(s) see it. Eventually, when the # of leaked threads reaches the MaxPoolSize, the system ends up deadlocked and will not accept any more incoming socket connections. I have described the problem in great detail in a forum post and in support case 00016786. I have patched the code, and so far it seems to be working fine and to have fixed the problem. This is what I patched: In ServerThread.java, I wrapped the contents of wakeup() inside of a try/catch, block, with the following code in the catch block: } catch (Exception e) { synchronized (clientpool) { synchronized (threadpool) { clientpool.remove(this); threadpool.add(this); Thread.interrupted(); } } throw e; } This makes sure that the thread is put back into the threadpool when an exception occurs in the createServerSocket() method (this method is doing socket I/O in 1.4.6, and in our case, this socket connection was timing out.). -- 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

13 years, 1 month

2
1
0 / 0

[JBoss JIRA] Created: (JBREM-646) dynamic loading of new keystores during runtime is not possible when using Transporters (beaming POJOs)

by Claudia Richter (JIRA)

dynamic loading of new keystores during runtime is not possible when using Transporters (beaming POJOs) ------------------------------------------------------------------------------------------------------- Key: JBREM-646 URL: http://jira.jboss.com/jira/browse/JBREM-646 Project: JBoss Remoting Issue Type: Patch Security Level: Public (Everyone can see) Components: transporter Environment: ?? Reporter: Claudia Richter Assigned To: Tom Elrod when running a Transporter Server and a Transporter Client, using SSL connection, the Transporter Server does not recognise changes within its Truststore, if this is updated. Means, if the Client is not trusted when starting the Server, it will not be trusted for future request until the Server is restarted. It would be better to have a Server that is able to recognise Truststore changes. This feature is already implemented for other transports (no Transporters) as described in issue http://jira.jboss.com/jira/browse/JBREM-427. -- 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

13 years, 1 month

4
7
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira July 2008