Application config file outside the EAR

[smokingapipe]

Simple question: What is the way to store application configuration information outside the EAR file? For example: my app allows users to upload lots of content. I'll be storing this in the filesystem, not the DB (I know, there are pros and cons to both approaches).

There are a few other run-time config options, too, What I would like to do is store all these in some file that goes along with the EAR file. I don't want to have to modify files within the EAR itself.

Is there a standard way to send config settings to the app, ideally making them available as Seam variables?

[smokingapipe]

No ideas on this? It sure would be nice to have a properties file somewhere in JBoss that is external to the EAR that lets me define parameters that are visible to Seam. Like the location of an uploads directory, etc.

[tcavaleiro]

Why don't you use a database to save that config file?
Or save the parameters to a table.

Just saying that because if an EAR archive "represents" an application there's no way to set some config file to that application directly... but I'm just a noob in JBoss...blahbhlah.

[pmuir]

How about a properties file. It's loadable from your app anywhere on the apps claspath.

[smokingapipe]

I could do that, but isn't the app classpath all within the EAR? I want to be able to ship out an EAR file on a CD and have the sysadmin (who knows nothing about any of this stuff) be able to copy it into a directory and say, "I'm done".

My idea right now is to try to do this the JBoss Way. Not knowing exactly what the JBoss Way is, I'm trying to use an MBean so that config params could be set within the jmx console. That's how all the other services within JBoss are configured, so why not configure my application that way?

Turns out it was very easy to create an MBean that is visible within the JMX console, and to be able to get and set properties.

What I need to figure out now is how to make that mbean data persistent across server restarts. I'm Googling for that but any suggestions would be welcome.

Any other options? Is there some place within the JBoss directories where I could / should stash a properties file that is external to the EAR?

[smokingapipe]

From reading a bunch of pages on the Wiki it looks like what I need to do is set up a SAR with a simple persistent xmbean in it. Then I need to have my application EJBs find and connect to the mbean that's in the SAR. A bit cumbersome but a workable solution. Is this the right way to go?

[modoc]

It may be the best option currently, however, this is an issue that is near and dear to me.

My day job has me working on a pretty nice commercial Java web application framework, which includes a really well thought out (in my opinion) configuration mechanism involving a config path (like a classpath). You configure your components using .properties files with the name of the component placed in the path of the component hierarchy, etc...

The cool part is that you can have a component, let's say one that is part of the framework itself (not a new one you made), which has it's default configuration as part of the framework. In your application/project you have a config directory, where you override or update a few of those settings, as needed. In your project you also have a liveconfig directory, where your non-server specific production settings go (say upping the cache size, or database connection pool size, or whatever). In the server instance on your desktop/laptop you also have a localconfig where you put settings specific to your computer (mail server, a local instance of an external webservice, etc... And in the server instance on the shared dev, or test, or staging, or preview, or production servers, they also have the environment and server specific settings there.

That way you can build and deploy the project locally, testing it, push that kit to shared dev, then to test, then to stage, etc... all the way into production, and the application just works. It's really brilliant, and pretty essential for big enterprise type environments.

Maybe I'm missing something, but I haven't found the parallel functionality in JBoss or Seam.


As part of my rant here, I want to ask for component specific properties files, instead of having to use the more cumbersome xml files, or a shared seam.properties:) I'd also love to see a standard component naming scheme that isn't so similar to package and class naming. A component's namespace and name shouldn't be related to it's package and class necessarily, and by formatting them the same, there's some implied link and confusion (imho).

I'd like to get a discussion going on configuration mechanisms, layers, etc... in general.

Devon

[smokingapipe]

I just got my SAR working and it is persistent. Now I have to get access to the SAR's mbean from within the EAR. That seems like that should be easy. And the persistent SAR itself was pretty easy, and this is a nice way to do all this, so config parameters can be used from the jmx-console. It's a little bit much coding but it's ok.

[smokingapipe]

Actually using MBeans is better than just having it read a config file somewhere. With the bean, I get to store properties, and yes, that is more cumbersome than putting them in a config file. But I get to do more: I can have the bean not only store the path to the file storage directory, but also check the status (permissions), create it, clear it, give statistics about it, etc. So it's a reasonable way. It is a bit of XML to manage, but it's workable.

[modoc]

The issue, in my mind, is that using mbeans doesn't lend itself to the scenarios I had in mind, with environment (dev, test, stage, etc...) and server (app01, app02, etc...) specific configs.

However, I'm glad it worked for your situation! Can you put up an example of how you're using the SAR as a config mechanism?

-- Devon

[ericjava]

Here is source code that shows all of the above: a persistent XMBean, accessing it within a web application, creating it as a Seam component, and wrapping the MBean proxy for safety: http://chiralsoftware.com/master-sauce/. This is still a work in progress, and in fact it always will be in progress, hence the name. You can build the app using:

ant -f build-template.xml ear

Or you can generate an app:

ant generate

and then go into that app and build it:

ant ear

It's an alternative to Seam-Gen. It does a few more things that we need in every application, like admin users, a SAR to store configuration, etc. Let me know what you think of it. It's really an in-house tool, and is not a finished product, but I'm putting it out there because it might be of interest or use. And it shows how to use a SAR to store config information outside the EAR.