Announcement Announcement Module
No announcement yet.
Initializing spring context from another app Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • Initializing spring context from another app

    I am developing an api that is wired together by spring. This api will be used in other applications. My question is what is the best way to initialize the spring context files in the api? Is there a way to do this without having to require the client application to use spring?

    So for example: lets say you have a service, MyService, which has dependencies that are managed by spring. I want the users of my api to be able to use MyService, but it needs to be injected with its dependencies first.

    A couple of way I have thought of are:

    1. Wrap the service in some sort of delegate that in its constructor loads the application context and gets the MyService bean and then proxies all calls to MyService.

    2. Create a factory that returns the MyService bean after loading the application context and calling getBean.

    Are there better ways to do this?

    Thanks for any help.


  • #2
    One Possible Solution

    Within MyService you can grab a handle to Spring's Context and from that you can get to all the bean definitions you would need:

    Here is an example, say you had a bean called "DataSource" which allows you to do JDBC calls to a database then the following code will allow you to get a handle to that bean defined in your Spring XML files.

    ApplicationContext ctx = ApplicationContextHolder.getContext();
    datasource= (DataSource) ctx.getBean("datasource");

    I hope this answers your question.

    Good Luck.

    Venkatt Guhesan


    • #3
      Yes but the question clearly stated: "Is there a way to do this without having to require the client application to use spring?"


      • #4
        I vote the factory route. Basically you want to encapsulate (hide) Spring initialization behind a library. That way if you choose to implement with some other container (Guice, Hivemind, OSGi, homegrown, etc) you can and your API is none the wiser.

        How exactly you do it depends on how configurable your API is. You can hard code as much or as little as you want. From just specifying the "API_HOME" to point to the base libraries to creating a complex Java property file which points to all sorts of settings that your API library can utilize using PropertyPlaceHolderConfigurers.


        • #5
          I agree that I think the factory is the more elegant solution - but I am wondering if using Spring is even appropriate in this case. Are there any examples of api libraries that anyone is aware of that are built using Spring? I guess more specifically is dependency injection appropriate to use when writing an api?


          • #6
            I think it certainly can be useful. DI is a pattern related to creating and initializing objects, something an API certainly has to do. DI is not magic, is should be used if you its appropriate, and shouldn't if its not. In addition in helping you reuse objects, it can help you break down complicated components into simpler ones and then wired together. It can also provide you with easy access to other Java services: JMX, JDBC, Transactions, security and help you address cross cutting concerns more easily with AOP.

            Personally I think the best way to use Spring is to think about your application without Spring. Design your API with whatever patterns you think is appropriate for you situation. You should quickly see if Spring is going to help you or not.