Berin Loritsch wrote: > I want to know what is easiest for Phoenix to expose as a JMX interface. > The issue is that I have multiple Jobs that I am managing, each of them > needs to have some controls exposed. Here is what I need to be able > to control for each Job: > > Start > Stop > Status > > I also need to be able to load new jobs, remove old jobs, etc.
Let me play this back to you, using terms i'm more comfortable with, to see if i understand what you're looking for. There is a phoenix application. One feature of this application involves managing 'jobs'. This feature is implemented via a JobManager component (block). Each job has a number of attributes and operations. These features should be exposed via the 'standard' management mechanism. In a tree view it might look like this: -+-> Phoenix | +--+-> Applications | | | +--+-> ApplicationThatHasJobs | | | | | +--+-> Blocks | | | | | +--+-> JobManager | | | | | | | +--+-> Jobs | | | +----> Job 1 | | | +----> Job 2 | | | | | +----> UserManager | | | +----> AnotherApplication | +--+-> Components Everything is ok until we get down to the management of individual jobs - the rest can be already be done. So the problem here is how is to allow blocks to register additional objects for management 'beneath' them. Basically, the way I see this working is to have the BlockContext makes it Management Context (an implementation of the SystemManager interface) available to Block, and then use that to create a Jobs subcontext: SystemManager blockMgmtContext = blockContext.getManagementContext() SystemManager jobMgmtContext = blockMgmtContext.getSubContext( "Blocks", "Jobs" ); Then the Block would register & unregister jobs on the jobMgmtContext: Job jobOne = ... get the job somehow jobMgmtContext.register( jobOne.getName(), jobOne ); The methods to expose by the job would be determined from its mxinfo file. Does that start to address the issue? - Huw -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
