On 25/01/2011 7:03 AM, Miguel Almeida wrote:
Anders,
I think I understand what you mean, but it doesn't seem to be very different
from the current approach.
Get rid of the profiles. You don't need them and they are leading you
astray.
Get your deployment stuff out of your WAR. Sooner or later some test
deployment artifact will get into production and make a very nasty problem.
JNDI is very simple and Tomcat gives you a place to put them.
Your JNDI stuff is pretty stable and is easy to change.
As was said earlier it is not a Best Practice to put something into
production that you have not tested and if you change it and don't test
it again, you are doing exactly that.
This is not only the right way to do it, it is the way that most people
do it so you will not have any problems with the tools.
Eclipse and Maven are designed to work this way.
Investing a new way to do something that should not be done at all is a
waste of time.
Ron
On Tue, Jan 25, 2011 at 11:35 AM, Anders Hammar<[email protected]> wrote:
Antonio is right.
This has been discussed several times. Search the archive for many examples
of doing this, including using JNDI or putting a properties file on the
classpath.
This leads to having, for example, a config-dev.xml, config-prod.xml,
config-clientTest.xml, etc in our code and, if necessary, use a filter to
build only with one of those. I haven't used JNDI much, but it seems more
complex and it might scatter the configuration if you need to put the
configuration outside the app (like in tomcat's configuration file). If one
can use JNDI with a similar approach as before (ie, one config.xml file),
then it's the same case I mentioned.
I understand this would require changes to your code base. Major changes
possibly. But it is the right way to go. Once you have donw this, adding
new
environments is a small task instead of requiring a new build (and breaking
close to everything Maven is about).
What I still am failing to realise is the major problem with putting this
in the profile: building a new environment now is as simple as adding a new
profile in the pom.xml. The only downfall I see is that I now effectively
have eg {log4j.loglevel} in my log4j.properties and the app will fail if I
don't define log4j.loglevel in the properties section of the active profile.
But that seems to also be the case with any other approach: if I don't
define the string in JNDI it will also not work.
Users in the archive suggest a variety of methods, from JNDI to profiles. Is
there any other pitfall I'm not seeing?
<profile>
<id>dev</id>
<properties>
<isDevelopmentMode>true</isDevelopmentMode>
<hibernate.connection.url>jdbc:postgresql://locahost/develomentDB</hibernate.connection.url>
<application.uploadPath>/mnt/devel/</application.uploadPath>
...
</properties>
</profile>
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
