Service Lifecyle confusions - potential fix

[starksm64]

The state machine was not immeadiately for the service layer, but
will be used to enforce illegal transitions if we decide on a state
diagram.

The suggested change makes sense, but the other problem is the fact
that the deployment layer is out of the loop in this. I would like
to couple dependency and life cycle to delay the creation of the
service as an mbean, but have not really looked at how big a change
this is.

Are you working on the Service lifecycle?
I saw you replaced common's state machine implementation.

I was thinking that there should be an extra indirection to avoid the confusion caused by people clicking stop() and other operations in the console where dependencies are not taken into account.

My idea is that you implement an extra operation in ServiceMBeanSupport

public void jbossServiceLifecylce(String operation) throws Exception { if (operation.equals("create")) { // the current create() method } etc.
}

This would be invoked from ServiceController.ServiceProxy when it is implemented by the MBean.

This would allow us to change the current
ServiceMBeanSupport.create() to be:
serviceController.create(serviceName);
etc.

Now clicking stop() in the console goes via the service controller making sure dependencies are also stopped.

This doesn't fix the problem for MBeans that do not extend ServiceMBeanSupport. These would still do the old behaviour.
Similar changes would be required to ServiceDynamicMBeanSupport and the XMBean descriptor include.

Regards,
Adrian

--
xxxxxxxxxxxxxxxxxxxxxxxx
Adrian Brock
Director of Support
Back Office
JBoss Inc.
xxxxxxxxxxxxxxxxxxxxxxxx

[starksm64]

I'm not seeing how IOC is sufficient to bring up a web container for example. There still needs to be a start notion that allows the service
to configure all of its internals it seems. How would start on the service interceptor be able to do this?

I actually feel lifecycle is unnecessary if read-ahead and IOC was implemented. It would be replaced by ordered configuration and valves. The user would have two options start/stop the valve or deploy/undeploy the service.

One solution would be to run core services/deployers in "ring zero"
a sort of controlling sub-machine/extensible kernel. This would make other services slightly second class citizens.
This still does not solve the problem generally, e.g.
1) how to allow pluggable logging (currently implemented with a boot.log and server.log)
2) how to run the boot under a security context and still have pluggable security
3) what if you want your mbean persistence from the db for your core services when the db connection isn't deployed until later

It's almost like you a need a separate bootstrap "process"
that boots enough to configure the main machine before being discarded in favour of it? A bit like the bios/boot block in the pc.

Regards,
Adrian

[adrian.brock]

Yes, there would still need to be lifecycle for components that don't support IOC.

I don't see start() as a configuration issue.
Start is a valve operation on an already confgured service, typically performing
things like jndi or server port binding.
e.g. for a webapp it would link an already configured webcontext to the web container.

What are examples where configuration can only be done at activation?
e.g.
currently:
void setJNDIName(String jndiName)
{
this.jndiName = jndiName;
}
void startService()
{
Util.bind(jndiName, this);
}

can be replaced with:
void setJNDIBinding(JNDIBinding binding)
{
binding.setBoundObject(this);
}

leaving the container to handle the real binding

Regards,
Adrian

[adrian.brock]

Bill Burke wrote:

I was also hoping that you could supply a mixin class that handled
service lifecycle so that POJO's could be involved with lifecycle and
not have to implement any interface.

Hmmmm, I guess you could do this with AOP introduction.

Bill

[bill.burke]

Not sure what you mean here adrian. Some services require a 2 stage startup. Clustering is an example. At create time, all services register with the ClusterPartition for events. Then in start(), ClusterPartition actuall joins the group. This is so that all state synchronization services can register for the initial state synch before the cluster partition joins the group.

Bill

[starksm64]

Right, I agree, start is not a configuration issue, and we don't use it as such now. It is a lifecycle op to notify the component to use the current configuration to bring the component into the start state. In a pojo framework with only aspects/interceptors introducing the service level functionality start can be handled outside of the component.

For integrating containers like the web container which already have a lifecycle notion its easier to simply delegate the start op to the component to bring up its connectors, etc. Its not that the web container does not support IOC, its already does by virtue of the mbean attributes. Taking all of the configuration info to a running web container is no something I can see being done by an IOC framework though.

[adrian.brock]

Hi Bill,

I'm arguing that the two stages are really two different ideas.

The first phase is configuration/deployment where the stateful services are
configured to be part of the cluster partition.
This is what needs to be ordered so we can build up the services
into a ready service in the correct order and provide information to the valves
about needs to happen during phase 2.

Phase 2 is where we release the valve (in this case let the partition
join the grousp).
I see what you mean by the callbacks, they are a form of lifecycle
but these aren't really configuration.

Phase 2's start/stop valve operations can be invoked from deployment
or manually from some the console.
You could configure some services to be "deployed" but not active,
i.e. phase 2 does not happen at startup, it is either a manual process
(or even lazily done when the service is actually used).

Regards,
Adrian