July 2011 - jboss-jira - Jboss List Archives

[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, 7 months

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, 7 months

4
6
0 / 0

[JBoss JIRA] Created: (AS7-1407) JNDI view operation doesn't show all entries

by Heiko Braun (JIRA)

JNDI view operation doesn't show all entries -------------------------------------------- Key: AS7-1407 URL: https://issues.jboss.org/browse/AS7-1407 Project: Application Server 7 Issue Type: Enhancement Components: Domain Management Reporter: Heiko Braun Assignee: Brian Stansberry don't ask me why, but a queue (java:/jboss/queues/myQueue) for instance is not shown. Same thing for resource adapter, etc. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 7 months

7
11
0 / 0

[JBoss JIRA] Created: (EJBTHREE-2254) @Singleton does not work with @RunAs/@RolesAllowed from an MDB (@Service works fine)

by Richard Kennard (JIRA)

@Singleton does not work with @RunAs/@RolesAllowed from an MDB (@Service works fine) ------------------------------------------------------------------------------------ Key: EJBTHREE-2254 URL: https://issues.jboss.org/browse/EJBTHREE-2254 Project: EJB 3.0 Issue Type: Bug Environment: JBoss 6.0.0.Final Reporter: Richard Kennard Test case attached. Please open as an Eclispe JBoss Tools project. It creates a Quartz-based MDB that tries to call various other beans (Session, Service and Singleton) that are secured with @RolesAllowed. To observe the behaviour: 1. Deploy the app. Notice that the MDB (which triggers every minute) can successfully run the secured methods from the Session bean and the Service bean, but NOT the Singleton bean. The @RunAs credentials are not being passed to the @Singleton bean 2. Uncomment the lines indicated in the code (in RunAsTestMDB.java and jboss.xml). This sets a null security-domain on the Singleton bean, allowing it to be invoked. However immediately afterwards the @RunAs credentials are lost and the MDB can no longer call other beans -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 7 months

3
10
0 / 0

[JBoss JIRA] Created: (AS7-1171) datasource names that start with java:jdbc/ do not work

by Scott Marlow (JIRA)

datasource names that start with java:jdbc/ do not work ------------------------------------------------------- Key: AS7-1171 URL: https://issues.jboss.org/browse/AS7-1171 Project: Application Server 7 Issue Type: Bug Affects Versions: 7.0.0.CR1 Reporter: Scott Marlow Using a datasource name like "java:jdbc/eFpDataSource" in a persistence.xml doesn't seem to work. We seem to start to deploy the datasource but cannot resolve the service lookup. Deploying an application that contains a persistence unit reference to the above datasource (see forum post for efp.ear zip), leads to the following server.log output: 07:20:11,374 DEBUG [org.jboss.as.connector.deployer.dsdeployer] (MSC service thread 1-1) Adding datasource: java:/java:jdbc/eFpDataSource 07:20:11,378 TRACE [org.jboss.as.naming.service.BinderService] (MSC service thread 1-2) Bound resource jdbc/eFpDataSource into naming store org.jboss.as.naming.InMemoryNamingStore@65499154 New missing/unsatisfied dependencies: service jboss.naming.context.java.java:jdbc/eFpDataSource (missing) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 7 months

5
14
0 / 0

[JBoss JIRA] Created: (JBAS-9099) Handle reconnection of hosts to the domain

by Brian Stansberry (JIRA)

Handle reconnection of hosts to the domain ------------------------------------------ Key: JBAS-9099 URL: https://issues.jboss.org/browse/JBAS-9099 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Components: Domain Management Reporter: Brian Stansberry Priority: Critical Fix For: 7.0.0.CR1 Establish processes for host controllers to reconnect to the master domain controller if communication is disrupted and thereafter synchronize themselves (and their servers) with the domain. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 7 months

6
8
0 / 0

[JBoss JIRA] Created: (AS7-1253) Package org.jboss.as.clustering has classes in multiple modules

by Brian Stansberry (JIRA)

Package org.jboss.as.clustering has classes in multiple modules --------------------------------------------------------------- Key: AS7-1253 URL: https://issues.jboss.org/browse/AS7-1253 Project: Application Server 7 Issue Type: Bug Components: Clustering Reporter: Brian Stansberry Assignee: Paul Ferraro Fix For: 7.0.1.Final Package splitting is verbotten in AS 7, even if all the jars are meant to be used as a unit. This is probably the result of the split of the clustering module into multiple pieces. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 7 months

5
7
0 / 0

[JBoss JIRA] Created: (JBAS-9369) Implement Namespace resolution policy

by David Lloyd (JIRA)

Implement Namespace resolution policy ------------------------------------- Key: JBAS-9369 URL: https://issues.jboss.org/browse/JBAS-9369 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Components: EE, Naming Reporter: David Lloyd Assignee: John Bailey Fix For: 7.0.0.Beta4 Perform the following automatic translations: * {{foo/bar/baz}} becomes {{java:jboss/env/foo/bar/baz}} ** if a component is in scope, instead use {{java:comp/env/foo/bar/baz}} or {{java:module/env/foo/bar/baz}} as appropriate * {{java:/foo/bar/baz}} => {{java:jboss/root/foo/bar/baz}} -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 7 months

6
7
0 / 0

[JBoss JIRA] Created: (JBAS-8338) handling of service start failure

by Alexey Loubyansky (JIRA)

handling of service start failure --------------------------------- Key: JBAS-8338 URL: https://jira.jboss.org/browse/JBAS-8338 Project: JBoss Application Server Issue Type: Sub-task Security Level: Public (Everyone can see) Reporter: Alexey Loubyansky Fix For: 7.0.0.M1 In this case, the exception is logged, and all the service's dependents will be trapped in a waiting state. This type of error will typically be due to transient conditions, like an incorrectly configured IP address, disk space issues, and so on. The correct behavior here is to log the error and let the user decide (based on the GUI or perhaps by deployment plan policy) whether to fix the issue and retry the failed service, let the error stand, or pull out the deployment unit. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 7 months

5
8
0 / 0

[JBoss JIRA] Created: (SECURITY-440) JBossXACML:: bug identified implementing RBAC

by Anil Saldhana (JIRA)

JBossXACML:: bug identified implementing RBAC --------------------------------------------- Key: SECURITY-440 URL: https://jira.jboss.org/jira/browse/SECURITY-440 Project: JBoss Security and Identity Management Issue Type: Bug Security Level: Public (Everyone can see) Components: JBossXACML Reporter: Anil Saldhana Assignee: Anil Saldhana -- 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

14 years, 7 months

3
2
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira July 2011