I have several small java projects that access to same DB. Is it possible to have one persistence.xml file, which is somewhere on the file system (not included in any jars, wars, ears, etc.) and it is still visible to the projects? The reason is that there is a requirement that the persistence.xml has to be easily replaceable and configurable and the configuration has to be done on one place for all projects.
Sounds like a question somewhat similar to this: Package a runnable JPA jar putting persistence.xml outside
The answer appears to be no. However, if you were using Spring to bootstrap the persistence manager, you could wire the datasource independent of the persistence.xml and have the properties loaded from a centralized .properties file. Look at this answer for more ideas: loading .properties in spring-context.xml and persistence.xml
Related
I have a project that will be separate as:
a) Business Layer ( containing all the core Java classes and some configurations (services, etc) ) and
b) Presentation Layer (containing all the web structure based on Spring webflow and also all the configuration files on it. So in the process of development we have several properties files spread in the java/main/src under a resource.properties.* package and we have other properties in the web structure under WEB-INF/conf and WEB-INF/i18n (which are label messages for the screen)..so my questions are the following:
It's correct to leave the properties files inside of
java/main/src under packages that later will be under classes
folder in the webapp?.
Which is the best approach to leave all the
properties files in one place let say WEB-INF/configurations ? or
leave some properties files of business layer in one place and some
properties files from presentation layer in another place?
Which is the best approach to have this properties in a best way to
install the webapp?, deliver the properties in a JAR file and
include it in the WAR or EAR? that allows us to modify on the fly
and include in the war without deploy the entire application... or which is the best or used approach to accomplish that?
I've found in helpful to separate properties into two categories:
Properties for conveniently changing application look and behavior
Properties for environment-specific settings (for example DEV vs. PRODUCTION)
Category #1 can be embedded in your WAR files wherever makes sense. In WEB-INF/classes is a popular place, but putting them in META-INF in jar files can also work well. It is worth choosing a standard you like and sticking with it. The bottom line is that these files are changed during development; they are not changed after deployment and remain the same at the system is released.
Category #2 should always be separate from the deployable. Ideally, environment-specific properties should be deployed only when they change. It is really a configuration-management (CM) decision where they live. Developers need to supply the basic versions of these configuration files and CM should edit them when they are deployed to specific environments (QA, PRE-PROD, PROD). In situations where delegation of duties is mandated (e.g. where SOX applies), the production version of the properties files should never be touched or seen by developers. I've seen a lot of cases where the different versions (DEV/QA/PROD) of these files are maintained by developers and kept in source control That's not appropriate.
I think its good to have a separate source folder 'resources' and keep all the properties file there. These also make sure that the property files don't get mixed up the source code.
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 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.
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.
I have a Java/Spring/Hibernate application with a payment module. Payment module has some domain classes for payment subscription and transactions etc. Corresponding hibernate mapping files are there. This module uses applicationContext.xml for some of the configuration it needs.
Also, This module has a PaymentService which uses a paymentDAO to do all database related work.
Now, I want to use this module as it is(without any or minimal re-writing) in my other application(Grails application). I want to bring in the payment module as a jar or copy the source files to src/java folder in Grails.
With that background, I have following queries:
Will the existing applicationContext.xml for Spring configuration in the module will work as it is in Grails? Does it merge with rest of Grails's Spring config?
Where do I put the applicationContext.xml? classpath? src/java should work?
Can I bundle the applicationContext.xml in Jar(If I use jar option) and can overwrite in Grails if anything needs to be changed? Multiple bean definition problems in that case?
PaymentService recognized as regular service? Will it be auto-injected in controllers and/or other services?
Will PaymentDAO use the datasource configuration of Grails?
Where do I put the hbm files of this module?
Can I bundle the hbm files in Jar(If I use jar option) and can overwrite in Grails if anything needs to be changed? Which hbms are picked? or, there will be problems with that?
Too many questions! :)
All these concerns are actually before trying. I am going to try this in next few days(busy currently). Any help is appreciated.
Thanks.
There are a couple of things you'll want to consider:
You'll need to package your applicationContext.xml to avoid namespace clashes - that is, you'll probably put it in src/resources/com/company/module/applicationContext.xml
This application context really needs to be compatible with the grails application - it'll need to access the DB connection used by your app - make sure it doesn't define its own - See section 14 of the docs - http://grails.org/doc/latest/guide/14.%20Grails%20and%20Spring.html
Section 15 of the docs - http://grails.org/doc/latest/guide/15.%20Grails%20and%20Hibernate.html describes using hibernate mapping files
15.4 points out some good articles - http://jasonrudolph.com/blog/2006/06/20/hoisting-grails-to-your-legacy-db/ and http://www.infoq.com/articles/grails-ejb-tutorial
Probably not the exact answer you were looking for, but I hope this helps.