Announcement Announcement Module
Collapse
No announcement yet.
Public / Private beans Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Public / Private beans

    I know there is currently no support for declaring root beans as public or private. However, I think that kind of ability would be extremely helpful in enforcing published api's. In most cases, a module would publish a set of API classes, and then specify the contract as it relates to spring.

    ie. Bean with id "x" is an instance of the "XYZ" interface.

    However, there are many times which you need supporting beans
    in your file that should not be available outside of that particular
    file.

    Is anyone aware of any projects which are going on to supply this
    feature? Is it planned for a later version of spring?

  • #2
    I agree this would be useful.

    In addition to limiting bean visibility to a file, it would also be useful to limit it in other ways. For example, you may want your services beans used directly by an application, but not the DAOs. I guess the issue is, how does Spring know what is your application and what is infrastructure code? Maybe by specifying allowed/disallowed packages for wiring?

    However, there are many times which you need supporting beans
    in your file that should not be available outside of that particular
    file.
    If it is only used once you can use an inner bean.

    Comment


    • #3
      We used to write our own bean factory which would take in a configuration file and expose a single bean.
      So we would have a persistence.xml which returned a DAO, then in appContext we would have a bean:

      Code:
        <bean id="myDAO" class="ChildFactory">
          <property name="beanToFind" value="myDAO"/>
        </bean>
      it was a very nice way of keeping cruft encapsulated.

      Comment


      • #4
        Originally posted by katentim
        In addition to limiting bean visibility to a file, it would also be useful to limit it in other ways. For example, you may want your services beans used directly by an application, but not the DAOs. I guess the issue is, how does Spring know what is your application and what is infrastructure code? Maybe by specifying allowed/disallowed packages for wiring?
        The <beans> root element could perhaps have a 'groupid' attribute or something like that, and then a pair of 'allows'/'disallows' attributes which are basically lists of groupids. So in a typical setup, you would have something like
        Code:
        <beans groupid="web">
        </beans>
        <beans groupid="services" allows="web" disallows="dao">
        </beans>
        <beans groupid="dao" allows="services" disallows="web">
        </beans>
        <beans groupid="utils" allows="web,services,dao">
        </beans>
        Don't ask me what it means when a groupid doesn't fall into either 'allows' or 'disallows'...

        Comment


        • #5
          I guess for comparison purposes, if you looked at a Spring file as a Java package, then...

          You'd declare a bean scope as 'package' if it could only be referenced by other beans in the same file.

          Code:
          <bean id="myBean" scope="package" ...
          The default scope could be 'public', which is how Spring behaves now, i.e. can access any bean at any time.

          There wouldn't really be a need for 'private', since that would be the same as configuring an inner bean.

          Maybe the 'friend' concept could be borrowed too. Not sure if you'd need allow and disallow, maybe just assume everyone can access the public beans, unless one or more friend packages are specified?

          Code:
          <beans package="dao">
            <friends>
              <friend>businessLogic</friend>
            </friends>
          </beans>
          After having built a 220+ page Spring app with 62 Spring config files, I'd actually like to see more of a Hivemind approach added as the preferred way to build Spring apps. That is, better promote the creation of jars containing modules. I think this issue fits into this conversation.

          Comment


          • #6
            I'd actually like to see more of a Hivemind approach added as the preferred way to build Spring apps. That is, better promote the creation of jars containing modules.
            I thought this was pretty much the norm. - it's certainly essential to a good architecture, and aids in integration testing at the module level.

            Certainly there's good support for loading multiple configurations from multiple JARs. Is there something extra Hivemind offers?

            Comment


            • #7
              gmatthews,

              I like your approach concerning the scoping of beans. However, the friend concept seems to go too far.
              Anyway, would you mind to add an enhancement request in JIRA? Would be nice to have such a feature around.

              Regards,
              Andreas

              Comment


              • #8
                Is there something extra Hivemind offers?
                Don't know really. Have only briefly read the Hivemind site. I was coming from the angle that Hivemind seems to stress more that you should build reusable services from the outset, and while you *can* do this in Spring, it's not promoted that much in any examples (in my experience).

                There's probably little to gain by building Spring modules if you're building a small app, and maybe only when your app gets too big, and there is a need to slice it vertically to reduce compile times, e.g. work on a module at a time.

                the friend concept seems to go too far
                You'd need something like that if there is a requirement to define a bean in a config file, but only have it referenced by certain other defined beans. e.g. only business logic can reference dao.

                would you mind to add an enhancement request in JIRA
                I'll have to read up more on Spring 1.3, etc, and the roadmap first. The Spring guys have probably already got something like this on the way or better.

                Comment

                Working...
                X