9 Replies Latest reply on Mar 26, 2007 1:03 PM by brian.stansberry

    Depends on microcontainer bean in -service.xml

    brian.stansberry

      Is there any support for a plain "depends" in a -service.xml where the depended-on object is an MC bean? I.e.

      <depends>HAPartition</depends>


      I can get "depends optional-attribute-name" behavior with

      <attribute name="Partition"><inject bean="HAPartition" state="Installed"/></attribute>


      but there are cases where it's a simple dependency with no associated injection.

        • 1. Re: Depends on microcontainer bean in -service.xml
          starksm64

          That should just work.

          • 2. Re: Depends on microcontainer bean in -service.xml
            alesj

             

            "scott.stark@jboss.org" wrote:
            That should just work.

            Yup, it's all there:

            ServiceMetaDataParser:
            else if (element.getTagName().equals("depends"))
             {
             String mbeanRefName = element.getAttribute("optional-attribute-name");
             if ("".equals(mbeanRefName))
             mbeanRefName = null;
             else
             mbeanRefName = StringPropertyReplacer.replaceProperties(mbeanRefName);
            
             String proxyType = element.getAttribute("proxy-type");
             if ("".equals(proxyType))
             proxyType = null;
             else
             proxyType = StringPropertyReplacer.replaceProperties(proxyType);
            
             // Get the mbeanRef value
             String dependsObjectName = processDependency(mbeanName, mbeanRefName, element, services, replace);
            
             if (mbeanRefName != null)
             {
             ServiceValueMetaData value = new ServiceDependencyValueMetaData(dependsObjectName, proxyType);
             ServiceAttributeMetaData attribute = new ServiceAttributeMetaData();
             attribute.setName(mbeanRefName);
             attribute.setValue(value);
             attributes.add(attribute);
             }
             else
             {
             ServiceDependencyMetaData dependency = new ServiceDependencyMetaData();
             dependency.setIDependOn(dependsObjectName);
             dependencies.add(dependency);
             }
             }
             else if (element.getTagName().equals("depends-list"))
             {
             String dependsListName = element.getAttribute("optional-attribute-name");
             if ("".equals(dependsListName))
             dependsListName = null;
            
             NodeList dependsList = element.getChildNodes();
             ArrayList<String> dependsListNames = new ArrayList<String>();
             for (int l = 0; l < dependsList.getLength(); ++l)
             {
             if (dependsList.item(l).getNodeType() != Node.ELEMENT_NODE)
             continue;
            
             Element dependsElement = (Element) dependsList.item(l);
             if (dependsElement.getTagName().equals("depends-list-element"))
             {
             // Get the depends value
             String dependsObjectName = processDependency(mbeanName, dependsListName, dependsElement, services, replace);
             if (dependsListNames.contains(dependsObjectName) == false)
             dependsListNames.add(dependsObjectName);
            
             if (dependsListName == null)
             {
             ServiceDependencyMetaData dependency = new ServiceDependencyMetaData();
             dependency.setIDependOn(dependsObjectName);
             dependencies.add(dependency);
             }
             }
             }


            ServiceDependencyMetaData:
             public void visit(ServiceMetaDataVisitor visitor)
             {
             ServiceControllerContext context = visitor.getControllerContext();
             Object name = context.getName();
             Object other = iDependOn;
             try
             {
             other = getIDependOnObjectName().getCanonicalName();
             }
             catch (MalformedObjectNameException ignored)
             {
             }
             visitor.addDependency(new LifecycleDependencyItem(name, other, ControllerState.CREATE));
             visitor.addDependency(new LifecycleDependencyItem(name, other, ControllerState.START));
             visitor.visit(this);
             }
            


            • 3. Re: Depends on microcontainer bean in -service.xml
              brian.stansberry

              Yeah, it works fine. There was a user malfunction when I was testing it. :-(

              Sorry for the noise.

              • 4. Re: Depends on microcontainer bean in -service.xml
                brian.stansberry

                To atone, I've put up a couple more entries in http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossMicrocontainerFAQ.

                • 5. Re: Depends on microcontainer bean in -service.xml

                  We should probably change the JMX proxy MBean to go through the ServiceController
                  such that dependencies on the old JMX ObjectNames still work?

                  • 6. Re: Depends on microcontainer bean in -service.xml
                    weston.price

                     


                    We should probably change the JMX proxy MBean to go through the ServiceController
                    such that dependencies on the old JMX ObjectNames still work?


                    +1


                    • 7. Re: Depends on microcontainer bean in -service.xml
                      brian.stansberry

                      Are you saying have the proxy separately go through the ServiceController, or somehow detect the @JMX annotation on the underlying pojo and route the underlying pojo through the ServiceController?

                      • 8. Re: Depends on microcontainer bean in -service.xml

                        The pojo create/start/stop/destroy should also lead to the JMX create/start/stop/destroy
                        via ServiceController invocations.

                        • 9. Re: Depends on microcontainer bean in -service.xml
                          brian.stansberry

                          If the problem of invoking the pojo's create()/start()/stop()/destroy() twice can be avoided, doing this would be very nice.