views:

152

answers:

2

I am a bit of a GlassFish beginner, so please forgive my ingnorance on the subject.

Basically we are serving a game website, and to make the client downloadable by our web app we copy it into a directory within domain1. The problem with this is that when redeploying the web app the client downloadable is lost and we have to copy it across again.

I'd like to be able to store the client downloadable in some external location and have GlassFish provide access to it.

I could just hardcode the link into the web app, but then we would lose portability so that's the reason for having GlassFish handle it.

I could also put the client downloadable into our database but that seems like poor use of a database and could also result in poor database performance.

The third option I have found is to add a custom resource mapping from some name to the file location, and then provide a method in one of my beans to retrieve the file location. This seems like a lot of work just to have an external resource, I feel like there must be an easier way.

So what should I do?

A: 

The link to your downloadables needn't be in the same application as the game servlets, right?

One solution would be to create a new "pseudo" application containing only a web.xml and your static file content. You would of course not deploy it in war form (well, only if you really want to) but just copy the files into the unpacked directory when you want to change content. I use a setup like this to serve a bunch of files from a Web app server I run.

At work, in an "enterprise" kind of environment, we do things differently. We have an Apache HTTPD server working as the front end. It forwards to the app server for stuff that needs to be done in Java, but any static content, as well as cookie management, SSL, load balancing and other "web server-y" stuff is done by HTTPD. This yields a bit of a performance advantage with heavily loaded sites and lots of big but static files. It also lets us split the work among different physical boxes, which again can help with performance.

Carl Smotricz
Hi, to clarify I want the link to downloadables to be accessible (clickable) from the game website but I don't want to actually be linking to an area within the domain that we website is deployed in. What I don't understand is how I would access the pseudo webapp from within our main webapp. It seems to me that I would be faced with the same problem again, how can glassfish point the main webapp to the location of the pseudo app?
PiersyP
Maybe I'm not understanding part of the problem. Your Web app is a bunch of Web pages, right? You can code any links you want into `href`s on those pages. Those links can point into the same Web app, to another Web app on the same app server, to a different machine or to Microsoft's Web site... it's just a URL, where's the problem?
Carl Smotricz
Ahhh yes sorry, I forgot to mention a vital piece of information, we will be running a development and production version, they will have different downloadables, and be running on different servers, If i code the link into the page I will have to switch it each time i rebuild and deploy for a different version. I don't want to run the risk of having customers downloading a development version of the game. So i want some way to configure glassfish to provide the location of a downloadable to the web application so that there is no need to have different versions of the webapp.
PiersyP
A professional solution would solve that problem configuratively. Any information that's different between versions goes into a configuration file and is read from there. Different configuration files are built into the WARs, or you put different configuration files somewhere outside the Web app on the different servers... you definitely want this information to be found and used automatically in a foolproof way.
Carl Smotricz
A: 

With GlassFish you can define an alternate document root to serve files from outside the war. From the documentation:

Alternate Document Roots

An alternate document root (docroot) allows a web application to serve requests for certain resources from outside its own docroot, based on whether those requests match one (or more) of the URI patterns of the web application's alternate docroots.

To specify an alternate docroot for a web application or a virtual server, use the *alternatedocroot_n* property, where n is a positive integer that allows specification of more than one. This property can be a subelement of a sun-web-app element in the sun-web.xml file or a virtual server property. For more information about these elements, see sun-web-app in Oracle GlassFish Server 3.0.1 Application Deployment Guide.

So you could configure something like this:

<property name="alternatedocroot_1" value="from=/ext/* dir=/path/to/ext"/>

Refer to the documentation for full details.

Pascal Thivent
Thank you Pascal this is just what I was looking for.
PiersyP
@PiersyP: You're welcome.
Pascal Thivent
Hi Pascal, I'm having some problems? I tried your solution by adding the following to my domain.xml
PiersyP
<property description="mapping for external files" name="alternatedocroot_1" value="from=/external/* dir=/Users/Piers/externalFiles" />
PiersyP
I know the "dir" is resolving correctly since I was getting an exception before I created "Users/Piers/externalFiles" but now I get an error when starting glassfish.
PiersyP
"SEVERE: No context found: /external"
PiersyP
I was assuming I would access the external files as follows
PiersyP
"<a href="/external/test.txt">Test</a>"
PiersyP
but this just brings me to "http://localhost:8080/external/test.txt"
PiersyP
What am I doing wrong? Thanks
PiersyP
@PiersyP You must include the context path in the link (so that it becomes http://localhost:8080/mycontext/external/test.txt). Oh, and personally, I would use the `sun-web.xml` instead of the `domain.xml`. But that's another story.
Pascal Thivent