There is no "OnUnDemand", i.e. automatically removing an unreferenced
bean when its dependencies are undeployed.
This is mainly because I don't want the OnDemand bean to bounce when its only
dependee is redeployed.
This will change when I add support for more direct/atomic redeploy.
Do we need any other modes? Most of the usecases I can think of
can be done with these primitives.
The only additional feature I plan to support is the "registry" type of OnDemand.
e.g. jms queue uses OnDemand jms destination manager which not only bootstraps
the destination manager (if not done so already)
but also does manager.register/unregisterDestination() as they are undeployed.
Making this a first class notion removes the need for this boiler plate code in every
service and also allows extra semantics to be placed at this "JoinPoint" since it is described
to the controller/microcontainer.
What is the correlation with these states and any management exposure, or is that an arbitrary aspect that depends on the service configuration?
Can you repeat the question in English :-)
Let me explain the recent changes in one place...
I have changed the controller along the lines mentioned in this thread:
This allows different context models to be plugged into the same controller
and take part in the same lifecycle, i.e. dependencies
Currently, there are two models envisioned
1) The new BeanMetaData from the pojo microcontainer
2) The "ServiceContext" from the jmx microcontainer
It is left to each model to interpret what happens during the different state
transfers, though they have similar meanings across the models:
NOT_INSTALLED - the controller knows about the context
DESCRIBED - the model has examined the metadata
INSTANTIATED - the target is constructed
CONFIGURED - the target is configured (setters invoked)
CREATE - the create method is invoked
START - the start method is invoked
INSTALLED - the target is enabled for "external" use
There is a corresponding reverse set of states.
The states are also pluggable, i.e. you can insert new states in the Controller,
though existing models will NOOP the state transfer if they don't understand it.
I have only envisioned linear state models (with install/uninstall callbacks)
at the moment, though a graph might also be possible, if more complicated,
should a usecase demand it.
On top of this, we have the MODE which is the discussion in this thread.
The current JMX model has no such notion (everything is MANUAL
with the AUTOMATIC behaviour an illusion provided by the deployers).
I plan to retrofit the MODE into the JMX model for deployment/management
i.e. at least the ServiceController, ServiceMBean and -service.xml.
Doing the other deployers will take more work since their xml is not always
simply related to the MBeans they control.
Got it. The question was concerning the existence of the pure jmx mbean in relation to the ServiceContext integration, as well as the desire to expose a management aspect for a BeanMetaData.
With a fixed state model with explicit methods, these methods are the join points for the introduction of adding the management aspect. With a pluggable state model, where is this defined?
The management advice (I think you mean advice/interceptor by aspect?)
would need to introduce the additional JMX operations
target.setControllerState(state) -> controller.change(context, state) target.setControllerMode(mode) -> context.setMode(mode)
Just like ServiceMBeanSupport does now with the redirect through the
Otherwise, you can always manage contexts through the controller directly.
I'm not following the ServiceMBeanSupport. Maybe there should be another thread on aspects like mangement should be integrated into the lifecycle as I have another question on the MODE behavior which I don't want to pollute with endless sidetracks.
So I think another quasi-mode is OnDemandIfRequired. The usecase exists today between the ejb-deployer and the dynamic-classloading-service. If a dynamic-classloading-service is configured for use in any mode, the ejb-deployer should have an optional dependency on it. This means that if the dynamic-classloading-service exists and could become avaialble, add a dependency between ejb-deployer and dynamic-classloading-service. If there is no usable dynamic-classloading-service either because it does not exist or is disabled, do not add a dependency.
The OnDemandIfRequired mode would be OnDemand only if the dependents are not optional. In the ejb-deployer/dynamic-classloading-service case, I probably really would want just OnDemand semantics.
I'm not clear that OnDemandIfRequired is useful, but the optional dependency certainly is. Is that a notion that already exists?
I know what you are trying to do, but I'm not sure how it could be made to work
in a dynamic environment.
EJBDeployer isDeployed and started (ifRequired wasn't resolved)
DynamicClassLoading is deployed
Oops we are in the wrong order so the EJB wasn't processed for DynamicClassLoading.
This isn't really a dependency, more of an "optional dynamic plugin" that will require
the service accepting the plugin to do extra work.
Maybe this could be made to work with the registry stuff I described earlier.
Something like (this is just thinking out loud):
<bean class="EJBDeployer"> <property name="dynamicClassLoading"> <plugin bean="DynamicClassLoading" register="addDeployer" unregister="removeDeployer"/> </propertiy> </bean>
"plugin" works like "inject" except it doesn't make the EJBDeployer wait for the DynamicClassLoading.
"register" is the hypothetical "registry" processing from earlier.
So when DynamicClassLoading is available it does
The ejbDeployer and dynamicClassLoading would still need some callback
protocol to do their work.
i.e. process earlier deployments and add new ones
So this gets back to the notion of knowing the existence of a component configuration at some point in the server lifecycle due to a static/deterministic configuration. The usecase I want is a static configuration one. There is a dependency injection of the DynamicClassLoading plugin, ONLY if there is a supplier of this service. If the server has been configured to not include a DynamicClassLoading, then there should be no dependency and obviously there will no injection.
This is not a relationship I can specify between truly dynamic services in a meaningful way due to the "what do I do now" interaction between the DynamicClassLoading and EJBDeployer that you describe.
There is nothing wrong with supporting such an injection sematic such that if a provider of the DynamicClassLoading plugin shows up, it will be used for subsequent deployments.
What I was looking for was more of a declarative dependency that allows one to know that at some point in time when the mc configuration has reached some known state (t=0 for a purely static configuration, could be latter if configuration is pulled from another source), there either is a DynamicClassLoading provider and a dependency is needed to ensure all ejb deployments have a DynamicClassLoader, or there is no such provider and no ejb deployment support dynamic class loading.
I never updated this thread with the real answer to this problem.
Basically, what you need is a policy object that can be injected. Something like:
<bean name="RemoteCL" class="whatever"/> <bean name="EJBDeployer" ...> <property name="RemoteCL"><inject name="RemoteCL"/></property> </bean> or even better?.... <bean name="MyEJB" class="org.jboss.ejb.Container"> <property name="RemoteCL"><inject name="EJBDeployer" property="RemoteCL"/></property> </bean>
Then what you can do is have RemoteCL be defined as either a Null
implementation or a real implementation.
If you change the implementation of RemoteCL by redeploying its dds
it will automatically restart the EJBDeployer/MyEJB with the new config.
You don't need the notion of optional, you just need a placeholder that has
a Null/NOOP implementation.