This is great...debugging with proxies has been a real PITA...this will *really* help.
Hiram Chirino wrote: > +1 from me too. Way back when I was working on the ActiveMQ - > Geronimo integration, the poxies gave me a few headaches. > > Regards, > Hiram > > On 3/19/06, Matt Hogstrom <[EMAIL PROTECTED]> wrote: >> +1...the debugging thing has been a problem. If for no other reason this is >> the >> right thing to do. However, there will be users who care less about >> isolation >> and more about memory and speed. This gives them the choice to run exposed >> to >> get what they want. >> >> Matt >> >> Dain Sundstrom wrote: >>> On Mar 18, 2006, at 5:18 AM, John Sisson wrote: >>> >>>> Dain Sundstrom wrote: >>>> >>>>> Forgot to mention, I added an experimental flag to 1.1 which will >>>>> turn off proxying in GBean references. This means that the injected >>>>> reference will be the actual service instance and not a proxy to the >>>>> service. My guess is this will break a few services that use >>>>> ProxyManager.getProxyTarget(Objcet), since the reference won't be a >>>>> proxy. All of these uses will have be rewritten to not assume a >>>>> proxy if we want to keep use this flag. >>>>> >>>>> To turn it on, you simply set the system property >>>>> org.apache.geronimo.gbean.NoProxy=true. This is property is picked >>>>> up by a static block in the AbstractGBeanReference class, so the >>>>> property will apply for the life of the kernel class loader >>>>> (normally the life of the vm). >>>>> >>>>> -dain >>>>> >>>>> >>>> What was the reason for this experiment? >>> >>> I'd like to completely remove proxying between gbeans in the future, >>> but I think it would lots break stuff to just flip it over right now. >>> Proxying between GBeans is problematic because it changes the expected >>> programming model of component writers. When you are giving out >>> proxies instead of the instance, the user can no longer use == for >>> comparison, and the since proxies are so much slower, the expected >>> overhead of a call is much higher. Both of these require require >>> changes to the component for it to run in geronimo, and if we want to >>> have the largest component base, we're going to have to change. >>> >>> Besides all of that, it is really a PITA to debug geronimo since you >>> have to step through all of those proxies, for really no reason. >>> >>> -dain >>> >>> >>> > > > -- > Regards, > Hiram
