Birt Report Home
Created on: Jan 29, 2009 6:39 AM by AndySteele - Last Modified: Jan 29, 2009 12:03 PM by AndySteele
It would be good to have a little more flexibility around this as this is really a system-level property rather than an application level one. At the moment I need to update this setting when moving my application from development to test - e.g. from a PC running RBD to WAS running on IBM i.
One solution might be to expose the birtEngineHome setting as a property of the BirtReport type in EGL and provide a means for accessing system/container properties (that could be the subject of a further feature request).
Of course system properties wouldn't be the only option, there could be any number of ways of resolving and adding the report engine directory.
I think this falls in with Dan Darnell's idea of a number of issues around runtime configuration for different environments.
XiLong says:
This is a good question, how to deploy EGL web applications to different environments? We need to move EGL web application to test environment, to production environment, to support environment, etc. Currently, RBD didn't have a completed solution to support this.
How about a set of ant script and properties files? Apache ant (http://ant.apache.org/) is a good solution to solve this problem. User just need to fill in the different parameters for different environment then run a set of ant script. The parameters will be replaced inside the EAR file to fit into different environment.
This is not limited to birtEngineHome setting, other parameters in an EGL web application that may vary for different environment could be handled by the ant script and properties files.
Futher more, we could give a sample Jython WAS admin script about how to deploy web application and configure the data source using Jython script other than go through the WAS admin console.
If we could make some kind of plug in within RBD with all the functions above, how do you think?
AndySteele says:
in response to: XiLong
Hi,
that is certainly one solution and one we use quite consistently. One of the points I was trying to make is that often these are application container level settings and one of the tenets of JEE is that when this is the case you let the container handle it and use JNDI and the like to reference the resources you need. This means that you can promote your application without lots of fiddling and recompiling and repackaging and so on. This reduces the risk inherent in promoting your application through the various steps to production. It also means you only have to configure the resources once, when you set up your target server; and to some people, even more importantly, it's in the hands of the system admins and not those pesky developers 
Yes I know there will be arguments about recompiling without debug settings and so on but we find that to be a minor problem compared to the other risks.
However, I do like the idea of a tool to generate the wsadmin scripts, we write those by hand just now. That wouldn't just be a boon to the EGL folks but also the wider Websphere community.
Of course we're talking specifically about WAS and Java here, how would this fit with other target environments?
Andy
Indeed. I concur.