-
1. Re: KernelControllerContext vs. KernelRegistryEntry
adrian.brock Mar 7, 2005 2:43 PM (in response to lhazlewood)I don't think I like the idea of a bean going directly into the registry.
Although it is certainly possible to implement it that way with the new
container, you lose some features.
(This is one of the problems with the current JMX micro kernel where MBeans
that do not go through the ServiceController cannot take part in the service lifecyle/dependencies).
With the new container, the beans can take part in dependency injection
on other objects, but there is nothing to say that that bean's dependencies
can be satisifed in a hot deployment environment.
In general it bypasses the controller's ability to control lifecycle.
Such a feature is more of a user requirement. Where they don't care about
dependency ordering and are happy to get runtime exceptions (NullPointerException?)
when dependencies are not satisfied, instead of deploying beans and
the controller stopping them even getting exposed/run if there is problem.
A better approach is to use something like the GenericBeanFactory I just committed.
i.e. you inject a factory that can control object instantiation rules.
Generically, it is much better for users to do (a purer IOC?):public void setFactory(MyFactory f) { X x = f.create(); } <bean class="MyClass"> <property name="factory"><depends name="MyFactory"/></property> etc. <bean class="GenericBeanFactory" name="MyFactory"> <factory and bean config goes here/> etc.
than a locator style pattern, especially if the beans are
going straight into the registry instead of AppConfig being
constructed through dependency injection for each of its partspublic void setAppConfig(AppConfig appConfig) { X x = (X) appConfig.getBean("SomeNameForX"); }
-
2. Re: KernelControllerContext vs. KernelRegistryEntry
lhazlewood Mar 10, 2005 6:28 PM (in response to lhazlewood)I agree with you that it is better to define beans in xml or use annotations so IoC/lifecycle management can occur. I'm just providing a basic feature that is often pretty useful.
For example, maybe an object can only be created programmatically after the container starts up (e.g. because the object is constructed w/ user input). But other components may need that actual instance after its been created.
So instead of using static memory, its better to put it in the bean container so that other container aware objects can retrieve it when they need it (or if they implement event callbacks, they can be notified when the object gets put in the container and acquire it at that moment - even better).
Even though this won't be used often, it is a really convenient feature to have in your back pocket :)
Les