October 2007 - jboss-jira - Jboss List Archives

[JBoss JIRA] Closed: (JBREM-38) SSH transport

by David Lloyd (JIRA)

[ http://jira.jboss.com/jira/browse/JBREM-38?page=all ] David Lloyd closed JBREM-38. ---------------------------- Resolution: Won't Fix Assignee: (was: Tom Elrod) SSH transport is not currently on the roadmap, as the default transport already does encryption without key management. However this can be reopened if there is a use case. > SSH transport > ------------- > > Key: JBREM-38 > URL: http://jira.jboss.com/jira/browse/JBREM-38 > Project: JBoss Remoting > Issue Type: Feature Request > Components: transport > Affects Versions: 1.0.1 beta > Reporter: Tom Elrod > Priority: Optional > > Check out http://www.jcraft.com/jsch/index.html and see if can be used for a SSH transport. Also see http://www.jboss.org/index.html?module=bb&op=viewtopic&t=58498 for more comments on this topic. -- 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

18 years, 9 months

1
0
0 / 0

[JBoss JIRA] Closed: (JBREM-103) Transport progress notification for client

by David Lloyd (JIRA)

[ http://jira.jboss.com/jira/browse/JBREM-103?page=all ] David Lloyd closed JBREM-103. ----------------------------- Fix Version/s: Remoting 3 M1 Resolution: Done > Transport progress notification for client > ------------------------------------------ > > Key: JBREM-103 > URL: http://jira.jboss.com/jira/browse/JBREM-103 > Project: JBoss Remoting > Issue Type: Feature Request > Components: r3 api > Affects Versions: 1.0.2 final > Reporter: Philipp Meier > Assigned To: David Lloyd > Fix For: Remoting 3 M1 > > > At the moment there is no way for the client or the server to be notified about the progress of the request / response transmission. Especially for rich clients it would be desireable to be able to register something like a ProgressListener to be notified about the transport progress (push model) or the request the current progress from the remoting implementation (pull model). The discussion in the remoting forum came to the conclusion that this would need some major enhancements of the marshaller. > I set the priority to major because of the major usefulness for richt clients and large dataset. -- 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

18 years, 9 months

1
0
0 / 0

[JBoss JIRA] Reopened: (JBREM-103) Transport progress notification for client

by David Lloyd (JIRA)

[ http://jira.jboss.com/jira/browse/JBREM-103?page=all ] David Lloyd reopened JBREM-103: ------------------------------- Reopening to update the fix version... > Transport progress notification for client > ------------------------------------------ > > Key: JBREM-103 > URL: http://jira.jboss.com/jira/browse/JBREM-103 > Project: JBoss Remoting > Issue Type: Feature Request > Components: r3 api > Affects Versions: 1.0.2 final > Reporter: Philipp Meier > Assigned To: David Lloyd > Fix For: Remoting 3 M1 > > > At the moment there is no way for the client or the server to be notified about the progress of the request / response transmission. Especially for rich clients it would be desireable to be able to register something like a ProgressListener to be notified about the transport progress (push model) or the request the current progress from the remoting implementation (pull model). The discussion in the remoting forum came to the conclusion that this would need some major enhancements of the marshaller. > I set the priority to major because of the major usefulness for richt clients and large dataset. -- 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

18 years, 9 months

1
0
0 / 0

[JBoss JIRA] Created: (JBREM-718) Support for more message-based protocols

by Mark Little (JIRA)

Support for more message-based protocols ---------------------------------------- Key: JBREM-718 URL: http://jira.jboss.com/jira/browse/JBREM-718 Project: JBoss Remoting Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: Mark Little Assigned To: Tom Elrod It would be good if Remoting supported more message-oriented protocols, such as JMS, FTP, email etc. RPC semantics could be layered on those, or simply say that the one-way approach is all that is supported. One slight worry might be if a supported plugin implementation for JBoss Remoting itself used JBoss Remoting (e.g., plugging JBoss Messaging into JBoss Remoting). This may set up some interesting circularities. -- 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

18 years, 9 months

4
3
0 / 0

[JBoss JIRA] Created: (JBREM-759) Client username/password authentication mechanism to provide JAAS UserPrincipal

by Clark Updike (JIRA)

Client username/password authentication mechanism to provide JAAS UserPrincipal ------------------------------------------------------------------------------- Key: JBREM-759 URL: http://jira.jboss.com/jira/browse/JBREM-759 Project: JBoss Remoting Issue Type: Feature Request Security Level: Public (Everyone can see) Components: security Reporter: Clark Updike Per the forum thread, Remoting needs a username/password-style authentication mechanism similar to JNDI for situations that require secure authentication but cannot support the infrastructure required for client certificates. The mechanism should populate a JAAS UserPrinciple that can be used to access the authenticated client identity on the remote side. -- 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

18 years, 9 months

3
3
0 / 0

[JBoss JIRA] Created: (JBREM-819) Consider removing dependency on jboss-commons

by Ron Sigal (JIRA)

Consider removing dependency on jboss-commons --------------------------------------------- Key: JBREM-819 URL: http://jira.jboss.com/jira/browse/JBREM-819 Project: JBoss Remoting Issue Type: Task Security Level: Public (Everyone can see) Affects Versions: 2.2.2.GA Reporter: Ron Sigal Assigned To: Trustin Lee Fix For: 3.0.0.Alpha1 (Otter) >From Greg Hinkle of the JBoss Operations Network group: "... not only are the including tons of crap in the garbage pale called commons, but they dictate tons of library dependencies and serialization versions. For a group like ours that has to be able to simultaneously connect to every version of jboss released in the last 3 years it is not a good situation. We end up having to create a separate class loader per connection. "Now with remoting, we're actually using it as a core infrastructure piece. That means its in parent classloaders to these connection classloaders. As long as commons is in that required list we can't use remoting this way. We're going to have to do some serious classloader restructuring to be able to support our needs." -- 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

18 years, 9 months

2
1
0 / 0

[JBoss JIRA] Created: (JBREM-824) Allow server to shut down connections from specified clients

by Ron Sigal (JIRA)

Allow server to shut down connections from specified clients ------------------------------------------------------------ Key: JBREM-824 URL: http://jira.jboss.com/jira/browse/JBREM-824 Project: JBoss Remoting Issue Type: Feature Request Security Level: Public (Everyone can see) Affects Versions: 2.2.2.SP2, 2.2.2.GA_CP01, 2.4.0.Beta1 (Pinto) Reporter: Ron Sigal Assigned To: Trustin Lee Fix For: 3.0.0.Alpha1 (Otter) >From Jay Howell: Several customers have asked for a management method to drop client connections from the server by ip address and by client id. So there would be two cases. By ipaddress - this would stop the pinger and also close all connections associated with that client ip address. Only one pinger exists for an ip address, so this would require closing of the pinger connection also. By clientid - this would close the pinger thread only if there are no other connections present. In each of the cases, clients should get an asynchronous onException call. This facility would be necessary to support JBMESSAGING-1117. -- 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

18 years, 9 months

2
1
0 / 0

[JBoss JIRA] Created: (JBAOP-366) Ability to attach a .aop deployment to a particular scoped classloader

by Kabir Khan (JIRA)

Ability to attach a .aop deployment to a particular scoped classloader ---------------------------------------------------------------------- Key: JBAOP-366 URL: http://jira.jboss.com/jira/browse/JBAOP-366 Project: JBoss AOP Issue Type: Feature Request Security Level: Public (Everyone can see) Affects Versions: 2.0.0.alpha2 Reporter: Kabir Khan Assigned To: Kabir Khan Fix For: 2.0.0.alpha3, 1.5.4.GA e.g. if an .ear file has been scoped with: <jboss-app> <loader-repository> dot.com:loader=ear1test </loader-repository> </jboss-app> It should be possible to deploy at a later time a .aop file like: <aop> <attach-scoped-loader>dot.com:loader=ear1test</attach-scoped-loader>  </aop> The classloader for the scoped repository "dot.com:loader=ear1test" should be used to deploy the contents of the .aop file in the same way as if the .aop file had been deployed as part of the .ear. -- 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

18 years, 9 months

1
6
0 / 0

[JBoss JIRA] Created: (EJBTHREE-1098) create base ejb3 and session domains in ejb3-interceptors-aop.xml

by William DeCoste (JIRA)

create base ejb3 and session domains in ejb3-interceptors-aop.xml ----------------------------------------------------------------- Key: EJBTHREE-1098 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1098 Project: EJB 3.0 Issue Type: Feature Request Affects Versions: AS 4.2.2.GA Reporter: William DeCoste Assigned To: William DeCoste Priority: Minor Extent applicable domains from base domains so easier to add defaults to all domains -- 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

18 years, 9 months

1
0
0 / 0

[JBoss JIRA] Created: (JBPORTAL-1776) User.updatePassword() fails silently

by Jon Whitmore (JIRA)

User.updatePassword() fails silently ------------------------------------ Key: JBPORTAL-1776 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1776 Project: JBoss Portal Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Portal Identity, Portal Security Affects Versions: 2.6.2 Final Environment: XP, portal 2.6.2, AS 4.2.2.GA, authenticating against LDAP with org.jboss.security.auth.spi.LdapExtLoginModule Reporter: Jon Whitmore The method updatePassword() on org.jboss.portal.identity.User offers the user no information as to the success or failure of the operation. The method can fail if the password offered is not strong enough for the authenticating authority behind the LoginModule. I'm requesting that the method at least return a boolean to indicate success or failure. A more descriptive return code would be even better. My work around to is call verifyPassword() after calling updatePassword() to see if in fact the password has been changed. This trick works for me only because I am not caching passwords - installations caching passwords for only a couple seconds will not be able to use my work around. -- 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

18 years, 9 months

1
0
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 October 2007