I think the easiest way to make Roller portable among app server is to
make everything self-contained w/in the WAR itself. We did this for
security when we added in Acegi. We can do this for JavaMail pretty
easily (I actually did it once to prove a point to the JavaLobby
guys). For a DataSource, you could do that pretty easily too (with out
w/o Spring). I think if you allow JavaMail and the DataSource to be
overridden and looked up from JNDI, you get the best of both worlds.
If the WAR is self contained, it should be able to deploy on any app
server. If it doesn't, it's a problem with an underlying framework or
the server's implementation. Ever since we switched AppFuse to use
Spring to configure everything in the WAR, a lot of deployment issues
have gone away.
Matt
On 5/16/07, Sean Gilligan <[EMAIL PROTECTED]> wrote:
Hi Dave,
Lately, I've been using JNDI and Tomcat's context.xml for configuring
webapps (in turn I use Spring to do JNDI lookups and inject config
parameters, so components don't have dependencies on JNDI). By doing it
this way it is possible to produce an immutable WAR that doesn't need
any changes for deployment. All deployment-specific configuration
options go in context.xml (for Tomcat)
Pros:
1) WAR file is "immutable" artifact and compatible with all Servlet
containers
2) For releases where configuration options don't have mandatory
changes you
just deploy the new WAR with your existing configuration
3) You use the configuration method of each app server/container to
configure the war
Cons:
1) Sometimes you still have to insert context.xml into the WAR (jar
update) for deployment on Tomcat
2) Development time/integration issues?
3) Caveats could turn into cons
Caveats:
1) I've only actually used this with Tomcat
2) I haven't done this (in a clean way) for a legacy properties
file/object or a large number of config parameters (Is there a way of
pushing a properties file/object through JNDI? - Perhaps pulling a
properties file from a configured location - this would be helpful on
load-balanced configurations where multiple instances are being installed)
(BTW, I found helpful information on configuring webapps (for Tomcat)
in the book "Tomcat 5 Unleashed" by Lajos Moczar)
I haven't looked at recent Roller releases, but I get the impression
that making things 100% Apache license compatible has complicated
installation. So perhaps the WAR file version could be in the Roller
Support Java.net project and include all the software with
verboten-licenses.
Another thing that could be nice is to create a Xen Image (virtual
server appliance) for the whole thing (Roller - Tomcat - Apache - Java -
PostgreSQL).
Regards,
Sean
p.s. I wish I had time these days to be more than just a lurker. It
looks like you guys are continuing to do great work!
Dave wrote:
> The Roller installation process is unacceptably complex and I'd like
> to fix that. I've been thinking about the problem for a couple of
> weeks now and I've talked to folks in Sun, at ApacheCon and JavaOne
> about the problem. I looked at configuration features in Tomcat and
> Glassfish. I also looked at installation instructions for popular Java
> webapps Confluence, JIRA, Liferay Portal and Blojsom.
>
> So far, I've identified four these options:
>
>
> 1) Property file based configuration
> - User puts JDBC and mail-session connection parameters in
> roller-custom.properties
> - If no JDBC and mail-session properties are found, falls back to
> JNDI resources
> - Roller creates/upgrades tables as needed (prompts user 1st and
> can be disabled)
> Pros:
> - Easy, just one properties file for all Roller configuration
> Cons:
> - User still has to do configuration if they want to use JNDI resources
>
>
> 2) Separate installer for each Servlet container / app server
> - Installer prompts user for configuration parameters
> - Installer does all setup and deploys Roller
> - Roller creates/upgrades tables as needed (prompts user 1st and
> can be disabled)
> Pros:
> - Easy UI driven installation
> - Supports JNDI resources
> Cons:
> - Need to develop separate installer for each Servlet container /
> app server
>
>
> 3) Standalone bundle with Roller, Servlet container / app server and
> database
> - User downloads, unpacks, runs startup script... done!
> Pros:
> - Amazingly easy for user
> - We can steal creation script from Blogapps for the Roller, Derby,
> Tomcat bundle
> Cons:
> - We'll need a separate bundle for each server
> - Not a complete solution if user wants database other than one we
> bundle
>
>
> 4) Roller does completely handles it's own installation
> - Roller prompts user for configuration parameters, does all setup
> - Creating JNDI data-source and mail-session if needed
> - Or creating property file for non-JNDI based installation
> - Roller creates/upgrades tables as needed (prompts user 1st and
> can be disabled)
> Pros:
> - Easy UI driven installation
> - Does everything!
> Cons:
> - Need to develop separate logic for each Servlet container / app
> server
> - May be difficult or impossible for some servers
> - May require application server jars in Roller's WEB-INF/lib directory
>
>
> Before I go further with my proposal, I'd like to get some feedback.
> At this point, I'm learning towards doing both options #1 and #2.
> Option #3 is too limiting and option #4 is just too complex.
>
> - Dave
>
>
--
http://raibledesigns.com
