On Friday 16 November 2001 09:17 am, you wrote: > Block X supports XMBean service. (Theoretically multiple blocks could > actually support the same management interface). So it may be a good idea > to put the management support info (like the Descriptions etc) into another > file that is same name as > > SO we would end up with something like > > com/biz/blocks/MyBlock.class > com/biz/blocks/MyBlock.xinfo > com/biz/services/MyService.class > com/biz/services/MyServiceMBean.class > com/biz/services/MyServiceMBean.xml > > > and it would be "com/biz/services/MyServiceMBean.xml" that described the > MBean in all its glory. That way if another block implemented that service > it would automatically inherit all that management metadata.
I think making management at the service level is a good start, but you really want to manage blocks, IMHO. Maybe if the management of a block was an aggregate of all the services it implements + any block specific items? Configuration is something we just had to deal with here as our phoenix app was installed at the first customer this week (whoho!). The primary end-user configurable things we have are the DataSource and a block that handles archiving to disk. We have an installer using InstallAnywhere and it currently edits the config.xml that is inside of the SAR. What would be nice, would be a way to deploy an app in an "unconfigured" state, and then let the user come and use a JMX tool to configure it. What do others do as far as deploying phoenix apps? Are you developing custom apps for a single client so you don't have many issues, or are you developing software that will be deployed to many client sites? -pete -- peter royal -> [EMAIL PROTECTED] -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
