On 3/22/06, David Jencks <[EMAIL PROTECTED]> wrote:
>
> On Mar 22, 2006, at 11:12 AM, Hiram Chirino wrote:
>
> > Awesome! This could give me a kewl approach to exposing the ActiveMQ
> > objects in Geronimo.. Now if I could just have complex data (like
> > say an xml fragment) injected into a gbean, then I would be so happy.
>
> You could do this today with an XmlAttribute. You just need to write
> an XmlAttributeBuilder for an appropriate namespace that puts the xml
> as an appropriate object (string? dom?) into the gbean attribute.
> This would be a lot simpler than the existing XmlAttributeBuilders
> which actually parse the xml and construct objects.
>
Fabulous!
> >
> > Then I could implement 1 coarse gbean the represents the activemq
> > broker with 1 configuration element that is the xbean xml
> > configuration. The coarse gbean would start up activemq using xbean +
> > the xml fragment. And then the broker would expose object to the
> > GBean kernel using dynamic registration similar to how it expose
> > object the JMX MBean server today.
> >
> So the gbeans put in the kernel would have as attributes the xbean-
> created objects that they wrap?
>
Not exactly. The xbean objects are just used to configure the broker
and that is not even close to what runtime management view of a broker
is. I guess the closest analogy is the xbean config is like the
deployment descriptor for EJB, the elements in the descriptor do not
map to GBeans directly.
> If you know what the wrapping gbeans are going to be at deploy time,
> you could also:
>
We don't know about all gbeans we will need ahead of time. Stuff like
queues, topics, connections, and subscriptions are created and
destroyed at runtime as users send requests through the broker.
> put the wrapping gbeans in the plan
> give each one a reference to the coarse-grained "setup" gbean
> when a wrapping gbean starts, it extracts the component it wraps from
> the "setup" gbean
>
> This would avoid the need to dynamically create and register gbeans.
> > What do you guys think? Is that possible or do you think it's a
> > bad idea?
> >
>
> I think it's possible, I don't know if it would be worth the work
> compared to waiting for a less rube-goldberg-inspired solution.
>
Thanks for the input David! I'll have to consider this more before I
commit to a approach.
> thanks
> david jencks
>
> > On 3/22/06, Aaron Mulder <[EMAIL PROTECTED]> wrote:
> >> Yes, you can. To add a GBean, fill out a GBeanData and then do
> >> something like this:
> >>
> >> Kernel kernel = ... (injected)
> >> ObjectName mine = (creator object name, normally injected)
> >> ObjectName oName = (new GBean object name)
> >> GBeanData data = ...
> >>
> >> EditableConfigurationManager mgr =
> >> ConfigurationUtil.getEditableConfigurationManager(kernel);
> >> if(mgr != null) {
> >> try {
> >> ObjectName config = Util.getConfiguration(kernel,
> >> mine);
> >>
> >> mgr.addGBeanToConfiguration(Configuration.getConfigurationID(config),
> >> data, true);
> >> return (...)
> >> kernel.getProxyManager().createProxy(oName, SomeInterface.class);
> >> } catch (InvalidConfigException e) {
> >> log.error("Should never happen", e);
> >> } catch (URISyntaxException e) {
> >> log.error("Should never happen", e);
> >> } finally {
> >> ConfigurationUtil.releaseConfigurationManager
> >> (kernel, mgr);
> >> }
> >> } else {
> >> log.warn("The ConfigurationManager in the kernel does not
> >> allow changes at runtime");
> >> }
> >> return null;
> >>
> >> I haven't looked at removing recently, but I know it's possible.
> >>
> >> Thanks,
> >> Aaron
> >>
> >> On 3/21/06, Hiram Chirino <[EMAIL PROTECTED]> wrote:
> >>> Hi Dain,
> >>>
> >>> Is possible to dynamicaly register/unregister a GBean in the kernel?
> >>> Last time I checked, that was not really possible, but I'm hoping
> >>> things have changed since then?
> >>>
> >>> --
> >>> Regards,
> >>> Hiram
> >>>
> >>
> >
> >
> > --
> > Regards,
> > Hiram
>
>
--
Regards,
Hiram
