October 2007 - jboss-dev-forums - Jboss List Archives

[Design of AOP on JBoss (Aspects/JBoss)] - Re: ClassLoading Module usage

by kabir.khan＠jboss.com

"adrian(a)jboss.org" wrote : "kabir.khan(a)jboss.com" wrote : | | AFAICT we don't know this at the time the classloader is created? So basically we need to turn off blacklisting of all classloaders in jboss 5? | | What stops you from knowing this? | | We have a new deployment, and create the classloader. At this stage we have no idea what classes are contained nor whether any of these will match any aspects deployed. I am not arguing for turning off the blacklist completely, I was just pointing out that as far as I can see without the ability to flush the blacklist I could not see any other way. I think you said that adding a flush method is OK? :-) Should the whole blackList be cleared, or just a single entry? | void flushBlackList(); | or | void flushBlackList(String classname); | I think the second option will suffice for my needs View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4096980#4096980 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4096980

18 years, 5 months

1
0
0 / 0

[Design of AOP on JBoss (Aspects/JBoss)] - Re: ClassLoading Module usage

by adrian＠jboss.org

"adrian(a)jboss.org" wrote : | Why I don't like it, is that there can be a local blacklist and a global blacklist. | Turning off the blacklist after the classloader has been created and added to the | domain could leave the global one in an inconsistent state unless extra steps | are taken to flush it. | This can get even more complicated where you have stacks of domains caching the results of parent domain lookups. Any flush on the parent would meaning flushing all the children as well. This complication is actually avoided in the current implementation because it doesn't cache the parent result. It assumes the parent will do it if it is required. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4096979#4096979 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4096979

18 years, 5 months

1
0
0 / 0

[Design of Security on JBoss] - Re: SRP and SASL

by david.lloyd＠jboss.com

I'm working from: http://tools.ietf.org/id/draft-burdis-cat-srp-sasl-08.txt which, as far as I can see, was the latest published. It seems perfectly compatible with SASL, it's just Java's SASL API that is lacking the notion of acquiring a verifier on the server side. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4096977#4096977 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4096977

18 years, 5 months

1
0
0 / 0

[Design of AOP on JBoss (Aspects/JBoss)] - Re: ClassLoading Module usage

by adrian＠jboss.org

"kabir.khan(a)jboss.com" wrote : | AFAICT we don't know this at the time the classloader is created? So basically we need to turn off blacklisting of all classloaders in jboss 5? What stops you from knowing this? In practice, for the "importAll" handling, any classloader that has no blacklist means all subsequent classloaders can't have one either. (Well actually they can have a local one, but no global one). A better solution would be if we could "intercept" the defineClass() and automatically flush the related blacklists. But unfortunately, the method is "final". I'm not actually too adverse to this change (it isn't like it is a dangerous operation ;-), and we already have a mechanism to bypass the classloading and access the cache on the RealClassLoader http://viewvc.jboss.org/cgi-bin/viewvc.cgi/jbossas/projects/integration/t... for the potential performance gain, so adding a flush{cache|blacklist} mechanism to the RealClassLoader spi wouldn't be that big a change. Why I don't like it, is that there can be a local blacklist and a global blacklist. Turning off the blacklist after the classloader has been created and added to the domain could leave the global one in an inconsistent state unless extra steps are taken to flush it. It seems to me that flushing the blacklists (whenever you define a class outside the normal classloading mechanism) is better than turning it off altogether? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4096975#4096975 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4096975

18 years, 5 months

1
0
0 / 0

[Design of POJO Server] - JBoss VFS release

by kabir.khan＠jboss.com

I need a jboss-vfs release to make the changes I made for this http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4096968#4096968 available to MC and AS5 View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4096973#4096973 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4096973

18 years, 5 months

1
0
0 / 0

[Design of AOP on JBoss (Aspects/JBoss)] - Re: ClassLoading Module usage

by kabir.khan＠jboss.com

"adrian(a)jboss.org" wrote : | Why aren't the java.* enhancements added to the root classloader? | This would seem like the more sensible location to control overriding standard | classes and it would just be one place to say it always "exports" the default package. I think I like this idea View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4096968#4096968 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4096968

18 years, 5 months

1
0
0 / 0

[Design of AOP on JBoss (Aspects/JBoss)] - Re: ClassLoading Module usage

by kabir.khan＠jboss.com

"adrian(a)jboss.org" wrote : I don't like either of these. :-) | | "kabir.khan(a)jboss.com" wrote : | | Without clearing the black list, the new class is never picked up. Can we include a method to do this in the spi? We would not even need to clear the whole set, just a particular entry. The domain already has a method for this, but I need it on BaseClassLoader. | | | | It shouldn't be blacklisting at all if classes can suddenly appear. | This just needs adding to the ClassLoaderMetaData, i.e. whether | caching and blacklisting can be done for the classloader. | AFAICT we don't know this at the time the classloader is created? So basically we need to turn off blacklisting of all classloaders in jboss 5? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4096966#4096966 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4096966

18 years, 5 months

1
0
0 / 0

[Design of AOP on JBoss (Aspects/JBoss)] - Re: ClassLoading Module usage

by adrian＠jboss.org

I don't like either of these. :-) "kabir.khan(a)jboss.com" wrote : | Without clearing the black list, the new class is never picked up. Can we include a method to do this in the spi? We would not even need to clear the whole set, just a particular entry. The domain already has a method for this, but I need it on BaseClassLoader. | It shouldn't be blacklisting at all if classes can suddenly appear. This just needs adding to the ClassLoaderMetaData, i.e. whether caching and blacklisting can be done for the classloader. anonymous wrote : | Another problem is if a generated AOP proxy is not in the same package as the proxied class (e.g. if the proxied super class is in the java.lang package, we create a proxy in the default package instead). This causes a problem since the underlying ClassLoaderDomain.classLoadersByPackageName does not get updated to include the default package, so the class is never found. Adding this, would mean people can play around things in dangerous ways (like the URLClassLoader.addURL() that I want to avoid). It's also not going to work with the OSGi style rules where you are explicitly importing/exporting package names. Why aren't the java.* enhancements added to the root classloader? This would seem like the more sensible location to control overriding standard classes and it would just be one place to say it always "exports" the default package. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4096963#4096963 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4096963

18 years, 5 months

1
0
0 / 0

[Design of POJO Server] - Re: mbean to bean conversion guide

by scott.stark＠jboss.org

All possible, but it should be described first, and then whatever obfuscated encoding of that knowledge we want to create can be done as needed. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4096962#4096962 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4096962

18 years, 5 months

1
0
0 / 0

[Design of POJO Server] - Re: AppClientDeployer

by scott.stark＠jboss.org

I have a deployment going through the deployers and getting to the Ejb3ClientDeployer which is installing a ClientENCInjectionContainer bean. The client enc is not getting setup though, presumably because the injectors don't have the metadata. The old ejb3 metadata propagates out the injectors via the EnvironmentRefGroup. I have started working on a EnvironmentRefGroupConveter that takes the new JBossClientMetaData.getJBossJndiEnvironmentRefsGroup and exposes this as a EnvironmentRefGroup. The question is this worth doing, or should this start using the new metadata model? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4096959#4096959 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4096959

18 years, 5 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 October 2007