November 2008 - jboss-dev-forums - Jboss List Archives

[Design of JBoss Remoting, Unified Invokers] - Re: Remoting 3: Beta release imminent

by david.lloyd＠jboss.com

Updated with stricter permissions. As usual. anonsvn will take a few minutes to sync up. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4189536#4189536 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4189536

17 years, 4 months

1
0
0 / 0

[Design of JBoss Remoting, Unified Invokers] - Re: Remoting 3: Beta release imminent

by david.lloyd＠jboss.com

Well, without the ability to create servers or connect to them, the tests would be pretty boring. :) Though in point of fact, I do not think that these permissions are needed anymore, since I use XNIO pipes for testing now, rather than sockets... View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4189535#4189535 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4189535

17 years, 4 months

1
0
0 / 0

[Design of JBoss Remoting, Unified Invokers] - Re: Remoting 3: Beta release imminent

by anil.saldhana＠jboss.com

| grant codeBase "file:${build.home}/api/target/test/classes/-" | { | permission java.lang.RuntimePermission "modifyThread"; // for executor control | }; | | grant codeBase "file:${build.home}/core/target/test/classes/-" | { | permission java.lang.RuntimePermission "modifyThread"; // for executor control | permission org.jboss.remoting.EndpointPermission "createRequestHandler"; | permission org.jboss.remoting.EndpointPermission "createClient"; | }; | | grant codeBase "file:${build.home}/protocol/basic/target/test/classes/-" | { | permission java.lang.RuntimePermission "modifyThread"; // for executor control | permission java.net.SocketPermission "*:*", "accept, connect, resolve"; | permission org.jboss.remoting.EndpointPermission "createRequestHandler"; | permission org.jboss.remoting.EndpointPermission "createClient"; | }; | | grant codeBase "file:${build.home}/protocol/multiplex/target/test/classes/-" | { | permission java.lang.RuntimePermission "modifyThread"; // for executor control | permission java.net.SocketPermission "*:*", "accept, connect, resolve"; | permission org.jboss.remoting.EndpointPermission "createRequestHandler"; | permission org.jboss.remoting.EndpointPermission "createClient"; | }; | | I think the permissions assigned to the tests are pretty lenient. Mainly the socket perm. But since this is remoting, I cannot comment. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4189531#4189531 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4189531

17 years, 4 months

1
0
0 / 0

[Design of POJO Server] - Re: VFS Permissions - JBMICROCONT-149

by alesj

"scott.stark(a)jboss.org" wrote : | I still think the generated bytecode in the vfsmemory: ... So, with this discussion going nowhere; people claiming 100th post, not-being-AOP experts, not-being-Adrian, ... what's the decision on non-real VFS handlers? Return plain vfs url or some re-producible url? As I doubt UnsuppOpException is useful. Although it would be the only one valid ... ;-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4189527#4189527 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4189527

17 years, 4 months

1
0
0 / 0

[Design of JBoss Remoting, Unified Invokers] - Re: Remoting 3: Beta release imminent

by david.lloyd＠jboss.com

We already have that. Check out our current testing policy: http://anonsvn.jboss.org/repos/jbossremoting/remoting3/trunk/testing-supp... View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4189522#4189522 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4189522

17 years, 4 months

1
0
0 / 0

[Design of JBoss Remoting, Unified Invokers] - Re: Remoting 3: Beta release imminent

by anil.saldhana＠jboss.com

"david.lloyd(a)jboss.com" wrote : | What I'd like to know is if there's anything anyone feels is missing/broken that we can't do a 3.0.0.GA without. And, of course, we need more tests... always more tests! Maybe ant target to run your tests under a security manager with stingy security policy. ;) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4189521#4189521 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4189521

17 years, 4 months

1
0
0 / 0

[Design of JBoss Remoting, Unified Invokers] - Remoting 3: Beta release imminent

by david.lloyd＠jboss.com

OK, so I've finished fixing up the Multiplex problems, getting integration with XNIO 1.2 and Mashalling straightened out, classloading, etc. There is only one remaining issue for Beta1, which relates to service metainformation which I think is now covered by the service registration API, so I'll be closing this issue. What I'd like to know is if there's anything anyone feels is missing/broken that we can't do a 3.0.0.GA without. And, of course, we need more tests... always more tests! View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4189513#4189513 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4189513

17 years, 4 months

1
0
0 / 0

[Design of EJB 3.0] - Re: Reintroducing Asynchronous Support

by ALRubinger

This is done as part of https://jira.jboss.org/jira/browse/EJBTHREE-1591. The underlying mechanism now decouples async invocations from jboss-ejb3-proxy; the client can add async support at runtime via a j.l.f.Proxy mixin. So as the Unit Tests in jboss-ejb3-common show, this isn't at all specific to EJB3. S, ALR View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4189508#4189508 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4189508

17 years, 4 months

1
0
0 / 0

[Design of POJO Server] - Re: xml persistent format for attachments

by scott.stark＠jboss.org

Also, if we are only persisting the managed object view of the attachment, it won't be a predetermined attachment any longer. Its a delta against the original transient managed attachment, so we would have to integrate the change in a PRE_REAL deployer. Not that this is a big issue, but there is no authoritative view of the metadata out on disk somewhere. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4189503#4189503 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4189503

17 years, 4 months

1
0
0 / 0

[Design of POJO Server] - Re: VFS Permissions - JBMICROCONT-149

by scott.stark＠jboss.org

So you have org.jboss.aspect.TCCL which sets the TCCL that is applied a call to Thread.setContextClassLoader that uses a privileged block to isolate the caller. So the first issue is that this cannot be a mechanism to circumvent the security check for calling setContextClassLoader, so the application of the aspect has to have a security check that applies to codebase where the aspect is being applied. I'm sure the aop layer does not make this check today. I still think the generated bytecode in the vfsmemory: location also has a permission that is inherited from the aspect codebase so that you know what an aspect is allowed to do. Unless I have granted the setContextClassLoader to the aspect, I'm not going to be able to apply it to some call context to change the caller's ability to perform a privileged operation. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4189501#4189501 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4189501

17 years, 4 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-dev-forums November 2008