"scott.stark(a)jboss.org" wrote : See the updated org.jboss.test.kernel.deployment.support.container.* classes with BeanContainer, BeanPool, etc.
|
This BeanPool class looks pretty broken:
| public synchronized T createBean()
| throws Throwable
| {
| if(pool.size() == 0)
| {
| // Fill the pool
| for(int n = 0; n < pool.size(); n ++)
| {
| T bean = (T) factory.createBean();
| pool.put(bean);
| }
| }
| return pool.take();
| }
|
The pool field is never instantiated - unless you're gonna do field injection.
And you have an if on size == 0, and then you iterate till size - which is 0.
OK, I know it's a test class. :-)
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4138182#4138182
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4138182
Its the xml I showed in this beanfactory extensions thread:
http://www.jboss.com/index.html?module=bb&op=viewtopic&t=132158
I checked in a test org.jboss.test.kernel.deployment.support.container.TestPooledBeanFactory with a simple bounded queue pool that is prefilled on first use.
The disconnect between the xml and any current psuedo code is that there is a one to one association between the bean metadata/xml and the instances upon which injection happens.
To exercise the pool exhaustion scenario, you have to create multiple instances of Bean2Type, injecting multiple instances of Bean1Type. This behavior is not part of the current mc core. The test needs to wire things up at the metadata level and then call the org.jboss.test.kernel.deployment.support.container.BeanContainer.getBean() multiple times to create the Bean2Type instances which should have new Bean1Type instances injected.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4138171#4138171
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4138171