This content has been marked as final. Show 4 replies
it sounds like you are using APEX Listener in Standalone Mode (i.e., you start the apex.war with java -jar apex.war and do not deploy it to a JEE Container), right?
next to the /i/ folder in a folder of our ownWhere exactly is that folder located? I assume you've created subdirectory blow the one you reference for +/i/+, right?
The only workaround we could come up with is to place a symbolic link into the /i/-folder pointing to the directory we want to include.It sounds like you've either got some typo in your directory name or perhaps use some special characters that would need to be escaped in your Linux environment. Please also note that Linux handles file and directory names case sensitive, which Windows doesn't. The fact that you can create a link to the location tells me that there exists no directory with the exact name you used for your link, so the directory name you reference must have a different name than the one you reference in APEX.
The folder we want to include has been granted 777 to exclude any potential access problems from within UNIXI'd recommend to change from 777 to a more safer approach. If you actually run in Standalone Mode it would be sufficient to give access rights to the user you run your APEX Listener with.
Make sure you not only change that value for the subdirectory itself, but recursively for all files/directories below, and ensure they all have the proper owner set.
Assuing, that you are in the directory referenced by +/i/+ and you run APEX Listener with a user named "oracle" you could execute the following:
I'd even set 500 just for directories, as all other files don't need execution rights and hence could live with 400 (read-only). A simple bash script with a for loop could do that for you...
chown -R oracle subdirectory chmod -R 500 subdirectory
we're using APEX Listener in standalone and in Tomcat/Glassfish environment, with no differences in outcome.
the structure of the folders is like so:
That means that everything works fine if we place folder "foo" into folder "i", but folder "foo" can't be seen when positioned as a sibling to "i". This on the other hand is what we want to achieve to allow for folder "i" to be replaced by a new version anytime APEX feels fine to recommend that.
Within our APEX application, we tried to point to this directory with ../foo/... or /foo/... but with no luck on the UNIX machine. Strange to us is that the very same setup is working fine on Windows (Tomcat, Glasshfish or standalone mode).
I agree in regard to your comments about the user rights, the actual setting we chose was simply to be sure that nothing UNIX-specific comes into play here as well.
docrootThis can't work in standalone mode, since the embedded nature has fixed contexts (including +/i+ and +/apex+ ) without a chance to add custom contexts.
It will work in Tomcat/GlassFish, if you deploy the contents properly. You could do this by creating a war file that carries your files, but I wouldn't recommend this as there are more convenient ways to make static contents available.
Tomcat for instance has a ROOT context when running on a default setup. This context can be used to host static contents similar to a plain HTTP Server, e.g. when using the htdocs in Apache HTTP Server as docroot. So you could simply copy your foo directory into the ROOT context and should be able to access the contents using http://yourtomcathost:yourtomcatport/foo/filename .
GlassFish has a similar concept for that: Each domain has a docroot directory. Just as explained for Tomcat, you can simply create/copy your foo directory there to make it available for your clients.
If this doesn't work, you have a general problem with your GlassFish/Tomcat configuration, as the docroot has nothing to do with APEX Listener. I just retestet with fresh GlassFish/Tomcat on Ubuntu 8.04 LTS (Server Edition) as follows:
1. download zip packages from http://glassfish.java.net/ or Tomcat mirror respectively.
2. unzip package
3. create directory "foo" in docroot (for GlassFish) and ROOT (for Tomcat)
4. create file "bar.txt" in "foo"
5. start server instance
6. use a remote client to access http://mybox:8080/foo/bar.txt and got the file.
How did you install your GlassFish/Tomcat on your Ubuntu?
Either way, if you tried the docroot/ROOT approach and failed, you could still try the war-file deployment. Perhaps your GlassFish/Tomcat instance has disabled the docroot/ROOT context for security reasons.
Note that you can't have both, i.e., you can't use the war file with context +/foo+ and still have a +/foo+ subdirectory in your docroot/ROOT.
Thanks very much for your help indeed. This did solve our issue!