This content has been marked as final.
Show 3 replies
-
1. Re: JBoss application deployment - Handling properties outsi
jaikiran Apr 27, 2009 6:21 AM (in response to sittont)What is the reason for keeping these properties outside the .ear? Is it because you will have to unzip the archive to make any changes to the properties? If yes, then have a look at the exploded deployment option http://www.jboss.org/community/docs/DOC-9719. That way you can include the properties within each ear and don't have to worry about unzipping the ear for doing any changes.
-
2. Re: JBoss application deployment - Handling properties outsi
sittont Apr 29, 2009 12:14 AM (in response to sittont)"jaikiran" wrote:
What is the reason for keeping these properties outside the .ear? Is it because you will have to unzip the archive to make any changes to the properties? If yes, then have a look at the exploded deployment option http://www.jboss.org/community/docs/DOC-9719. That way you can include the properties within each ear and don't have to worry about unzipping the ear for doing any changes.
Currently our application (deployed on Weblogic) is deployed in a way that many configuration files are outside of the ear file. Also some properties related to environment issues such hosts and ports. We would like to deploy same strucrue in JBoss if possible. Is there a way to stay with this structure in JBoss. We noticed that we can't access files outside of the ear file. -
3. Re: JBoss application deployment - Handling properties outsi
jaikiran Apr 29, 2009 12:49 AM (in response to sittont)You can place those property files in %JBOSS_HOME%/server/< serverName>/conf folder which by default is in the classpath. You can then access those files in the code, something along these lines:
InputStream is = this.getClass().getClassLoader().getResourceAsStream("myprops.properties); Properties props = new Properties(); props.load(is);
But obviously, you cannot have multiple versions of the same file on the same server instance (that's what i thought your original requirement was - one version per ear on the same server instance).