Announcement Announcement Module
Collapse
No announcement yet.
Dependencies in applicationContext Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Dependencies in applicationContext

    Hi,

    We have a large project where we have POJO'ed most of our existing ejbs. The ones we have not fully POJO'ed are our stateless session beans acting as facade entry points for third party (other project) access i.e. where other projects accesses our functionality via JNDI lookup to our Remote EJB's and even here we have POJO'ed the business logic to enable better testing and they all extend the AbstractStatelessSessionBean.

    In doing this we have created a couple of application context xml files that inject dependencies into these POJO's. All singleton beans have been set to lazy-init=true.

    We also want to use these context files within our web applications as well as well as our non J2EE clients. The web applications use a subset of the beans defined in the contexts. The problem now comes that even with lazy-init=true (i.e. I only want to instanciate a bean if its used) all jar files required to satisfy even the unused beans (i.e. ones that will NEVER be used within this web application listed in the loaded context files) are needed on the class path. This has bloated our deployment and has meant that each of our maven projects now require dependencies on other projects or jar files they will never use.

    We have kept the context files course like this with the intention that they go into one project which contains only the xml context files and the resultin jar file is included in all projects using any context. All these individual context files are then accessed either with the singleton classpath*:breanRefFactory approach (listing each individual context) within ejb projects or with a webRefFactory.xml that just uses the import element to import all other context files and keep things simple for project members getting used to Spring.

    So we now have a situation that ALL our individual maven projects (enabling fine grained deployment of our application) depend on ALL other maven projects bloating all individual deployments and introducing non dependend dependencies.

    Can anybody recomend the best way to resolve this issue.

    Regards

    Steven McArdle

  • #2
    Originally posted by smcardle
    We also want to use these context files within our web applications as well as well as our non J2EE clients. The web applications use a subset of the beans defined in the contexts. The problem now comes that even with lazy-init=true (i.e. I only want to instanciate a bean if its used) all jar files required to satisfy even the unused beans (i.e. ones that will NEVER be used within this web application listed in the loaded context files) are needed on the class path. This has bloated our deployment and has meant that each of our maven projects now require dependencies on other projects or jar files they will never use.
    Without a concrete example scenario, I feel it kind of hard to grasp exact complexity of your system. Is it possible to move the beans used by your web app to a separate context file, and only have that one loaded by the web app?

    Comment


    • #3
      Hi,

      No its not. Foe example the DAO beans are used by all ejb deploymentsand all web deployed components.

      Our maven projects produces components in the form of jar, war or ear files a single jar could be a group of utility classes used by many other parts of the system or it can be a jar that has specific functionality used by only a part of the system such as barring a SIM card.


      Regards

      Steve

      Comment


      • #4
        Originally posted by smcardle
        No its not. Foe example the DAO beans are used by all ejb deploymentsand all web deployed components.
        Mmm, I'm very likely still missing something here - why can't you put all the DAO (and other container-agnostic beans) in a context file, say, commons.xml, all the ejb stuff into ejbs.xml, and all the web related into web-beans.xml? For EJB deployments, deploy commons.xml + ejbs.xml, and for the web apps, deploy commons.xml + web-beans.xml?

        Comment


        • #5
          Hi,

          Because we have more than 1 web project (4 actually) and more than 1 ejb project (3 actually)

          So unless I go through each and work out the actual dependencies or each project and break them up individually I will continue to have these dependencies.

          As a side issue, why does the container initialisation check all of the classes defined by the bean class attribute exist in the class path when they have been defined as lazy-init ?

          Would it not be possible to NOT check the classes are available in the class path UNTIL the container tries to initialise the bean. This would mean that all NON lazy-init singleton classes would as as currently defined i.e. at container startup, but all lazy-init or prototype beans would only be checked at creation time. OR could we just have a setting that say DONT CHECK CLASSES EXIST in class path until bean creation time. I don't mind having ClassNotFoundExceptions in my log files for when I am an idiot.

          This would mean that as long as I define all my singleton beans to be lazy-init I could have them all in a single context and only supply jars required by each application that initialise certain beans.....

          Regards

          Steve

          Comment

          Working...
          X