March 2008 - jboss-jira - Jboss List Archives

[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

14 years, 1 month

4
7
0 / 0

[JBoss JIRA] Created: (JBREM-652) allow passing of config map when creating transporter client

by Tom Elrod (JIRA)

allow passing of config map when creating transporter client ------------------------------------------------------------ Key: JBREM-652 URL: http://jira.jboss.com/jira/browse/JBREM-652 Project: JBoss Remoting Issue Type: Task Security Level: Public (Everyone can see) Components: transporter Affects Versions: 2.2.0.Alpha4 Reporter: Tom Elrod Assigned To: Tom Elrod Fix For: 2.2.0.Beta1 (Bluto) Currently the transporter client can only be created using invoker locator for configuration. Need to add to the api so can pass config map which gets passed to the remoting client that is created so can customize things such as ssl config. For example, would be need to be able to something like is done in org.jboss.test.remoting.transport.socket.ssl.custom.InvokerClientTest with a transporter client. -- 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

14 years, 1 month

3
4
0 / 0

[JBoss JIRA] Created: (JBREM-738) ServerThread/invoker still executing invocation after its related TransportServer was stopped

by craig bordelon (JIRA)

ServerThread/invoker still executing invocation after its related TransportServer was stopped --------------------------------------------------------------------------------------------- Key: JBREM-738 URL: http://jira.jboss.com/jira/browse/JBREM-738 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Components: transporter Affects Versions: 2.2.0.Beta1 (Bluto) Environment: java 1.5 on solaris but doubt its specific to this one. Reporter: craig bordelon Assigned To: Tom Elrod get an exception on the third iteration of a transporter client to a transporter server where the client code is doing the same invoke each time. This should not happen as the first two iterations give correct result. The exception is thrown from the server side as apparently the jboss remoting internals are confused -- stating that a ServerInvoker is not in "started state". Exception is java.lang.reflect.UndeclaredThrowableException at $Proxy4.toString(Unknown Source) at java.lang.String.valueOf(String.java:2615) at java.lang.StringBuilder.append(StringBuilder.java:116) at proxy.Client.testClientCall(Client.java:38) at proxy.Client.main(Client.java:115) Caused by: org.jboss.remoting.ServerInvoker$InvalidStateException: Can not proc ess invocation request since is not in started state. at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:751) at org.jboss.remoting.transport.socket.ServerThread.processInvocation(S erverThread.java:568) at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread. java:390) at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.ja va:164) at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClient Invoker.java:163) at org.jboss.remoting.Client.invoke(Client.java:1548) at org.jboss.remoting.Client.invoke(Client.java:534) at org.jboss.remoting.Client.invoke(Client.java:522) at org.jboss.remoting.transporter.TransporterClient.invoke(TransporterC lient.java:297) to reproduce this (one way at least): run the transporter sample modified for the Client to execute the the makeClientCall multiple times. Now to get past the obvious first issue (socket in use) add new code for customerProcessor.releaseCustomer(processedCustomer.getCustomerId() in the Client just before the TransporterClient.destroyTransporterClient(customerProcessor); Implement this method in the CustomerProcessorImpl to use the id to locate (eg hash get()) the related ICustomer TransporterClient and destroy it and to the TransporterServer to stop it. This theoretically frees up the Customer "server" allowing for the next iteration by the Client. note that the processCustomer() implemenation is modified to store the TransporterClient and TransporterServer that are created here. ------------ I dug into the code a bit and what i gathered is that a ServerThread is trying to do processInvocation using a SocketServerInvoker that was already "stopped". I think the ServerThread itself should not be executing as the TransporterServer it should be involved with was already stopped. I posted to the jboss forum on issues i was having trying to make the transporter sample run from the client multiple times. See issue by "bord" on 4/17/2007 -- 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

14 years, 1 month

3
3
0 / 0

[JBoss JIRA] Created: (JBREM-591) Make asynchronous calls using Transporter

by vivek v (JIRA)

Make asynchronous calls using Transporter ----------------------------------------- Key: JBREM-591 URL: http://jira.jboss.com/jira/browse/JBREM-591 Project: JBoss Remoting Issue Type: Feature Request Security Level: Public (Everyone can see) Components: transporter Reporter: vivek v Assigned To: Tom Elrod This came out of the user forum question, http://www.jboss.com/index.html?module=bb&op=viewtopic&t=89224 Currently, there is a mechanism to do asynchronous calls and callbacks using InvocationHandler. As more and more people are using POJOs (via Transporter) for remoting it would be great if we can have the same features (both asynchronous calls and callbacks) available for the Transporter. Couple of use cases can be, Asynchronous Call ----------------------------- 1) Client makes a simple method call (using POJO) on server 2) Server gets the request and returns immediately to the Client. Now Client is free to do its own stuff without waiting or polling for the result. 3) Server starts processing the request 4) When the response is ready Server sends the response to the Client. Callbacks -------------------- 1) An alert happens on the server side 2) Server should be able to send the alert to the Client without Client requesting for it. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 1 month

4
5
0 / 0

[JBoss JIRA] Created: (JBREM-585) there is the need to add a callback listener for ssl stream invocation

by Michael Voss (JIRA)

there is the need to add a callback listener for ssl stream invocation ---------------------------------------------------------------------- Key: JBREM-585 URL: http://jira.jboss.com/jira/browse/JBREM-585 Project: JBoss Remoting Issue Type: Task Security Level: Public (Everyone can see) Components: stream Affects Versions: 2.0.0.CR1 (Boon) Reporter: Michael Voss Assigned To: Tom Elrod Fix For: 2.0.0.GA (Boon) If want to use existing ssl connector for stream invocation (using Client.invoke(InputStream,Object,Connector) ) the client has to add a callback listener to run the the invocation properly I think stream invocation should also work without the need to add a callback listener if no listener is added the following exception is thrown: by stream sender: org.jboss.remoting.ConnectionFailedException: Connection has been shutdown: javax.net.ssl.SSLProtocolException: Illegal client handshake msg, 1 at org.jboss.remoting.transport.multiplex.MultiplexClientInvoker.handleConnect(MultiplexClientInvoker.java:111) at org.jboss.remoting.MicroRemoteClientInvoker.connect(MicroRemoteClientInvoker.java:252) at org.jboss.remoting.Client.connect(Client.java:391) at org.jboss.remoting.Client.connect(Client.java:383) at org.jboss.remoting.stream.StreamHandler.<init>(StreamHandler.java:77) at org.jboss.remoting.ServerInvoker.getStreamHandler(ServerInvoker.java:1253) at org.jboss.remoting.ServerInvoker.handleInternalInvocation(ServerInvoker.java:1225) at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:983) at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:848) at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:447) at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:520) at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:257) at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:163) at org.jboss.remoting.Client.invoke(Client.java:612) at org.jboss.remoting.Client.invoke(Client.java:604) at org.jboss.remoting.Client.invoke(Client.java:1211) by stream receiver: javax.net.ssl.SSLException: Connection has been shutdown: javax.net.ssl.SSLProto colException: Illegal client handshake msg, 1 at com.sun.net.ssl.internal.ssl.SSLSocketImpl.checkEOF(Unknown Source) at com.sun.net.ssl.internal.ssl.AppInputStream.read(Unknown Source) at java.io.BufferedInputStream.fill(Unknown Source) at java.io.BufferedInputStream.read1(Unknown Source) at java.io.BufferedInputStream.read(Unknown Source) at org.jboss.remoting.transport.multiplex.InputMultiplexor$SingleGroupIn putThread.completeHeader(InputMultiplexor.java:608) at org.jboss.remoting.transport.multiplex.InputMultiplexor$SingleGroupIn putThread.doRun(InputMultiplexor.java:540) at org.jboss.remoting.transport.multiplex.utility.StoppableThread.run(St oppableThread.java:54) Caused by: javax.net.ssl.SSLProtocolException: Illegal client handshake msg, 1 at com.sun.net.ssl.internal.ssl.ClientHandshaker.processMessage(Unknown Source) at com.sun.net.ssl.internal.ssl.Handshaker.processLoop(Unknown Source) at com.sun.net.ssl.internal.ssl.Handshaker.process_record(Unknown Source ) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(Unknown Source) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.performInitialHandshake(Un known Source) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.writeRecord(Unknown Source ) at com.sun.net.ssl.internal.ssl.AppOutputStream.write(Unknown Source) at java.io.OutputStream.write(Unknown Source) at org.jboss.remoting.transport.multiplex.OutputMultiplexor$OutputThread .encode(OutputMultiplexor.java:580) at org.jboss.remoting.transport.multiplex.OutputMultiplexor$OutputThread .doRun(OutputMultiplexor.java:452) ... 1 more -- 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

14 years, 1 month

4
6
0 / 0

[JBoss JIRA] Created: (JGRP-726) GossipRouter: support GET and REGISTER via UDP datagram packets

by Bela Ban (JIRA)

GossipRouter: support GET and REGISTER via UDP datagram packets --------------------------------------------------------------- Key: JGRP-726 URL: http://jira.jboss.com/jira/browse/JGRP-726 Project: JGroups Issue Type: Feature Request Reporter: Bela Ban Assigned To: Vladimir Blagojevic Fix For: 2.8 Currently, GossipRouter supports only TCP. If a GossipClient calls register() or getMembers(), then a TCP connection is established and torn down after the request. This is inefficient and leads to many sockets in TIME_WAIT states (which are cleaned up after 2 * MSL seconds). If we (in GossipRouter) add an additional listener, which listens on a UDP port, and provide the same for GossipClient, we would not use precious TCP sockets. Think about: we should separate the transport in GR from the processing logic, so we could support TCP, UDP, HTTP etc. Should we use JGroups (in unicast mode) for this ? -- 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

14 years, 1 month

5
6
0 / 0

[JBoss JIRA] Created: (JGRP-705) Unicast JGroups

by Bela Ban (JIRA)

Unicast JGroups --------------- Key: JGRP-705 URL: http://jira.jboss.com/jira/browse/JGRP-705 Project: JGroups Issue Type: Feature Request Reporter: Bela Ban Assigned To: Bela Ban Fix For: 2.x Investigate use of JGroups for point-to-point communication, as a replacement for java.net{Server}Socket. E.g. Channelch=new JChannel(); ch.connect(null); // null means p2p -- 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

14 years, 1 month

2
7
0 / 0

[JBoss JIRA] Created: (JBRULES-1075) Support overloading of accumulate functions: Add int (or long) based sum's, int based avarage's, etc

by Geoffrey De Smet (JIRA)

Support overloading of accumulate functions: Add int (or long) based sum's, int based avarage's, etc ----------------------------------------------------------------------------------------------------- Key: JBRULES-1075 URL: http://jira.jboss.com/jira/browse/JBRULES-1075 Project: JBoss Rules Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Drl Parser/Builder Affects Versions: 4.0.0.GA Reporter: Geoffrey De Smet Assigned To: Edson Tirelli Priority: Minor Fix For: FUTURE TTP nl10 solver has about a 3% performance increase when switching from sumDouble to sumLong (and possibly a bit more when switching to sumInteger) There are 2 ways I see to implement this: 1) Force the user to explicitly declare he wants to use an integer based sum and add a sumInteger. This is not so user-friendly. This is what I 've done in the patch. 2) Support overloading of accumulate functions based on the function arguments. AFAIK drl is strongly typed (at least with the java dialect), so it should be theoretically possible for the drl parser to see sum($myInteger) and bind it to SumIntegerAccumulateFunction, while binding sum($myInteger.doubleValue()) to SumDoubleAccumulateFunction. And added advantage is that the drl compiler will also mark some bugs as compiler errors. For example sum($myString) -- 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

14 years, 1 month

4
5
0 / 0

[JBoss JIRA] Created: (SECURITY-132) Traditional Authentication

by Darran Lofthouse (JIRA)

Traditional Authentication -------------------------- Key: SECURITY-132 URL: http://jira.jboss.com/jira/browse/SECURITY-132 Project: JBoss Security and Identity Management Issue Type: Task Security Level: Public (Everyone can see) Components: Negotiation Reporter: Darran Lofthouse Assigned To: Darran Lofthouse Incomming call may be traditional username / password type call but consideration needs to be given for potential outbound call. -- 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

14 years, 1 month

3
11
0 / 0

[JBoss JIRA] Created: (SECURITY-141) Fallback to different authenticator if authentication fails

by Darran Lofthouse (JIRA)

Fallback to different authenticator if authentication fails ----------------------------------------------------------- Key: SECURITY-141 URL: http://jira.jboss.com/jira/browse/SECURITY-141 Project: JBoss Security and Identity Management Issue Type: Task Security Level: Public (Everyone can see) Components: Negotiation Reporter: Darran Lofthouse Assigned To: Darran Lofthouse Need to consider how this will work especially regarding security domains, possible to do something active directory - password-stacking and an LDAP login module that for negotiation does just role mapping and for non negotiation also does authentication. -- 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

14 years, 1 month

4
11
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira March 2008