JBoss a dead-end

[sudsy]

"sudsy" wrote:

"sudsy" wrote:
Mighty harsh words, but I came to that conclusion as a result of much reading and experimentation on my part trying to get one essential element working: specifying the context root directory for an application. Without that capability then JBoss will be limited to niche applications or those that store all data in a database. None of your typical e-commerce solutions can effectively use JBoss as the application root will change every time the server is restarted or the application redeployed.
I know I'm not the only one looking for a solution: the forums are rife with this question posed in various ways. As you do a lot of digging and reading you find various dead-end solutions, like using the context-root tag in the jboss-web.xml file (doesn't do anything) and lots of discussion about the context or Context tag in the catalina control files (inaccesible). Then you run into an official-sounding post which states straight out that "you can't do it!"
And I was so eager to use the local EJB interfaces! Some solutions even went so far as to suggest using a "real" Tomcat as the application front-end. This would then relegate JBoss to being an EJB-only engine, and not very efficient at that since you'd have to use the remote interfaces. You couldn't use the servlet/JSP elements since they wouldn't be using the same application root.
Such a common requirement and yet JBoss can't deliver. Sigh! Guess I'll have to use the Sun ONE server or else spend some serious dough on a "professional" solution like IBM WebSphere. A nice try otherwise, people!

[jflinchbaugh]

"jflinchbaugh" wrote:

"jflinchbaugh" wrote:
are you trying to specify an arbitrary context path different from your war name? like deploy app.war with a "/myapp/" context path?

or are you trying to deploy an app as the root (/) of the server?

i think the root app should go in ROOT.war, but i think i've seen this not work for my jboss/tomcat install.

if you want to specify a context-path, i don't think the standard provides a way in the war itself, but you should be able to specify a context per each web app in an ear file. you may just need to package your war within an ear, and specify it in your application.xml.

[sudsy]

"sudsy" wrote:

"sudsy" wrote:

"jflinchbaugh" wrote:

if you want to specify a context-path, i don't think the standard provides a way in the war itself, but you should be able to specify a context per each web app in an ear file. you may just need to package your war within an ear, and specify it in your application.xml.

Allow me to be more specific. Suppose I have a web application which permits uploads of images which are then "massaged" by a JSP and then inserted into the application directory structure. The standard mechanism is to use ServletContext.getRealPath() to perform the mapping. The problem with JBoss is that what I call the application root (the location within the filesystem) changes every time the server is restarted or the application is redeployed.
My "working directory" (for the purposes of getRealPath()) might be:
$JBOSS_HOME/server/default/tmp/deploy/tmp39271MyApp.ear-contents/MyApp.war
This entire directory structure is destroyed when the server is shutdown. IOW, there is no persistence. Every other servlet container or J2EE server has provided the capability to specify the root of an application in the filesystem such that I don't lose data when the application is stopped and restarted.
THIS is the restriction to which I refer. I know all about context paths and have no problems there. My production server is Apache/Tomcat and I can specify the docBase and appBase of my Host/Context pairs. I can do the same in IBM WebSphere and BEA WebLogic using the console webapps. So my question is why does JBoss have this glaring omission?

[alanmoor]

"alanmoor" wrote:

"alanmoor" wrote:
The way I got around this was to expand my war file in the deploy directory. Hot deployment is neat and cool and everything, but outside a development environment, has little real use. Besides, if I want to redeploy my app, I have found all I need to do is replace the components I need, then touch the WEB-INF/web.xml.

If you expand myapp.war into {jbosshome}/server/default/deploy/myapp.war directory, then getRealPath("/docs") will yield {jbosshome}\server\default\deploy\myapp.war\docs.

Another issue that drove us to this was some poorly written 3rd party code that actually requires OS file names for locations of configuration files. Stupid but true.

[sudsy]

"sudsy" wrote:

"sudsy" wrote:
Interesting work-around, but does it work with ears? And, more importantly, will a symbolic link into the deployment structure be both recognized and maintained?
Just so you know, I've already formulated a number of ways around the problem but I hate to code solutions to problems which only exist in a single abberant platform.
I know how to make it work with "vanilla" Tomcat so why is the version bundled with JBoss artificially crippled?
Doesn't it bug you that you have to work around these silly limitations? It would certainly preclude the product from serious consideration in any number of "real world" scenarios IMHO.

[vertigo]

"vertigo" wrote:

"vertigo" wrote:
Working with the expanded "folder.ear" (and with expanded "folder.war"'s within) works ok. But I totally disagree with you on your approach to the "upload" problem.

You see, you application folders should not be treated as a repository of any sort. An applications server like WebSphere or WebLogic might expand a deployed EAR into the folders you are using, but there is no contract saying that these folders should remain intact on a server restart or on a redeployment. That is plain bad design on ANY application server. In a clustered environment, for example, any upload to the application "real" diretory would be useless. If file uploads are needed, try using a network storage (like a configurable path **OUTSIDE** the application known to all servers on the cluster). Any other approach, in fact, is a silly design on a serious production environment (no offense).

[erik777]

I whole heartedly agree. You shouldn't even, IMHO, put these folders inside the JBoss installation at all, let alone inside the deploy or application folders.

Even in websphere, we used folders entirely outside the application for any incoming or outgoing data files, whether imports, logs, generated reports, or anything else. Then use a properties file to configure their location, and an application properties class for loading configuration properties.

[captrespect]

I have the same problem as this guy. I have an app that lets the users upload pics and they will be used in the application.

I have the upload directory outside joss like /usr/pictures

Uploading to this directory is no problem, but how do I serve from this directory through simple web links? I would like to just say something like:

<img href = "/userpics/image1.jpg"/>

So how do I map /usr/pictures to /userpics in a way that they can be served by the same webapp?

Thanks,
Jon

[captrespect]

I figured out the answer to my problem and posted the answer here:

http://jboss.org/index.html?module=bb&op=viewtopic&p=3823101#3823101[/url]

[rbottoms]

You've answered a question I've had for years about static content. Not so useless a rant after all. Maybe this section should be renamed just Rants.