[Design the new POJO MicroContainer] - Re: Scoped Kernels
by alesj
"alesj" wrote :
| 3) While testing, how to get the actual bean / context from bootstrapping kernel / controller, since the real bean / context is present in some scoped child controller.
I've added this:
| private class TestController extends AbstractController
| {
| private AbstractController delegate;
|
| public TestController(AbstractController controller) throws Exception
| {
| this.delegate = controller;
| }
|
| public ControllerContext getContext(Object name, ControllerState state)
| {
| return findContext(delegate, name, state);
| }
|
| private ControllerContext findContext(AbstractController controller, Object name, ControllerState state)
| {
| ControllerContext context = controller.getContext(name, state);
| if (context != null)
| {
| return context;
| }
| else
| {
| for (AbstractController childController : controller.getControllers())
| {
| ControllerContext ctx = findContext(childController, name, state);
| if (ctx != null)
| return ctx;
| }
| }
| return null;
| }
| }
|
I have some public methods in AbstractController that it would be better if they were not public. I'll fix them later - when we decide what to put in SPI.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4019841#4019841
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4019841
19 years, 1 month
[Design the new POJO MicroContainer] - Re: Scoped Kernels
by alesj
I'm quite done with scoping, but I have encountered a few problems:
1) When a bean that represents the classloader for other beans is deployed in some scope, other dependent beans (from same scope) are unable to find him - since they are not described yet == no scope knowlegde.
2) If I deploy bean with the same name and the same class in 2 different scopes, KernelControllerContext scope lacks some differentiation between different context instances - fullScope with INSTANCE and CLASS is the same for both context instances. I currently added context's hash under WORK level, to be able to test this.
3) While testing, how to get the actual bean / context from bootstrapping kernel / controller, since the real bean / context is present in some scoped child controller.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4019809#4019809
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4019809
19 years, 1 month
[Design of JCA on JBoss] - Re: JCA antipattern? Or not?
by weston.price@jboss.com
anonymous wrote :
| BTW is there much doco about using jca jms resource adapter to do this from an MBean? They are not using mdbs.
|
The JMS RA is targeted towards message endpoint deployments. Today, it requires MDB's to function correctly. Basically the JMS/JCA RA takes the place of the JMSContainerInvoker in JBoss 3.x and early version of JBoss 4.x.
I would be willing to bet the lionshare of the problem with the Spring example is the use of non ASF facilities in application server environment to 'simulate' MDB type semantics using a 'poll' type mechanism for delivery (ie cons.receive()) rather than the ASF ConnectionConsumer wherein the provider is responsible for 'pushing' messages. There is nothing to prevent them from using ASF in their own code, but I would be willing to bet the Spring stuff does not which is causing problems.
Since what they want is non standard and outside the purview of both the JCA and JMS/ASF spec they would have to develop a custom RA to do this.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4019606#4019606
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4019606
19 years, 1 month