Announcement Announcement Module
Collapse
No announcement yet.
ApplicationContexts and Subsystems in Large App Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • ApplicationContexts and Subsystems in Large App

    Not sure if question in right forum (maybe in Architecture?). Anyway, apologizing in advance if wrong.

    I'm making large app with several subsystem like client, contracts, billing, etc. How should I divide in terms of ApplicationContexts? Should I have one ApplicationContext with one context config file per subsystem? Or should I have one ApplicationContext per subsystem? If one per subsystem, should I also have one "main" parent ApplicationContext that contains subsystem ApplicationContexts? I mean, how you decide for big app...Spring sample apps seems to small to give guide here. Advice is appreciating.

  • #2
    Are all these subsystems in the same CVS/IDE project? If not, are you using Maven or similar to manage dependencies? Do they have different development cycles? Will they be deployed in a single WAR, or some other way?

    The answers to these sort of questions decide how to go about it. There is an OSS project known as ONESS which shows how to structure multiple subsystem together via Maven and using Spring. Each subsystem has its own WAR, own IDE project, own build aritfacts etc. A good source of ideas if you are building a very big application.

    If its simpler than that, say a single WAR, CVS and IDE project, just use separate packages for each "subsystem" with each subsystem or package having its own applicationContext-subsystemName.xml file. It really depends on how many beans you've got as to what is practical. We tend to use one per subsystem, even though a subsystem has several packages (usually a dao + domain package at least). Then declare all of them together in web.xml:

    Code:
    	<context-param>
    		<param-name>contextConfigLocation</param-name>
    		<param-value>
    			classpath&#58;applicationContext-common.xml 
    			classpath&#58;applicationContext-security.xml 
    			classpath&#58;applicationContext-services.xml
    			classpath&#58;applicationContext-common-dataSource-dbcp.xml 
    			classpath&#58;applicationContext-sitemesh.xml 
    			classpath&#58;applicationContext-common-party.xml 
    			classpath&#58;applicationContext-common-counter.xml 
    			classpath&#58;applicationContext-common-contact.xml 
    			classpath&#58;applicationContext-common-auth.xml 
    			classpath&#58;applicationContext-content-dns.xml 
    			classpath&#58;applicationContext-content-vfs.xml
    		</param-value>
    	</context-param>
    Hope this helps, but if not, please give some more info as to your requirements and I'm sure people will be happy to make suggestions.

    Comment


    • #3
      Originally posted by Ben Alex
      Are all these subsystems in the same CVS/IDE project?
      Yes.
      Originally posted by Ben Alex
      Do they have different development cycles?
      I assuming you mean "are they be developed all at same time"? No, not really. The subsystems really represent logical division of app. How we do it is some guys work on a subsystem's DAO and domain layers while some other guys work on a subsystem's UI layer. Then, as needed, we starting working on related subsystem with same DAO-domain/ui split. Don't know if this is good approach but it's how we doing it currently and is working good for us.
      Originally posted by Ben Alex
      Will they be deployed in a single WAR, or some other way?
      No WAR. This is standalone Swing app (starting to add in Spring Rich Client features now). Actually is sort of like specialized ERP system. We will deploy probly as single jar, at least for now.
      Originally posted by Ben Alex
      If its simpler than that, say a single WAR, CVS and IDE project, just use separate packages for each "subsystem" with each subsystem or package having its own applicationContext-subsystemName.xml file. It really depends on how many beans you've got as to what is practical. We tend to use one per subsystem, even though a subsystem has several packages (usually a dao + domain package at least). Then declare all of them together in web.xml:
      Code:
      	<context-param>
      		<param-name>contextConfigLocation</param-name>
      		<param-value>
      			classpath&#58;applicationContext-common.xml 
      			classpath&#58;applicationContext-security.xml 
      			classpath&#58;applicationContext-services.xml
      			classpath&#58;applicationContext-common-dataSource-dbcp.xml 
      			classpath&#58;applicationContext-sitemesh.xml 
      			classpath&#58;applicationContext-common-party.xml 
      			classpath&#58;applicationContext-common-counter.xml 
      			classpath&#58;applicationContext-common-contact.xml 
      			classpath&#58;applicationContext-common-auth.xml 
      			classpath&#58;applicationContext-content-dns.xml 
      			classpath&#58;applicationContext-content-vfs.xml
      		</param-value>
      	</context-param>
      Okay so looking like one xml file per subsystem. But how many ApplicationContext? I mean, should I be loading all xml files into one ApplicationContext? Or should I have one ApplicationContext per xml file? If one per, should I have main parent ApplicationContext as well?

      Thanking you for this.

      Comment


      • #4
        Alex,

        Thinking more. Lets say one developer implement domain layer and DAO layer and a different developer implements UI layer. Thinking maybe split subsystem xml file into two files. Example, for billing subsystem, maybe this:

        applicationContext-billing-business.xml
        applicationContext-billing-ui.xml (with Spring Rich Client, view beans go here)

        What you thinking about this one? Maybe also someone can say something?

        Comment


        • #5
          I'm going to be controversial about this...

          We are using spring and our system is getting very large.

          The business-layer, and the dao are simple enough that it is not problematic to wire since we use class names as a means to hook up everthing and 9 times out of 10 we don't screw this up.

          However, our UI layer is a complete mess. It is just like struts but not typed. Maintaining it is a real nightmare and frankly spring is not helping since the definitions are way too general and can't validate the content (i.e. the property values). It is too easy to screw up and very difficult to unit test. Even if you break down the files it doesn't help. We've decided to programatically wire the UI with the business logic layer. It is going to be typed, we can use the IDE to follow relationship and will be much more maintainable.

          We can do this since it is not our requirement to change the xml dynamically. I've used struts for over 3 years and I have NEVER modified the strut-config.xml on production.

          This is where the pico container is better. I thought it was very inflexible to programatically wire elements together. However, our team have been using spring for the last 5 months and 90% of our problems is related to xml configuration. The framework itself is very very cool.

          Dino

          Comment


          • #6
            Re: I'm going to be controversial about this...

            Originally posted by hucmuc
            We've decided to programatically wire the UI with the business logic layer.
            Are you doing only the wiring of UI beans programatically or are you also doing the instantiation programatically? What I mean, are you still defining your UI beans in a context config file and letting the container instantiate them, then after instantiate, you programatically injecting dependencies? Or are you programmatically instantiating and dependency injecting your UI beans?

            Maybe, please show example of how you doing this?

            Thank you for this one.

            Comment


            • #7
              We are partially using the spring MVC framework (i.e. controller, model view) in conjuction with our UI framework so giving you an example would be misleading. Currently, we are using the xml for the business/facade and for the entry point into the UI framework. We are still in the process of cleaning this up since we've recently ditched the xml approach.

              Dino

              Comment

              Working...
              X