On Sun, 2004-03-07 at 02:20, Adrian Brock wrote:
> 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 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.
>
> > 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.
>
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
> 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
