Lets say I have two applications which both use Hibernate and both share some functionality, if I were to separate the shared functionality into a library what is the best way to structure the hibernate configuration?
I don't want to have to replicate the shared parts of the hibernate configuration in both my applications so is there a way I can save some configuration in the library (i.e. just the mapping elements for classes in the library) which is then loaded dynamically into the applications hibernate config at startup?
If you use spring, you could create an abstract bean with your base hibernate configuration, and then have your clients extend from that.
By using annotations, much of the mapping configuration ends up bound to the code. Library clients then only need to specify the package so that the hibernate annoatations are processed and added to the mapping configuration.
if you want to put all thge mapping elements in a jar & reuse them you can use the tag
<mapping jar="" />
here you pass the path & the name of the jar file (so the jar could be reused over & over again).
with this technique you will be able to share the hbm configs only..
if you need to share any other components there are different ways to do that.
Related
My application utilizes many libraries that each require their own configurations.
For example, both Hibernate and Apache Shiro requires me to specify database connection details in the configuration files of each library. Is there any method of centralizing these values into a single file, XML or otherwise, that would make it a lot easier to manage?
In this situation, you can either
configure the libraries programatically, without configuration files, using a common framework. e.g. Spring.
generate the configuration files using templates for each configuration file and a shared set of properties.
There is no universal solution. Each library (typically) has its own way of doing configuration that isn't conducive for sharing with other libraries.
If you were using Spring DI, then there is considerable scope for sharing configuration via Spring XML wiring files ... provided that the library is configurable that way. (The latter means that you need to be able to inject the configuration information; e.g. as a Properties object.)
Another possibility is to use something else to generate your configuration files; e.g. Chef or Puppet ... or old fashioned macros.
I am having some problems getting Hibernate and Spring up and running. I have a web server project which makes use of several other projects which have persistent entities in them. The problem I have is that I get a ClassNotFoundException for an entity class that is stored within another jar inside of WEB-INF/libs.
Do I need to have a persistence.xml for each jar that contains entity classes?
Please let me know if you need to see any configuration files.
Depending on your set up there are probably a number of different ways to solve this - and none them usually feel idea (IMO).
The essential problem is to do with ClassLoader isolation. There are rules as to what the files within a jar can access.
In your particular case, the easiest way to solve it is probably to put the persistence.xml within the parent web project. If you are not using persistence xml, you need to bootstrap hibernate/spring from the web project.
The parent web project should have access to all the libraries within its WEB-INF/lib whereas each of the jars in the libs folder may not have access to each other.
You could set up another persistence.xml in each jar but they would not be composited together into one persistence unit. You would need to use a different pu depending on which entity you wanted.
We have a team of 5 to 8 people and our project is using Hibernate (ORM) but we are facing some problems related to HBM files and there respective VOs (Value Objects). Actually we all are working on different modules and we all are creating HBM files and there respective VOs as per our module (so we have our HBM files and VOs specific to our module). If common table is used in more than one module then we have multiple HBM file and their VOs for that single table. So should we place all the HBM files anf VOs to a specific location or keep them module specific even if we have multiple HBMs and VOs. Please suggest the GOOD or BAD practice as well.
Thanks
From the query it seems each module has its own data access. If its not very complex, you can put all the data access in separate module. A project can have multiple modules but should have one place for data access.
As suggested, you can have a DAO module which is only doing to Data related operations.
Packages can be used to identify different DAO types.
The common DAO should be kept simple. Business Logic should not go in that. Logic should be handled at a higher level.
Other than that :-
Your project should be properly structured i.e. packages should be clearly defined.
module1/src/../com/../../bl
module2/src/../com/../../b0
dataacess/src/../com/../../bl
dataacess/src/../com/../../bo
Dependencies should be clearly extrapolated. If you have one DAO module then DAO should be independent. Other Modules should depend on DAO. If its java you can use maven to do this.
Finally its the choice we make. There will be lot of best practices. You should choose what suits best in your scenario. In the end it should be simple and manageable in future.
There should be a common project that will contain all DAO related stuff. Each module/project will include that commonDAO project in its classpath to perform hibernate and database related operations. This will overcome HBM files duplicacy and ease to maintain code.
There are several java SE apps using the same library and working with the same database via Hibernate (not JPA). Where do I put hibernate mapping files and hibernate config? (so what can be extracted to the library?)
Put everything that is common to all applications in the library, and everything related to a specific application (database URL, user, password, but maybe also caching options, etc.) outside of the library.
At then end, everything is loaded from the classpath. Whether the files are in one jar or another doesn't matter for Hibernate.
If you use annotations, most of the configuration will be in the entity classes anyway.
You might consider extracting all those mapping into single "DAO" project. Then you might add "DAO" dependency to all your apps. This way only "DAO" would communicate with DB and only "DAO" will require such mapping files.
We can use both Spring config file OR a .properties file to store and retrieve some properties, like for a database connection. (db url, db password and etc)
We can also use Spring config file and a .properties file together, where we reference the property from a .property file (like in ant)
What would be the advantages or disadvantages for the following scenarios:
1 - Using only .properties file.
2 - Using only Spring config file.
3 - Using both together.
Would any of the scenarios be better when it comes to maintenance?
I need to choose between the three, and I would like to have a better judgement before I go with any of the option!
Thanks in advance!
- Ivar
Both together. Use a properties file that's externalizable from your project to configure Spring. Spring then configures your project. Mostly, you don't write code to read from properties files. Let Spring manage that and inject your objects with the appropriate values. Then you have appropriate dependency injection and the artifact you build isn't environment-specific.
Disadvantages:
How does your code know what file to load the properties from? Isn't that a property? It also violated dependency injection by having code go find a resource rather than passively accepting one.
Configuration is tightly coupled to your artifact and can't change between environments without rebuilding (BAD).
The way you seem to think of it, this combines the disadvantages of the other two, but if you do it the way I described, it eliminates those disadvantages, which is an advantage.