3 Replies Latest reply on Aug 22, 2005 11:13 AM by Adrian Brock

    On-Demand Deployment of EJBs

    Klaus Richarz Newbie

      I have the need to deploy EJBs (Session+Entity only) in a JBoss 4.x Kernel only on demand. This is because of a customer who wants to use JBoss, but who's not satisfied with the initial startup time. Most of the startup (about 80%) is done at EJB deployment (building CMP Metadata etc, Registering at JNDI etc pp).

      From Bill I know that there will be a notion of "On Demand" but not the 4.x series.

      My suggestion would be to write ...
      1. a new customized EJBDeployer:
      - instantiate EjbModule
      - set EjbModule state to something like ON_HOLD (maybe append DeploymentInfo)
      - Notifiy about state change
      - NOT create or START EjbModules that have state ON_HOLD
      2. a new EjbOnDemandService:
      - intercept notification ON_HOLD
      - register EjbModule as an OnDemand EjbModule
      - provide an interface to finish deploy a registered EjbModule (create+start)
      3. a new customized NamingServer:
      - if a lookup fails, ask EjbOnDemandService if any EJB matches the JNDI name and deploy the corresonsing EjbModule using the EjbOnDemandService and retry lookup
      Alternative for changing the NamingServer: maybe we can provide a JNDI reference for every EJB (bound in EjbOnDemandService) and deploy the 'real' EJB to another NamingContext? If the reference is accessed the first time, the reference would invoke the deploy on the EjbOnDemandService...

      All those new services would be optional packages that could be used instead of the original services.

      Another option would be to include this feature into the existing Services and provide configuration options to enable/disable. What would you suggest?

      The above approach does only work for Session- and Entitybeans. MDBs are working differently, the event would not be a JNDI lookup but am incoming message. Do you have an ideas?

      Is this a feature that is interesting for the 4.x series? Or should I build a solution solely for the use of my customer?

        • 1. Re: On-Demand Deployment of EJBs
          Adrian Brock Master

          That isn't the way we are going to do it in JBoss5.

          1) On demand is a "service" thing. i.e. you describe the service but don't
          create it/start it. Otherwise, how do you know what jndi bindings or queues,
          serversockets, etc. are the entry points.

          2) Belongs in the ServiceController/DependencyController

          3) The correct way to do this is to use a placeholder.
          You bind some simple code (e.g. jndi objectfactory) at the entry point of the "service"
          then if it is "OnDemand" and not started, you hold the request while you start the service
          through the ServiceController.

          I'm not interested in doing this in JBoss4 until it has been properly tested
          in JBoss5. Especially since JBoss4 has no notion of exposing "entry points"
          through metadata to the service controller.
          And hacking it into the *implementation* rather than making it a generalized notion
          for all services to use, is the wrong way to go.

          • 2. Re: On-Demand Deployment of EJBs
            Klaus Richarz Newbie

            I will have a look at the JBoss5 code and make a custom patch for my customer.

            Are there any plans to include this feature into JBoss4.x after it has been testet in JBoss5?

            • 3. Re: On-Demand Deployment of EJBs
              Adrian Brock Master


              "klaus.richarz@hbt.de" wrote:

              Are there any plans to include this feature into JBoss4.x after it has been testet in JBoss5?

              Much I was like to answer this question over and over again...

              Looking at Roadmaps is the very first link on the WIKI:
              If you don't find what you need, you can always raise a feature request.

              Tell me what we can do to make this information more prominent
              so we don't have to read/answer this question at 40,000 Hz. :-)