I think when such a problem arise, we need to do the following: * provide a default and simple implementation * make sure the implementation is easily pluggable so that aries consumers can easily replace the part with something more stuitable for their runtime I think the first point is important in order for basic users to be able to use aries components easily, have them deployed in an osgi runtime without requiring additional coding. This will help attracting more people and grow the users community (and hopefully then, the developers community). If we don't provide components that can be used directly, people will just go away. The second point is necessary to fullfil the requirements you expressed: i.e. when you embed an aries component into a given runtime, you may need a tighter integration with the runtime, hence the need for pluggable parts to replace.
In our case, a simple solution would be to have a simple module that will grab or create a default platform mbean server and register it in osgi. We could leave out creating a remote jmx connector and all, as this would soon have ties to the security bits and such ... On Thu, Oct 22, 2009 at 21:58, Alasdair Nottingham <[email protected]> wrote: > Hi, > > The JMX specification (taken from the March early draft) says the > following about the MBean server: > > "The construction, maintenance and lifecycle of the MBeanServer which > will host the MBeans defined in this specification is intentionally > left undefined. It is left undefined as the MBeanServer is invariably > tied to the particular application that is responsible for it. For > example, the MBeanServer may exist outside the OSGi framework that the > MBeans are managing. Or there may be multiple MBean servers which > contain the MBeans defined in this specification. The introduction of > nested frameworks, such as those defined in RFC 138, may have their > management MBeans hosted in the MBeanServer which hosts the MBeans for > the outermost OSGi container. Alternatively, these MBeans may be > hosted, for example, in an application server's MBeanServer which is > embedding mulitple OSGi containers." > > My interpretation of this is that the specification does not describe > how the MBeans are registered with an MBean server. So this JIRA seems > to go beyond what is required to implement the JMX specification. > > This is not necessarily a problem, but it does make me wonder if doing > this work is in the scope of the original incubator proposal. I think > registration of MBeans with an MBeanServer is the responsibility of > the runtime into which Aries has been embedded rather than the aries > podling itself. > > What do people think? > Alasdair > > 2009/10/21 Adam Wojtuniak (JIRA) <[email protected]>: >> Implement JMX Agent >> ------------------- >> >> Key: ARIES-29 >> URL: https://issues.apache.org/jira/browse/ARIES-29 >> Project: Aries >> Issue Type: New Feature >> Components: JMX >> Affects Versions: 1.0 >> Reporter: Adam Wojtuniak >> Fix For: 1.0 >> >> >> Implement JMX Agent. It should be responsible for tracking all MBean >> servers(registered as a services) and services which will be exposed as a >> Managed Beans (MBeans). >> JMX Agent should register following MBeans: Framework MBean, Bundle State >> MBean, Service State MBean, Package State MBean, Permission Admin MBean, >> Configuration Admin MBean, >> Provisioning Service MBean, User Admin MBean, Conditional Permission Admin >> MBean. >> It is open issue if we should track MBean servers registered as services but >> for now we can follow RI of JMX which listen to MBean Server services. >> For now we can track MBeanServers and when service is discovered register >> MBeans. Same in case when service is exposed as Managed MBeans it should be >> registered (on all available MBean servers) when is discovered. >> >> -- >> This message is automatically generated by JIRA. >> - >> You can reply to this email to add a comment to the issue online. >> >> > > > > -- > Alasdair Nottingham > [email protected] > -- Cheers, Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ Open Source SOA http://fusesource.com
