Announcement Announcement Module
No announcement yet.
Best pratice for using spring in jars? Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • Best pratice for using spring in jars?

    Hi all,

    I have several questions about using spring in jar components. We are experiencing some issues and we are not sure if its sping or something else. So here goes

    1)We seem to have a problem in that the developers of the components jars also use applicationContext.xml as their config file name. I think this results in "namespace" conflicts with other jars which use the same name since suddenly the jars class don't work even though unit test on the stand-alone jar are fine.

    2)It appears as if beans defined in jar application context they are not visable to the inluding package which makes sense since its a different context. Is there a way to access these bean?

    3) We don't want to force the users of the libraries to use spring too but there does not appear to be a neat way to get the jar to load the application contexts on "start up". We have tried loading the context in the objects constructors but this messes with using these classes in spring contexts. Also we have to load the config files in every class's constructor as we are not sure which class will be used first.

    4) Also we want to hide implementation details from users of the libraries. So eg if they use a jar containing data access objects we don't want the client to have to pass in a session object. The client should just use the services of the jar by using getBean or by using new operator. eg bean= (EmployeeService)getBean(employeeService); bean.getEmloyee(555900); The application context should just look like <bean id="empoyeeService" class="" /> or EmployeeService = new EmployeeService();

    To give more info here is what we do. We distribute a client jar which contains all the domain, data access and service objects. Applications make use of the client jar by calling methods to retrieve and save objects. The database details may be changed via a properties file but we dont what application designer to have to configure sessions/connections and pass them through to the jars. We use spring for wiring together the services and daos.


  • #2
    1. Maybe you can put the jar's app context file in the jars unique classpath location. So, if your jar's main class is a.b.c then you would put the context definitions at a/b/c in the jar. An alternative is to use simple namespaces for the bean names. Using name aliasing solves some of the issues, see below.

    2. Users of the jar should not know about the jars use of Spring. They just get what they need using the factory pattern.

    3. As in 2 above, the jar is exposed by a single factory class or context class. This class is the one that does the Spring based wiring. Or the external client app does the Spring based initialization.

    4. Seems to me that here you need to load the jar's application context definition with the jar user's app context (a graph) that way you can inject the jar's components into the client context beans.

    btw, the book Professional Java Development with the Spring Framework in chapter 3 has a small section called "Strategies for Handling Components". In here the use of name spaces and aliasing is discussed. Perhaps the coming OSGi-Spring will make things easier.