An update here... I've been able to decouple the o.a.b.controls.runtime.ControlBeanContext object from the BeanConext support classes in the JDK. The result is that the ControlBeanContext implementation now *implements* the java.beans.beancontext.* APIs and delegates to an implementation of BeanContextServices to implement these.
I'm sitting on a change that would make this implementation an instance of java.beans.beancontext.BeanContextServicesSupport and will likely commit this later today. All of the Controls and NetUI tests pass with this change. Once this is done, either Chad or I will look at allowing the implementation of BeanContextServices to be switched to his new classes. Eddie On 4/25/06, Eddie O'Neil <[EMAIL PROTECTED]> wrote:
All-- I've been profiling some of the code that Controls Core uses from the Java class library -- specifically the implementation classes for the BeanContext, BeanContextServices, and BeanContextChild APIs. As it turns out, these classes use a static, final, VM-wide lock: java.beans.beancontext.BeanContext.globalHierarchyLock that is used to serialize changes to a BeanContext bean hierarchy and service requests (as per its Javadoc). These JDK classes appear to have been written assuming that a bean hierarchy is VM-wide or is at rooted in a shared ancestor in the VM. This is very different from how hierarchies of bean contexts are maintained in enterprise applications where they may be scoped to a page flow, session, application, or container. In the case of NetUI, for example, there is a hierarchy of these beans for every Page Flow. Having these hierarchies share a lock with every other page flow for every user in every web application can cause obvious performance problems. Thus, I'd suggest that we start down the path of providing an implementation of the BeanContext / BeanContextServices / BeanContextChild APIs in order to make the locking patterns required in these classes more granular. For how we tend to use these classes in NetUI and in the ControlFilter (web tier use cases), the ControlBeanContext / ControlContainerContext / ServletBeanContext objects are either soped to a single request or protected by a larger framework and thus single threaded. So, let's build something that reflects this by being single threaded, *fast*, and by making control instantiation very inexpensive. I'm going to look at two options for the existing CBC / CCC / SBC objects: 1) changing the CBC object to delegate to an implementation of the BeanContextServices interface(s) 2) forking these classes and then adding implementations of the interfaces in the java.beans.beancontext package Other thoughts / suggestions welcome. :) Eddie
