1 Reply Latest reply on Mar 17, 2006 12:57 PM by Scott Stark

    Potential Duplicate services defined by JBoss projects

    Anil Saldanha Master

      I have come across a situation which I will try to describe to the best of my ability.

      JBoss default installation can be configured to define Jacc DelegatingPolicy service as follows:

      <mbean code="org.jboss.security.jacc.DelegatingPolicy"
       <attribute access="read-only" getMethod="getPolicyProxy">
       <description>The java.security.Policy implementation</description>
       <attribute access="read-write" getMethod="getExternalPermissionTypes"
       <description>The types of non-javax.security.jacc permissions that
       should be validated against this policy</description>
       <!-- Not used, just here to test that custom permissions don't break the
       current behavior of javax.security.jacc.* permissions.
       <attribute name="ExternalPermissionTypes">org.jboss.security.srp.SRPPermission</attribute>

      Now this is optional for a JBoss admin.

      Now the portal project for its security, definitely needs this service defined . But the portal cannot assume the presence of Jacc configured in JBoss. To do this, it defines the Jacc delegating policy service in its service configuration (read jboss-service.xml). This will work fine as long as there is no requirement to turn on JACC in the JBoss installation.

      If the user turns ON Jacc in JBoss, when the portal sar deploys, its DelegatingPolicy service will throw a JMException ("InstanceAlreadyRegisteredException" ....).

      Is it possible to have a feature request to override a service if it is already registered in the MBeanServer. So when portal service deploys, it has its DelegatingPolicy with some attribute "replace=true". This will make its DelegatingPolicy to replace the one that has already registered with the mbean server.

      I see this can lead to issues. Your thoughts?

        • 1. Re: Potential Duplicate services defined by JBoss projects
          Scott Stark Master

          Overriding is certainly the wrong thing to do. What is needed is the notion of a default configuration if a dependency is not satisfied. This is the ${x:y} system property reference equivalent of a service dependency. The main problem with this exact form of dependency specification is lack of stability with the current jmx service object names. This could be addressed with a service name alias service we have mentioned from time to time for a long time now. Anyway, what is needed is:

           <mbean name="jboss.portal:serivce=portal-container">
           <mbean name="jboss.portal:service=JACCSecurityMgr" mode="onDmand">

          so that if there is a jboss.security:service=JACCSecurityMgr, its used, otherwise the portal local definition is used. I don't know exactly what support the mc has for this yet.