Announcement Announcement Module
Collapse
No announcement yet.
modifying a bean definition Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • modifying a bean definition

    I have my bean defs split into 2 files. I have done this because I have 2 applications, one which requires the beans in file 1 and one which requires the beans in both files 1 and 2.

    In file 1, I have defined a Hibernate session factory which is passed to several other beans.

    My problem is that in addtion to additional beans, my 2nd app also needs additional hibernate mappings. How can I get these mappings into the session factory for app 2 but not have them there for app 1?

  • #2
    I do not know no way to add new mappings to Hibernate SessionFactory after it has been configured. You can however do the following :
    1. create a new file (file 3), copy the configuration of your SessionFactory into this new file and make the configuration meet the exact requirements for application 1.
    2. move the initial definition of your Session factory from file 1 to file 2 and add the additional mappings
    3. configure application 1 to use files 1 and 3
    3. configure application 2 to use files 1 and 2

    HTH

    Comment


    • #3
      Thanks.
      That would probably work ok, although I was hoping for a way to override a bean def.

      Comment


      • #4
        You can also use parent and child bean definitions, to provide most of the information about a bean in one definition, and actually create it somewhere else.

        http://www.springframework.org/docs/...an-definitions

        Regards,

        Comment


        • #5
          I'm wondering how that would work.

          The parent bean would be defined in file1 and referenced by other beans in that file. Then I would create a child bean in file 2 and refernce it by other beans in that file. Would that work? Wouldn't this create to session factories?

          Comment


          • #6
            Well, you'd have a parent somewhere, declared as lazy-init so it doesn't get instantiated, and that would be used by one source.

            Then you would have a child, which would just override the mappings, and that would be used by the other source. Depending on whether the child def would ever be around when only the parent needs to be used, you might have to make the child def lazy too, but that's no issue, either the parent or child will still be created when it is actually used.

            Alternately, you could have one "abstract" parent, and then two children, which just override the mappings. This would save having to set a few properties, and the classname.

            Regards,

            Comment


            • #7
              Let me see if I undestand you.

              If I have the parent defined in file 1 and set to lazy-init and then have the child defined in file 2, and then the first bean my application accesses is one of the ones from file 1, this will still cause the creation of the bean based on the definition in file 2?

              Comment


              • #8
                No,

                I'm saying if a bean is marked lazy-init, it won't be pre-created, which is what normally happens for singletons. A lazy-init bean will simply be created only when asked for, either directly, or because it is a property of another bean.

                You can define both the parent and child as lazy init, and then use either one as needed, and only the one actually used will be created, when it is actually used. The reason I made the point about the child possibly not needing to be marked lazy is that if the file fragment it is in is not even used for one use case, then of course it will never be know about or created under any circumstances.

                Regards,

                Comment


                • #9
                  But my question is, since I will be using beans from both files, will I end up with 1 sessionfactory or 2?

                  Perhaps I should give some more info:

                  File 1:
                  <beans>
                  <bean id="xenonSessionFactory" lazy-init="true"
                  class="org.springframework.orm.hibernate.LocalSess ionFactoryBean">
                  <property name="configLocation">
                  <value>classpath:config/hibernate.cfg.xml</value>
                  </property>
                  </bean>

                  <bean id="tradeDAO"
                  class="com.sknt.picasso.dao.trade.TradeDAOImpl">
                  <property name="sessionFactory">
                  <ref local="xenonSessionFactory"/>
                  </property>
                  </bean>
                  </beans>

                  File 2:
                  <beans>
                  <bean id="migrationSessionFactory" parent="xenonSessionFactory">
                  <property name="mappingResources">
                  <list>
                  <value>MigrationTask.hbm.xml</value>
                  <value>MigrationTaskType.hbm.xml</value>
                  </list>
                  </property>
                  </bean>

                  <bean id="migrationDAO"
                  class="com.sknt.picasso.rdbms.migration.MigrationD AOImpl">
                  <property name="sessionFactory">
                  <ref local="migrationSessionFactory"/>
                  </property>
                  </bean>
                  </beans>

                  Now in my application, I may use either or both of the DAO beans in any order. However, I never want more than one session factory created. Will the above do this?

                  Comment


                  • #10
                    It's just a dependency graph which is what controls what is created. The actual files are almost irrelevant. So yes, if in your app2 you use a DAO from file fragment one, which refers to the parent session factory, and you use a DAO from file fragment two, which uses the child session factory, you would create two session factory.

                    In your case, you are better off in each case referring to the session factory via some alias, and then for each app have an app specific fragment which actually defines the session factory specific to that app. You could still leverage parent/child definitions to make this a bit smaller, though.

                    Regards,

                    Comment

                    Working...
                    X