4 Replies Latest reply on Jan 31, 2007 2:21 PM by Adrian Brock

    Class dependencies

    Bill Burke Master

      Yet another thing from Seam.

      Seam components can state that if a certain class is not in the classpath, then don't deploy them. Sound like an interesting feature?

      <bean name="foo" class="org.drools.Shit" load-if-class-not-available="false"/>
      


      I think this is another example of the "ON DEMAND" mode except that the user turns off the bean by removing "drools" from the classpath.

        • 1. Re: Class dependencies
          Scott Stark Master

          Somewhat, but then how is this reflected in the profile and exposed via management interfaces? Its hard to deal with something that does not exist. There would have to be some unresolved bean notion that does not fail a deployment when its validated.

          • 2. Re: Class dependencies
            Adrian Brock Master

            This has the same problem as the precedence.

            When do you check that the class is available?

            Under hotdeployment, the class could be added later and even removed and
            redeployed.

            When classloading dependencies are implemented (needs integration
            between the classloader and the kernel - see other discussions)
            a better feature might be to say:

            <bean ... class="org.drools.Shit" optional="true"/>
            


            So if the class doesn't exist we don't report it as a missing dependency.
            We just don't start the bean until somebody deploys the class.

            This would also extend to other dependencies, not just classes.

            • 3. Re: Class dependencies
              Bill Burke Master

              don't you have the same issue with "On Demand" stuff?

              • 4. Re: Class dependencies
                Adrian Brock Master

                No because "On Demand" doesn't "On Undemand". :-)

                If somebody references the bean we deploy it, but we don't undeploy it
                when it is de-referenced.

                That is mainly because it would wasted effort if the referencer is just redeloying.

                For class dependencies the issue is different. You have to redeploy if the class changes
                or undeploy if the class is removed.

                It's not difficult, the semantics are just a bit more exacting.