View Full Version : modifying a bean definition
Aug 16th, 2004, 03:41 PM
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?
Aug 16th, 2004, 03:47 PM
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
Aug 16th, 2004, 03:56 PM
That would probably work ok, although I was hoping for a way to override a bean def.
Aug 17th, 2004, 11:58 AM
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.
Aug 17th, 2004, 12:16 PM
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?
Aug 17th, 2004, 12:21 PM
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.
Aug 17th, 2004, 12:29 PM
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?
Aug 17th, 2004, 12:35 PM
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.
Aug 17th, 2004, 12:59 PM
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:
<bean id="xenonSessionFactory" lazy-init="true"
<bean id="migrationSessionFactory" parent="xenonSessionFactory">
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?
Aug 17th, 2004, 01:15 PM
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.
Powered by vBulletin® Version 4.2.1 Copyright © 2013 vBulletin Solutions, Inc. All rights reserved.