1 2 Previous Next 15 Replies Latest reply on Sep 7, 2007 1:28 PM by bill.burke

    Deployer order solely based on inputs/outputs now?

    bill.burke

      Is deployer order solely based on inputs/outputs now? If so I believe I have a serious problem. I don't think the current approach in the EJB3 container of creating DependencyItems and RegistryPlugins is going to work. The main reason is that the @EJB annotation (and ejb-ref XML metadata) is incomplete. It does not have enough information to correctly define the dependency.

      This is why there were two deployers: EJBRegistrationDeployer and EJBStage2Deployer. Registration was supposed to work first on all deployments before Stage2. Stage2 would be able to determine the "REAL" dependencies by searching for @EJB refs (and @PersistenceUnit refs for that matter) based on:

      1. Look in the jar first for the reference
      2. Look in the EAR
      3. Look globally

      EE6 will complicate things further as EJB jars will be deployable within WARs.

      Do you see the problem I'm getting at? Since @EJB is incomplete, it could be possible for it to resolve to something it is not supposed to. Some links to WIKI or forum posts would be helpful. (and no adrian, google doesn't always work as you have to know what to search for).

      thanks

        • 1. Re: Deployer order solely based on inputs/outputs now?
          bill.burke

          Ok, after talking to Ales I think i get it.

          There would be:

          EJBParserDeployer
          EJBDescribeDeployer
          EJBComponentDeployer

          So, if my EJBDescribeDeployer is part of the DESCRIBE stage, it should happen after EVERY DeploymentUnit has gone through Parsing, right?

          • 2. Re: Deployer order solely based on inputs/outputs now?
            bill.burke

            The only thing about this is that there would need to be a

            JavaEEDescribeDeployer that would need to work with EJBs, Servlets and any other EE component that uses EE XML/annotation component references.

            • 3. Re: Deployer order solely based on inputs/outputs now?
              wolfc

              Yes, and I want each deployer to use a clean SPI. So no use of InjectionContainer which is too bloated. But one created in projects/integration based on the org.jboss.ejb3.javaee interfaces.

              After the describe phase each JavaEEComponent should be able to answer the questions in the interface.

              (I don't like the createObjectName methods. Maybe getComponent(name) on JavaEEModule level and getModule(name) on JavaEEApplication. If we add generics we could even specify what kind of components are in the module. Hmm EE 6 clash, getComponent(name, type).)

              • 4. Re: Deployer order solely based on inputs/outputs now?
                wolfc
                • 5. Re: Deployer order solely based on inputs/outputs now?

                   

                  "bill.burke@jboss.com" wrote:
                  Ok, after talking to Ales I think i get it.

                  There would be:

                  EJBParserDeployer
                  EJBDescribeDeployer
                  EJBComponentDeployer

                  So, if my EJBDescribeDeployer is part of the DESCRIBE stage, it should happen after EVERY DeploymentUnit has gone through Parsing, right?


                  This can only work if you add the dependencies to the deployment rather than
                  the ejb instance. The same way OSGi dependencies work.

                  It has to be real dependencies, no "flow" or ordering of deployers is going to
                  solve the problem where deployments are deployed piecemeal, i.e. not at
                  the same time, or even worse (more complicated)

                  * redeployed
                  * one of the transient dependencies is missing and deployed later

                  The real solution is to create your own DependencyItem implementation
                  like I've been telling you to over a year now.

                  The JNDI plugin to the MC registry is stupidly inefficient, it's ok as an
                  early hack to try out the idea.

                  A DependencyItem that does the same thing, but only for those you expect to
                  be JNDI dependencies is much more efficient.

                  • 6. Re: Deployer order solely based on inputs/outputs now?
                    bill.burke

                     

                    he real solution is to create your own DependencyItem implementation
                    like I've been telling you to over a year now.


                    And I've been telling you that EE injection requirements are not simple...

                    Are you sure the DependencyItem stuff will work since EJB and PC ref's metadata may be incomplete or even ambiguous? Does a DependencyItem get queried EVERY TIME any arbitrary thing is deployed or when ANY arbitrary thing changes state within the MC? I also worry about a dependency item matching and picking up the wrong reference because an inner deployment scope hasn't been processed/deployed yet.

                    I don't understand why I have to add the dependencies to the deployment to make this work. The subdeployments of an EAR are not going to be deployed piecemeal.

                    Also, we're not going to make configuration more complicated for the user for the edge cases 90% of people don't care about. Meaning, we're not going to require a mapped-name with @EJB or @PersistenceContext refs. i.e. requiring them to specify a mapped-name.

                    Where is there documentation on how dependency items work? The Javadoc isn't very helpful ;-)

                    • 7. Re: Deployer order solely based on inputs/outputs now?

                       

                      "bill.burke@jboss.com" wrote:
                      he real solution is to create your own DependencyItem implementation
                      like I've been telling you to over a year now.


                      And I've been telling you that EE injection requirements are not simple...


                      I know.


                      Are you sure the DependencyItem stuff will work since EJB and PC ref's metadata may be incomplete or even ambiguous? Does a DependencyItem get queried EVERY TIME any arbitrary thing is deployed or when ANY arbitrary thing changes state within the MC? I also worry about a dependency item matching and picking up the wrong reference because an inner deployment scope hasn't been processed/deployed yet.


                      You can make a DependencyItem do whatever you like, e.g. just delegate
                      to the EJBContainer to do all the work.


                      I don't understand why I have to add the dependencies to the deployment to make this work. The subdeployments of an EAR are not going to be deployed piecemeal.


                      EAR subdeployments are always going to piecemeal unless you make
                      them wait for their dependencies.
                      If its non-deterministic then nothing is going to work, its just random.


                      Also, we're not going to make configuration more complicated for the user for the edge cases 90% of people don't care about. Meaning, we're not going to require a mapped-name with @EJB or @PersistenceContext refs. i.e. requiring them to specify a mapped-name.


                      I'm not saying you should. I'm saying you create a dependency that is relevant
                      to what the user requests. If they say mapped-name then that is more specific
                      and should respected over whatever heuristic rules you use otherwise.


                      Where is there documentation on how dependency items work? The Javadoc isn't very helpful ;-)


                      Not done, yet...
                      http://jira.jboss.com/jira/browse/JBMICROCONT-81
                      Ales has been concentrating on what most people will actually use
                      in the documentation.

                      There's many examples though, e.g. the deployment dependencies
                      I added for OSGi a few weeks ago:

                      http://viewvc.jboss.org/cgi-bin/viewvc.cgi/jbossas?view=rev&revision=64469

                      Mapping of OSGi requirement to MC dependency (currently only modules and packages
                      are implemented as requirements)
                      http://viewvc.jboss.org/cgi-bin/viewvc.cgi/jbossas/projects/microcontainer/trunk/deployers-impl/src/main/org/jboss/deployers/plugins/classloading/RequirementDependencyItem.java?view=markup&pathrev=64469

                      • 8. Re: Deployer order solely based on inputs/outputs now?
                        bill.burke

                         

                        EAR subdeployments are always going to piecemeal unless you make
                        them wait for their dependencies.
                        If its non-deterministic then nothing is going to work, its just random.


                        1. Parsing deployer runs generating metadata for each EJB in the EAR
                        2. Describe deployer runs adding dependency metadata for each EJB
                        3. Component deployer runs, creating EJB beans with "real" kernel dependencies based on metadata in step #2.

                        Again, this would be for @EJB and @PC refs that do not have a mapped-name defined. Metadata refs with mapped-name specified don't have the ambiguity that @EJB and @PC might have that don't have mapped-name defined.

                        FYI, my question on DependencyItem is simple. When does it get invoked upon. What triggers it. If i know this information, then I can proceed.

                        • 9. Re: Deployer order solely based on inputs/outputs now?
                          alesj

                           

                          "bill.burke@jboss.com" wrote:
                          What triggers it. If i know this information, then I can proceed.


                          Any addition (e.g. new install) to Controller triggers this:
                          
                           Set<ControllerContext> unresolved = contextsByState.get(fromState);
                           Set<ControllerContext> resolved = resolveContexts(unresolved, toState, trace);
                          
                           protected Set<ControllerContext> resolveContexts(Set<ControllerContext> contexts, ControllerState state, boolean trace)
                           {
                           HashSet<ControllerContext> result = new HashSet<ControllerContext>();
                          
                           if (contexts.isEmpty() == false)
                           {
                           for (ControllerContext ctx : contexts)
                           {
                           if (advance(ctx))
                           {
                           DependencyInfo dependencies = ctx.getDependencyInfo();
                           if (dependencies.resolveDependencies(this, state))
                           result.add(ctx);
                           }
                           }
                           }
                          
                           return result;
                           }
                          


                          • 10. Re: Deployer order solely based on inputs/outputs now?
                            alesj

                            Plus this:

                             public boolean resolveDependencies(Controller controller, ControllerState state)
                             {
                             boolean resolved = true;
                             if (unresolved.isEmpty() == false)
                             {
                             for (DependencyItem item : unresolved)
                             {
                             if (state.equals(item.getWhenRequired()) && item.resolve(controller) == false)
                             {
                             resolved = false;
                             break;
                             }
                             }
                             }
                             return resolved;
                             }
                            


                            btw: you can always check the code for more details ;-)

                            • 11. Re: Deployer order solely based on inputs/outputs now?

                               

                              "bill.burke@jboss.com" wrote:

                              FYI, my question on DependencyItem is simple. When does it get invoked upon. What triggers it. If i know this information, then I can proceed.


                              I'll answer your question with some psuedo code that describes the MC algorithm :-)

                              whenSomebodyInstallsANewContext()
                              {
                               registerItInNotInstalledState();
                              
                               // Go through all the states from NOT_INSTALLED TO INSTALLED
                              
                               for (ControllerState state : allStates)
                               {
                              
                               // Go through all the contexts at the current state
                              
                               List<ControllerContext> contexts : getContextsInState(state);
                               for (ControllerContext context : contexts)
                               {
                               List<DependencyItem> items = context.getDependencyInfo().getDependencies(context.getNextState());
                              
                               // See whether the depenencies are resolved
                              
                               boolean readyToGoToNextState = true;
                               for (DependencyItem item : items)
                               {
                               if (item.resolve() == false)
                               readyToGoToNextState = false;
                               }
                              
                               // If they are bump it to the next state
                              
                               if (readyToGoToNextState())
                               doIt();
                               }
                               }
                              }
                              


                              Of course the real implementation is more complicated because of ControllerMode, multithreading, recursion and error handling, but that algorthim is effectively all the MC does.

                              So you can see it will check dependency items for every context that is not in a
                              fully installed state when somebodyinstalls a new context.
                              But only those dependency items that lead to the next state.

                              • 12. Re: Deployer order solely based on inputs/outputs now?

                                 

                                "adrian@jboss.org" wrote:
                                "bill.burke@jboss.com" wrote:
                                Ok, after talking to Ales I think i get it.

                                There would be:

                                EJBParserDeployer
                                EJBDescribeDeployer
                                EJBComponentDeployer

                                So, if my EJBDescribeDeployer is part of the DESCRIBE stage, it should happen after EVERY DeploymentUnit has gone through Parsing, right?


                                This can only work if you add the dependencies to the deployment rather than
                                the ejb instance. The same way OSGi dependencies work.


                                I should also point out that with the latest rev of the deployers, the deployment
                                dependencies are implemented on the whole deployment.

                                i.e. adding a dependency on an ejb subdeployment of ear will actually be
                                a dependency for the whole ear.

                                So if the describe deployer adds a dependency saying don't move to the "REAL"
                                stage until java:/DefaultDS is deployed, nothing in the EAR will move to "REAL"
                                until that is done.

                                In that sense, it can't be piecemeal if you have real dependencies on the deployments.

                                • 13. Re: Deployer order solely based on inputs/outputs now?
                                  bill.burke

                                  You're talking about DeploymentUnit dependencies, not components, right? So, if I create dependencies on the EJB container itself, rather than the deployment I'll be ok.

                                  • 14. Re: Deployer order solely based on inputs/outputs now?
                                    bill.burke

                                    Having dependencies on the deployment instead of the actual EJB container makes no sense to me whatsoever, especially considering the lack of metadata needed to concretely resolve certain dependencies (@EJB).

                                    So maybe 4 deployers:

                                    1. Parse and create metadata (PARSE)
                                    2. Process anonotations (POST_CLASSLOADER)
                                    3. Instantiate EJB containers and register them. (POST_CLASSLOADER stage, ordered after annotation processor).
                                    4. Real deployer, process references, create dependency items, install EJB containers with these dependency items.

                                    If an EJB container has an @EJB/@PC dependency, it wouldn't be affected by an arbitrary stop/redeploy because it would already know the concrete kernel names it depended on. Unless of course the user changed the referenced EJB or PC's name, but we don't have to handle that situation.

                                    For the piecemeal scenario (at least my definitino of piecemeal), we *cannot* support the scenario of somebody deploying something first, then deploying something that it depends on 1 hour later and expecting the dependency to be resolved unless the user has defined adequate metadata to resolve the dependency (i.e. @EJB with only interface as identifying metadata will not work).

                                    1 2 Previous Next