March 2009 - jboss-dev-forums - Jboss List Archives

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: security and createQueue

by ataylor

Ok, I'll add create/deletenondurablequeue and remove temp View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4220322#4220322 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4220322

17 years

1
0
0 / 0

[Design of AOP on JBoss (Aspects/JBoss)] - Re: Reimplementing AspectManager/Domains to understand jboss

by adrian＠jboss.org

"kabir.khan(a)jboss.com" wrote : | "adrian(a)jboss.org" wrote : | | e.g. In your final comment where you want a "global" aspect definition then | | the deployments that want to use it would need to "import" the classloader | | where those aspects are deployed. | | I think you are saying just ignore InterceptorB and InterceptorC unless A.jar is set up to import the packages/modules of the interceptors? I think that will be pretty simple to do. | It depends what you are talking about. If the aspect definition is in A.jar but the class is invisible then I think it should be an error. I don't see why aspects shouldn't follow the same rules as normal class imports? The fact that AOP is weaving the class reference into bytecode (either literally or dynamically via interceptors) shouldn't make any difference. anonymous wrote : | My suggestion regarding global visibility is to make the classes from the loaders for B.aop and C.aop magically visible from A.jar somehow. But that means we don't get versioning of modules packages, so maybe an explicit import is the best thing. At the same time, I don't know if whoever writes A.jar should need to know that InterceptorB or InterceptorB might be applied later? | Magically adding a random version of the class is clearly not in sympathy with the modularization rules of OSGi style classloading. The issue that I said was upto you is whether InterceptorB defined in B.aop really applies to A.jar when everything else from B.aop is not visible to it. I'd say the rule should be that the aop config only applies when A.jar chooses to import the relevant aspect classes defined in B.aop. The part I said you might ignore would be where B.aop contains aspect configuration for other classes that A.jar chooses NOT to import or just isn't relevant. I don't know whether that helps you resolve the problem, but you certainly shouldn't be trying to break the class visbility rules in any way. That could be a potential security hole if nothing else. :-) View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4220320#4220320 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4220320

17 years

1
0
0 / 0

[Design of AOP on JBoss (Aspects/JBoss)] - Re: Reimplementing AspectManager/Domains to understand jboss

by kabir.khan＠jboss.com

The problem I am trying to solve is not really to do with the classes being woven, rather with being able to load up bound aspects when invoking the woven class. If the aspects are part of the the target deployment it is not an issue. There will be a problem if the aspects are in other deployments and the aspect classes are not found by the target deployment's classloader. For example if I have a deployment A.jar using importAll=false containing | package pkga; | | @Marker | public class ClassA{ | public void method(){} | } | | | | | In same the classloading domain I have a B.aop archive containing pkgb.InterceptorB.class: | | | | | <aop> | | | <interceptor class="pkgb.InterceptorB"/> | | | <bind pointcut="execution(* @Marker->*(..))"> | | | <interceptor-ref name="pkgb.InterceptorB"/> | | | </aspect> | | | </aop> | | | | | and a C.aop archive containing pkgc.InterceptorC.class: | | | | | <aop> | | | <interceptor class="pkgc.InterceptorC"/> | | | <bind pointcut="execution(* @Marker->*(..))"> | | | <interceptor-ref name="pkgc.InterceptorC"/> | | | </aspect> | | | </aop> | | | | | | | When the class is loaded/woven we don't care about what is bound, so we can weave the class no problem. | | | | When we come to invoking pkga.ClassA.method(), we need to populate the interceptor chains. Since A.jar's loader is not set up to see pkgb.InterceptorB or pkgc.InterceptorC we can't invoke those interceptors. Currently AOP will throw an error, the purpose of this thread is to figure out a better way to handle this. | | | | "adrian(a)jboss.org" wrote : | | | e.g. In your final comment where you want a "global" aspect definition then | | | the deployments that want to use it would need to "import" the classloader | | | where those aspects are deployed. | | | | I think you are saying just ignore InterceptorB and InterceptorC unless A.jar is set up to import the packages/modules of the interceptors? I think that will be pretty simple to do. | | | | My suggestion regarding global visibility is to make the classes from the loaders for B.aop and C.aop magically visible from A.jar somehow. But that means we don't get versioning of modules packages, so maybe an explicit import is the best thing. At the same time, I don't know if whoever writes A.jar should need to know that InterceptorB or InterceptorB might be applied later? | | | | When generating the invocation class for pkga.ClassA.method() we create something like: | | | | | public class ClassA_method extends MethodInvocation | | | { | | | ClassA target; | | | | | | public ClassA_method(POJO target) | | | { | | | this.target = target; | | | } | | | | | | public void dispatchJoinPoint() | | | { | | | target.method(); | | | } | | | } | | | | | | public class ClassA_method_1 extends ClassA_method | | | { | | | pkgb.InterceptorB aspect1; | | | pkgc.InterceptorC aspect2; | | | | | | int current; | | | public Object invokeNext() throws Throwable | | | { | | | try | | | { | | | switch (current++) | | | { | | | case 0: | | | return aspect1.invoke(this); | | | break; | | | case 1: | | | return aspect2.invoke(this); | | | break; | | | default: | | | dispatchJoinPoint(); | | | return null; | | | } | | | } | | | finally | | | { | | | current--; | | | } | | | } | | | } | | | | | If go with ignoring the aspects that cannot be found we would need to generate this instead: | | | | | public class ClassA_method_1 extends ClassA_method | | | { | | | int current; | | | public Object invokeNext() throws Throwable | | | { | | | switch (current++) | | | { | | | case 0: | | | return aspect1.invoke(this); | | | break; | | | case 1: | | | return aspect2.invoke(this); | | | break; | | | default: | | | dispatchJoinPoint(); | | | return null; | | | } | | | } | | | } | | | | | | | View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4220313#4220313 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4220313

17 years

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Context installation causes StackOverflowError

by adrian＠jboss.org

"alesj" wrote : "adrian(a)jboss.org" wrote : | | It might be an idea to test that for backwards compatibility issuse at the same time? | Test where? In JBossAS, etc. I don't think it could really cause a problem if you look at the logic, but you never know. ;-) View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4220305#4220305 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4220305

17 years

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Context installation causes StackOverflowError

by alesj

"adrian(a)jboss.org" wrote : | It might be an idea to test that for backwards compatibility issuse at the same time? Test where? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4220295#4220295 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4220295

17 years

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Context installation causes StackOverflowError

by alesj

"adrian(a)jboss.org" wrote : | Like it says there, this needs to be validated against JBossAS, etc. | to make sure it doesn't cause some unexpected problem. | | Ales can you do that? | Sure, I'll check the related MC projects (cl, deployers, ...) and work with Jaikiran to see how this behaves in JBossAS. Thanks for the fix. ;-) ps: I'll do this in the evening, as I really am PT time currently :-) View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4220293#4220293 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4220293

17 years

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Context installation causes StackOverflowError

by adrian＠jboss.org

Incidently, I think there's a further optimization where we don't look at the dependencies for contexts that are already in the "installing' set, since we know we won't process them anyway. | protected Set<ControllerContext> resolveContexts(Set<ControllerContext> contexts, ControllerState state, boolean trace) | { | HashSet<ControllerContext> result = new HashSet<ControllerContext>(); | | if (contexts.isEmpty() == false) | { | for (ControllerContext ctx : contexts) | { | - if (advance(ctx)) | + if (installing.contains(context) == false && advance(ctx)) | { | It might be an idea to test that for backwards compatiblity issuse at the same time? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4220291#4220291 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4220291

17 years

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Context installation causes StackOverflowError

by adrian＠jboss.org

https://jira.jboss.org/jira/browse/JBMICROCONT-421 The problem and "fix" is described on the above JIRA issue. Basically I've made the processing of resolved contexts more "width first" to avoid the unwanted/unneeded recursion. The fix is basically to add all the relevant resolved contexts to the "installing" set rather than just the current one. This avoids any recursive call to Controller.install() also seeing and processing those unresolved contexts. Like it says there, this needs to be validated against JBossAS, etc. to make sure it doesn't cause some unexpected problem. Ales can you do that? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4220290#4220290 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4220290

17 years

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: security and createQueue

by timfox

We need to distinguish between durable and non durable permissions. However I'm not sure we need to distinguish on temporary. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4220280#4220280 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4220280

17 years

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: security and createQueue

by jmesnil

I'm not in favor of allowing anyone to create non durable non temp queue: I prefer to grant permissions explicitly rather than implicetly. I'm also not in favor to add permissions for all the combination of (non)durable & non(temp) Dumb question: do we really need to distinguish between non durable and durable queue wrt to permissions? Can't we simply have 4 permissions: CREATE_QUEUE DELETE_QUEUE CREATE_TEMP_QUEUE DELETE_TEMP_QUEUE where CREATE_QUEUE & DELETE_QUEUE are checked wether the queue is durable or not? wdyt? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4220275#4220275 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4220275

17 years

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 March 2009