Announcement Announcement Module
No announcement yet.
Namespaces for Spring Beans Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • Namespaces for Spring Beans

    Hi all,

    I have following problem: In our Spring-project we have several sub-projects where each sub-project has its own spring-config.xml file. So each sub-project defines its own beans but the beans can be accessed from other projects since all spring-config.xml files are loaded into the same spring application context.

    To guarantee unique bean-id's across all sub-projects we've defined prefixes for each project. For example sub-project a got prefix "a", project b got prefix "b" and so forth.

    By convention every developer uses the prefix when defining beans. E.g. a bean in project a would get the id "a.mybean".

    My question is: Is this a "good" approach or does the spring framework provide some advances functionalities to solve the described problem. I am thinking of something like namespaces, so that each spring-config.xml file would become its own namespace and we could reference beans by something like "mynamespace.mybean".

    Thanks in advance!


  • #2
    Well, basically it is more of a convention to help and not cause conflict.

    The main bean naming convention is that the name of the bean should be the name of the interface that that class implements. So I have a OrderService interface and an OrderServiceImpl class to be a bean. The bean name for that bean will be "orderService"

    So where this fails to work in say your situation, is if two teams have implementations of OrderService, or each team has their own OrderService interface in different packages. But typically, one team is on the service layer, one team the DAO/Repository layer and rarely intersect like above.

    Does "." work in the attribute "id", I thought id couldn't have special characters? But you can use the "name" attribute instead.

    This does get to be an issue if you have lots of beans, which is one of the reasons why I do prefer annotations.

    I wouldn't say what you are doing is a bad approach, just a odd taste in my mouth, that I think communications between teams would fix.

    Hope that helps.