On Sun, 2004-03-07 at 02:08, Scott M Stark wrote:
> 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 wasn't considering deployment, only lifecyle.
> 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.
My preferred solution for this to read-ahead all deployments
to determine the full graph (including class and jndi dependencies)
before any deployment starts. You can then inject configuration IOC
style. It would also give enough information to allow a realistic
valve implementation.
I haven't figured out how you identify the deployers or the scanner
as special - i.e. allowing their initial processing before the full
graph has been read - so they can contribute to the graph.
I'd also like to introduce cleverer (more fine grained) dependency
information like the ejb deployer should not depend upon jms.
Instead it should be based on whether jms is used, either by an
mdb or a resource-ref.
This would potentially allow the jmx-console to deploy eariler rather
than waiting for unnecessary dependencies specified on the web deployer.
Regards,
Adrian
>
> xxxxxxxxxxxxxxxxxxxxxxxx
> Scott Stark
> Chief Technology Officer
> JBoss Group, LLC
> xxxxxxxxxxxxxxxxxxxxxxxx
>
> > -----Original Message-----
> > From: Adrian Brock
> > Sent: Saturday, March 06, 2004 5:24 PM
> > To: Scott M Stark
> > Cc: [EMAIL PROTECTED]; The Core
> > Subject: Service Lifecyle confusions - potential fix
> >
> > Hi Scott,
> >
> > 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
> >
> >
> >
--
xxxxxxxxxxxxxxxxxxxxxxxx
Adrian Brock
Director of Support
Back Office
JBoss Inc.
xxxxxxxxxxxxxxxxxxxxxxxx
-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
_______________________________________________
JBoss-Development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
