May 2008 - jboss-jira - Jboss List Archives

[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

12 years, 5 months

4
6
0 / 0

[JBoss JIRA] Created: (EJBTHREE-1293) Cleanup dependencies of ejb3-core

by Carlo de Wolf (JIRA)

Cleanup dependencies of ejb3-core --------------------------------- Key: EJBTHREE-1293 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1293 Project: EJB 3.0 Issue Type: Task Components: core Reporter: Carlo de Wolf Assigned To: Carlo de Wolf Fix For: AS 5.0.0.CR1 The goal is to have ejb3-core not depend on any jboss-as artifacts. -- 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

12 years, 5 months

3
11
0 / 0

[JBoss JIRA] Created: (EJBTHREE-1343) Remove the cyclical dependency from ejb3/core to org.jboss.jbossas-jboss-as-server

by Dimitris Andreadis (JIRA)

Remove the cyclical dependency from ejb3/core to org.jboss.jbossas-jboss-as-server ---------------------------------------------------------------------------------- Key: EJBTHREE-1343 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1343 Project: EJB 3.0 Issue Type: Task Components: core Reporter: Dimitris Andreadis Assigned To: Carlo de Wolf Priority: Critical Fix For: AS 5.0.0.CR1 ejb3/core -> jboss-as-server dependencies ------------------------------------------------------------ ejb3/core ./org/jboss/ejb3/naming/client/java/javaURLContextFactory.java depends on org.jboss.jbossas:jboss-as-server org.jboss.corba.ORBFactory ------------------------------------------------------------ ejb3/core ./org/jboss/ejb3/naming/client/java/javaURLContextFactory.java depends on org.jboss.jbossas:jboss-as-server org.jboss.naming.client.java.HandleDelegateFactory; ------------------------------------------------------------ ejb3/core ./org/jboss/ejb3/AllowedOperationsInterceptor.java ./org/jboss/ejb3/service/ServiceContainer.java ./org/jboss/ejb3/stateless/StatelessContainer.java depends on org.jboss.jbossas:jboss-as-server org.jboss.ejb.AllowedOperationsAssociation ejb3/core ./org/jboss/ejb3/mdb/MessagingContainer.java depends on org.jboss.jbossas:jboss-as-server org.jboss.jms.jndi.JMSProviderAdapter; org.jboss.jbossas:jboss-as-server ----------------------------------------- ejb3/core ./org/jboss/ejb3/timerservice/jboss/JBossTimerServiceFactory.java ./org/jboss/ejb3/timerservice/TimedObjectInvoker.java depends on org.jboss.jbossas:jboss-as-server org.jboss.ejb.txtimer.EJBTimerService; org.jboss.ejb.txtimer.TimedObjectInvoker ----------------------------------------- ejb3/core ./org/jboss/ejb3/stateful/StatefulLocalProxyFactory.java ./org/jboss/ejb3/stateless/StatelessContainer.java depends on org.jboss.jbossas:jboss-as-server org.jboss.proxy.ejb.handle.StatefulHandleImpl; org.jboss.proxy.ejb.handle.HomeHandleImpl; ------------------------------------------ ejb3/core ./org/jboss/ejb3/AllowedOperationsInterceptor.java ./org/jboss/ejb3/ContainerPlugin.java ./org/jboss/ejb3/service/ServiceContainer.java ./org/jboss/ejb3/stateless/StatelessContainer.java depends on org.jboss.jbossas:jboss-as-server org.jboss.ejb.AllowedOperationsFlags ------------------------------------------- ejb3/core ./org/jboss/ejb3/EJBProxyFactory.java depends on org.jboss.jbossas:jboss-as-server org.jboss.invocation.Invocation -------------------------------------------- ejb3/core ./org/jboss/ejb3/EJBProxyFactory.java depends on org.jboss.jbossas:jboss-as-server org.jboss.ejb.GenericEntityObjectFactory -- 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

12 years, 5 months

4
9
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

12 years, 5 months

5
6
0 / 0

[JBoss JIRA] Created: (JGRP-763) UnicastChannelTest broken

by Bela Ban (JIRA)

UnicastChannelTest broken ------------------------- Key: JGRP-763 URL: http://jira.jboss.com/jira/browse/JGRP-763 Project: JGroups Issue Type: Bug Reporter: Bela Ban Assigned To: Bela Ban Priority: Minor Fix For: 2.8 Caused by moving the starting of threads into handleConnect() (in UDP), however, a unicast channel doesn't send down a CONNECT event. -- 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

12 years, 5 months

2
4
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

12 years, 5 months

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

12 years, 5 months

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

12 years, 6 months

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

12 years, 6 months

4
11
0 / 0

[JBoss JIRA] Created: (SECURITY-45) Assimilate the Higgins Project SPI

by Anil Saldhana (JIRA)

Assimilate the Higgins Project SPI ---------------------------------- Key: SECURITY-45 URL: http://jira.jboss.com/jira/browse/SECURITY-45 Project: JBoss Security and Identity Management Issue Type: Task Security Level: Public (Everyone can see) Components: Security SPI Reporter: Anil Saldhana Assigned To: Anil Saldhana Fix For: 2.0.1 There is a need to get the SPI for Project Higgins Trust Framework into the JBoss Security SPI. -- 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

12 years, 6 months

2
5
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira May 2008