On Mon, Jul 22, 2013 at 10:08:35AM -0500, Thornton, Susan M. (LARC-B702)[LITES]
wrote:
> I remember in older versions of DSpace, we created a .war file and
> deployed that in our web server. Now we use the web application path
> ({/dspace}/webapps/jspui to deploy our site.
>
> Here are my questions:
>
> 1. Why don't we deploy the .war file like we used to? Why the change,Good questions. I'm looking forward to the answers. :-) > what's the difference in doing it this way, and are there any benefits? Implementation dependent. A servlet container could treat the WAR as a compressed virtual filesystem containing files and compressed virtual filesystems (JARs), and navigate this structure on the fly, or it could just unpack the WAR into a scratch directory at deployment. IIRC Tomcat does the latter unless you configure it to do the former. So the tradeoff seems to be convenience (one WAR to deliver to production) vs. deployment time and/or additional storage for the unpacked contents. > 2. We are modifying the structure of our new DSpace sites, to include a > separate PostgreSQL server and not having the DSpace source code on the > Production server. The SAs have asked me to find out: > > a. If we can deploy DSpace 3.1 with a .war file that can just be copied > over from the Dev machine once we're ready to go to Production? WARs can still be produced, but it's not the default behavior. Run ant with -Dwars=true if you want them. > b. Are there any other ways of doing this so the DSpace source code is > NOT on the Production server? If you want to run production with unpacked webapp.s: install to a scratch directory on Dev, archive the [DSpace]/webapps directory, copy the archive over, unpack. But the simplest way might be to produce the WARs, copy them over to production, and unpack manually instead of letting the container do it. I would probably build the WARs, copy to production, and let the container do what it's configured to do. (In our shop I'd also be configuring the container, so I may not be the best example.) All this only treats the webapp.s. If you want the commandline tools on the production machine, you'd need to update [DSpace]/bin and [DSpace]/lib. But, come to think of it, there's no reason that they *must* be on that host. -- Mark H. Wood, Lead System Programmer mw...@iupui.edu Machines should not be friendly. Machines should be obedient.
signature.asc
Description: Digital signature
------------------------------------------------------------------------------ See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
_______________________________________________ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech List Etiquette: https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette
