1 2 Previous Next 17 Replies Latest reply on Jan 23, 2007 4:01 PM by starksm64 Go to original post
      • 15. Re: DataSource/ServiceXSLDeployer processing issue
        starksm64

         

        "bill.burke@jboss.com" wrote:

        The EJB Deployer can do what it already does: instantiate the container itself and install them manually into the kernel. No need for special MC states.

        Then your back to the old monolithic model of mixing describing how to do something with doing it. This will complicate interaction with generalized notions like admin ops affecting all transport interfaces, clustering behaviors, as well as resue of code across server versions.


        • 16. Re: DataSource/ServiceXSLDeployer processing issue
          starksm64

           

          "adrian@jboss.org" wrote:
          DEPLOYMENT PROTOCOL

          This is something that is not a part of the original prototype but it is a part of the
          original design.

          The basic idea is that the deployers can be run in two modes.
          1) Runtime - this is what is implemented, it is the full deployment
          2) Profile Service - in this case, the "real deployers" create contexts that have
          stubbed out actions for the MC and JMX layers.

          That is when it runs in Profile Service mode, it still goes through the full
          deployment process, creates all the contexts and tries to resolve dependencies,
          but it doesn't create any objects or invoke any setters or lifecycle methods.

          NOTE: This is only for the deployments. It does need to do the full work
          for the deployers and classloaders otherwise they wouldn't be able to do anything. :-)

          Then the real deployers simply need to select the approriate contexts based on a DeploymentMode(Runtime,Validation) type of attachment. This of course precludes non-real deployers from directly interacting with any kernels.



          • 17. Re: DataSource/ServiceXSLDeployer processing issue
            starksm64

             

            "adrian@jboss.org" wrote:

            ...
            There are complications like the XSL deployer which needs to be changed
            so you can pass in some form of DOM representation as the predetermined
            attachment and still do the XSL transform on it, but this is an exceptional case
            caused by badly written deployers that don't have a proper metadata model.


            This is a deficiency of the base JAXPDeployer though. If it supported a dom document attachment rather than always parsing a virtual file this would just work. I created the following feature request for that:
            http://jira.jboss.com/jira/browse/JBMICROCONT-144

            I would assume its easier to add this than update the datasource deployer.


            1 2 Previous Next