stephan_zehnder
asked on
JBoss: Configuration inside an ear file
I'm using jakarta configuration (XML) as a configuration framework together with JBoss. At the moment the configuration files are in a separate directory under my server directory. To load them I prepend the path of the configuration to the jboss classpath.
This is the code to initialize the jakarta configuration:
ConfigurationFactory factory = new ConfigurationFactory();
URL configURL = null;
configURL = ClassLoader.getSystemResou
if (configURL == null) {
throw new ConfigurationException("Co
}
factory.setConfigurationUR
rootConfiguration = factory.getConfiguration()
The configuration consists of several xml files. The main one references all the others.
Now I would like to change this and add the configuration to my ear file. I do this by jaring them up and put it in the root of the ear file.
The problem is, that this doesn't work, because the classloader doesn't find the main config file. So what I did I took the main one and added it to the configuration folder which is in the jboss classpath, the other configuration files are in the configuration.jar only.
But I want them all in the jar. Any idea?
Thanks a lot!!
This is the code to initialize the jakarta configuration:
ConfigurationFactory factory = new ConfigurationFactory();
URL configURL = null;
configURL = ClassLoader.getSystemResou
if (configURL == null) {
throw new ConfigurationException("Co
}
factory.setConfigurationUR
rootConfiguration = factory.getConfiguration()
The configuration consists of several xml files. The main one references all the others.
Now I would like to change this and add the configuration to my ear file. I do this by jaring them up and put it in the root of the ear file.
The problem is, that this doesn't work, because the classloader doesn't find the main config file. So what I did I took the main one and added it to the configuration folder which is in the jboss classpath, the other configuration files are in the configuration.jar only.
But I want them all in the jar. Any idea?
Thanks a lot!!
ASKER
Those configuration files are not meant to be changed. That's actually also why I want them inside the jar file.
A configuration-file is meant to be changed :) e.g., the driver for the data-base to use, the connection URL (the IP-address or the machine you use as the data-base server might change, for example), authentication credentials, etc - what info are you storing in the configuration file that you don't want it to change??
ASKER
Please stop telling me what my configuration files are for.
I didn't tell you - I gave you an example and asked you what your files are for, that you don't want to change them. If you are not interested in being helped, then I'm off this question. EE is a collaborative forum and it is not possible to arrive at a solution without asking a few details from the questioner.
ASKER
What you are asking hasn't got anything do to with my question. To load a configuration file I guess it doesn't matter what is in.
What is "configDefinition" set to?
Sometimes the requirement for a problem has to be understood one level higher. One solution which will work is that the configuration-file should be present in directory. Then comes the next question - why should it not be in a directory? And I was trying to solve that because generally in all production deployments that we've done, I don't think we kept configuration-files inside a JAR file as they were likely to be changed (since they contain configur*able* parameters for tweaking the application like turning logging on or off, IP-address, port, etc - they define the configuration for your application's run and that is why they are called as 'configuration'-files).
ASKER
configDefinition is the name of the main file. In my case the name is ConfigDefinition.xml.
Together with a friend we discovered, that if I do this:
configURL = Thread.currentThread().get
it works.
But we are not sure if it is a good idea to use currentThread() in a J2EE environment.
Together with a friend we discovered, that if I do this:
configURL = Thread.currentThread().get
it works.
But we are not sure if it is a good idea to use currentThread() in a J2EE environment.
Does it work if you do:
YourClass.class.getResourc
?
YourClass.class.getResourc
?
Does the file-name have a "/" preceding it or not?
ASKER
@mayankeagle
Sure I agree with you. But the kind of configuration I have is really not to be mentioned to change by a customer. It is e.g. definition of services. They are fixed, but might change for each release. If the customer changes anything there, the product won't work.
Sure I agree with you. But the kind of configuration I have is really not to be mentioned to change by a customer. It is e.g. definition of services. They are fixed, but might change for each release. If the customer changes anything there, the product won't work.
ASKER
IUt hasn't a / in front.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Try with "/ConfigDefinition.xml"
>> configURL = Thread.currentThread().get
You might run into problems debugging that in an IDE :)
>> configURL = Thread.currentThread().get
You might run into problems debugging that in an IDE :)
Where is "ConfigDefinition.xml" specified? Is it hard-coded?
ASKER
hehe. No it is an environment variable.
ASKER
@Tim
It works with this.getClass().getResourc
I'm gonna try it with a sticky class inside the configuration jar file. This seems to be the best solution according to Mario sitting next to me.
Thx guys.
It works with this.getClass().getResourc
I'm gonna try it with a sticky class inside the configuration jar file. This seems to be the best solution according to Mario sitting next to me.
Thx guys.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
ok
Configuration-files should not be in JARs but they should be outside because they are meant to be changed (so that the application's behaviour and adaptability changes). If you keep them in a JAR, you cannot expect a user to extract it, change it and then JAR it again for the change to be effective.