7 Replies Latest reply on Jun 29, 2005 12:29 PM by Adrian Brock

    SubDeployer interceptors in 4.x/HEAD

    Dimitris Andreadis Master

      So the ability to dynamically attach jmx interceptors to any XBeans in general, and a set of SubDeployers in particular, exists both in 4.x.(3) and HEAD.

      The EJB, EJB3, and Web Deployes can be currently intercepted, (i.e. they've been XMBea-nized, with the DynamicInterceptor attached) but we may do the same for any subdeployer.

      Note, this is standard xmbean stuff, it's not related to jboss aop.

      This feature is already used in HEAD for the new WebService subdeployers, that can attach dynamically, do their own thing and fail a deployment if something goes wrong with the webservices part of the deployment.

      There is also an older prototyped LoginConfigInterceptor that detects the presence of a META-IN/login-config.xml and creates/destroys a security domain upon deployment, undeployment (although this needs work when dealing with multiple/nested login-config.xml descriptors>)

      Except for WebServices, this feature should be useful to the JBoss Portal deployer. We could also try to process custom log4j.xml descriptors?

      You can read about it here:

      http://wiki.jboss.org/wiki/Wiki.jsp?page=SubDeployerInterceptorSupport
      http://wiki.jboss.org/wiki/Wiki.jsp?page=InterceptorServiceMBeanSupport
      http://wiki.jboss.org/wiki/Wiki.jsp?page=DynamicInterceptor

      A related forum posting is this:
      http://www.jboss.org/index.html?module=bb&op=viewtopic&t=57296&postdays=0&postorder=asc&start=0

        • 1. Re: SubDeployer interceptors in 4.x/HEAD
          Adrian Brock Master

          My objections to this still stand to this.
          This is not something I want to support going forward in this format.

          1) How does it cope with class redeployment of the interceptor, who holds the state?

          2) The lifecycle is wrong since the interceptor waits for the service,
          thus potentially missing some deployments:

          <depends-list optional-attribute-name="Interceptables">
           <depends-list-element>jboss.ejb:service=EJBDeployer</depends-list-element>
           <depends-list-element>jboss.ejb3:service=EJB3Deployer</depends-list-element>
           <depends-list-element>jboss.web:service=WebServer</depends-list-element>
          </depends-list>
          


          3) When it is late bound how does it intercept previous deployments?

          4) When the interceptor is unbound does it "unintercept"

          5) How does this play with the already overly compliated (and broken)
          deployer/subdeployment lifecycle.

          • 2. Re: SubDeployer interceptors in 4.x/HEAD
            Adrian Brock Master

            Rhetorical question.

            Also, can we stop dumping everything in org.jboss.system/deployment?

            System is for the core kernel, not for every possible helper class that uses
            system and deployment. The helper classes should be written to the system api
            not digging around in implementation details.

            I know we don't have a project that for helpers except varia which is just another
            form of dumping ground.

            This whole dependency on implementation thing is getting way out of hand.
            It is going to be impossible to change a single line of code soon without breaking
            backwards compatibility.

            • 3. Re: SubDeployer interceptors in 4.x/HEAD
              Scott Stark Master

              So let's move the non-core stuff to the deployment module that contains the jsr-88 implementation?

              As for not supporting this in the future, what is the main problem, not being able to adapt this behavior to the jb5 kernel? I understand and agree with the numerous problematic issues you raised in your objections.

              We need to add interceptors on the deployers as a first class notion, not through xmbean tricks.

              • 4. Re: SubDeployer interceptors in 4.x/HEAD
                Dimitris Andreadis Master

                This is just a short term solution to be able to fail a deployment directly, somewhat better from what we do now with jmx notifications. It carries the same set of problems, and it only works if the interceptor is closely deployed with the target deployer(s).

                It can be somewhat improved by not having a dependency and start dealing with registration notifications, but that's just as far you can get.

                The "interceptors" really need to register with the MainDeployer, because this is the only way to be informed of past deployments, and get the lifecycle right. This is in Adrian's deployer design, anyway.

                We also need to clarify what makes the org.jboss.system/deployment APIs that we want to support.

                • 5. Re: SubDeployer interceptors in 4.x/HEAD
                  Adrian Brock Master

                   

                  "scott.stark@jboss.org" wrote:
                  So let's move the non-core stuff to the deployment module that contains the jsr-88 implementation?


                  OK


                  As for not supporting this in the future, what is the main problem, not being able to adapt this behavior to the jb5 kernel?


                  1) It would require yet another compatibility layer to invoke user written XMBean deployment interceptors from the aspectized deployers.

                  2) The purpose of the aspectized deployers is to work on the metadata model of the
                  deployment.
                  deployment aspects -> metadata -> kernel -> objects
                  This XMBean interception approach is just a form of scripting
                  deployment -> interceptor -> anything at all
                  with the kernel having no understanding of how the "anything at all" fits into
                  the system for dependencies/classloading/lifecycle/mangement/etc.
                  let alone trying to describe the possible deployment configuration to tools.

                  • 6. Re: SubDeployer interceptors in 4.x/HEAD
                    Adrian Brock Master

                     

                    "adrian@jboss.org" wrote:

                    deployment aspects -> metadata -> kernel -> objects
                    ...
                    let alone trying to describe the possible deployment configuration to tools.


                    In the more complicated tool workflow:

                    raw deployment -> deployment aspects -> metadata ->
                    user review/change -> metadata -> versioned config -> kernel -> objects

                    • 7. Re: SubDeployer interceptors in 4.x/HEAD
                      Adrian Brock Master

                       

                      "dimitris@jboss.org" wrote:
                      This is just a short term solution to be able to fail a deployment directly, somewhat better from what we do now with jmx notifications. It carries the same set of problems, and it only works if the interceptor is closely deployed with the target deployer(s).


                      Yes, it is a mechanism that helps in the decoupling of the aspects of deployment
                      e.g. creating webservice endpoints
                      but my main problem with it that it does nothing to expose what is happening
                      to the deployment.
                      At least in the "monolithic" SubDeployer architecture there is some attempt
                      to collect the deployment description in DeploymentInfo.


                      We also need to clarify what makes the org.jboss.system/deployment APIs that we want to support.


                      Scott already raised the issue of each project describing what is its "public api"
                      supported across versions, as oppossed to implementation details or internal
                      integration routines that happen to be public classes.