From: Richard S. H. <he...@un...> - 2002-07-06 09:37:37
|
Andreas Schaefer wrote: >JBoss uses Java Management eXtension (JMX) as >communication bus between the modules of JBoss. >Thus it is possible to change the implementation of >the modules and they can still work together as long >as the needed methods are available because the >references to the module is resolved when the call >is made. > Yes, JMX is similar to OSGi in many ways. The main difference, though, is that JMX is intended to expose "management" interfaces not application interfaces. The MBeans of JMX control instrumented "resouces"; of course, you could combine the "resource" as well as the management interface into the MBean, but this is not the exact point of JMX. >Transferred this to jEdit this would allow to change >jEdit as well as the plugins without depending directly >on each other and thus jEdit can change the API of >the textarea etc. and still old and new plugins can still >work with jEdit. > This is slightly overstated, as long as the APIs changed in compatible ways, they would still be compatible. If jEdit combined one method into two or divided one into two, then old plugins would be broken, just like normal. >It would also allow plugins to lookup >other plugins and investigate their API and work with >it without directly now the real implementation. So a >project management plugin could look up a pretty >formatter and then ask it to make a nice layout and this >on every file in the project. This sounds simple but is >powerful because it can work with any formatter plugin >as long as they can agree on a certain set of methods. > Yes, this is one of the exact benefits that I was describing for OSGi. This is the type of thing that I plan to do with my Oscar plugin for jEdit. >JMX also allows to load classes at real time and in >JBoss 3.0 the unified class loader allows to reload >classes (!!) at runtime. > Yes, this is also the point of OSGi. Actually, from my reading of JMX, class loading and delivery of MBeans seems to be an after thought, whereas in OSGi, this is the whole point. OSGi is barely more than a super-ClassLoader with a service registry. >Last but not least it would allow to access components >on another (even remote) JVM without any changes in >the code. For example this would allow to provide a >life preview from plugin-central. > Yep, as long as there is a remote interface, just like OSGi. I think both JMX and OSGi are reasonable candidates, but I would argue that OSGi is better in this case since it was specified to do exactly what is desired here; plugins are not really a "management" issue. The whole point of OSGi is to build applications out of a collection of loosely couple services...this sounds a lot like plugins. Additionally, OSGi is probably simpler conceptually...some could argue about this I suppose, but after reading both specs this is my conclusion. -> richard |