Web Facet/Web Resources

I have projects set up as follows

module/
module/src
module/src/java
module/src/test

module/src/web
module/src/web/images
module/src/web/styles
module/src/web/WEB-INF
module/src/web/WEB-INF/jsp
module/src/web/WEB-INF/jsp/content1
module/src/web/WEB-INF/jsp/content2

etc.

setting up an IDEA module with the java source and java test is not a problem.

I set up a web facet with a web resource directory set to "module/src/web" and the "path relative to deployment root" set as "/".

this works great except for the editing the JSPs... the struts config, tiles config, spring, etc. all recognized the paths just fine with the JSPs in "content1" and "content2".

the problem is editing the JSP. the code references things line "images/xyz.gif" or "styles/default.css" -- IDEA says that the directory "images" and "styles" do not exist -- because it is looking for it to be under "module/src/web/WEB-INF/jsp/content1".

in reality those jsp are rendered at runtime at the root so the references to "images/xyz.gif" etc. work just fine.

How can I configure IDEA/web-facets to recognize this structure and not give me warnings on the relative references? (it won't let me setup multiple embedded roots or any other combination i've tried)

7 comments
Comment actions Permalink

(I guess this question could apply to non-EAP builds as well, I there any way to move it to a different forum to try and get an answer?)

0
Avatar
Nikolay Chashnikov
Comment actions Permalink

Hello k,

As far as I know locating JSPs under /WEB-INF/jsp is specific for JRun App
Server. IDEA don't take into account server-specific agreements when resolving
file references in JSPs.

I have projects set up as follows

module/
module/src
module/src/java
module/src/test
module/src/web
module/src/web/images
module/src/web/styles
module/src/web/WEB-INF
module/src/web/WEB-INF/jsp
module/src/web/WEB-INF/jsp/content1
module/src/web/WEB-INF/jsp/content2
etc.

setting up an IDEA module with the java source and java test is not a
problem.

I set up a web facet with a web resource directory set to
"module/src/web" and the "path relative to deployment root" set as
"/".

this works great except for the editing the JSPs... the struts config,
tiles config, spring, etc. all recognized the paths just fine with the
JSPs in "content1" and "content2".

the problem is editing the JSP. the code references things line
"images/xyz.gif" or "styles/default.css" -- IDEA says that the
directory "images" and "styles" do not exist -- because it is looking
for it to be under "module/src/web/WEB-INF/jsp/content1".

in reality those jsp are rendered at runtime at the root so the
references to "images/xyz.gif" etc. work just fine.

How can I configure IDEA/web-facets to recognize this structure and
not give me warnings on the relative references? (it won't let me
setup multiple embedded roots or any other combination i've tried)



0
Comment actions Permalink

It isn't a JRun isssue. We are using WebLogic.

The JSPs are never called directly, they always get accessed via some sort of servlet mapping-- either directly in struts-config, a spring-mvc definition or via tiles-def --- in which case the JSPs can be placed anywhere.

It is convention to place JSPs under WEB-INF so they are not accessible directly via a URL.

for example...

A spring defined bean:
]]>
...

Associated with a tiles def:
<definition name="successXyz" path="/WEB-INF/jsp/content/successXyz.jsp"...
...

means that /WEB-INF/jsp/content/successXyz.jsp will get rendered out at /xyz.html

when I am editing /WEB-INF/jsp/content/successXyz.jsp in IDEA I should be able to reference other resources (images, scripts, etc) that are relative to /.

0
Comment actions Permalink

Placing JSP's under the WEB-INF is one of the conventions used in web development. This seems to stem from the days when bugs in application servers made it possible to serve up the content of a JSP without executing it. Those days are long since past so people tend to use that convention now either out of habit or out of the misguided sense that it adds security.

If you check Sun's guidelines they place JSPs directly in the web root. Though many people feel they belong under a jsp directory.

Personally I think it would be nice to be able to specify a URL mapping for the directories, e.g., /web/WEB-INF/jsp should be considered as a root URL along with with /web.

0
Comment actions Permalink

yes. i'm not looking for a debate on the validity of the practice just for support by the tool, as some of us in consulting or corporate development don't have control over project structures.

i do remember way back there were app servers that didn't follow the specs that led to people putting JSPs under WEB-INF... but it doesn't really matter where, some people just like to organize them into directories even though at runtime they will all be rendered at the root.

0
Avatar
Nikolay Chashnikov
Comment actions Permalink

Hello Charles,

Currently IDEA uses web resource mappings for both reference resolving and
packaging JSPs to war-file or exploded directory. In your case the mapping
from "/web/WEB-INF/jsp" to "/" must be used only for refernce resolving but
not for packaging. We won't introduce such mappings in IDEA 7 but perhaps
it will be implemented in next version.

Placing JSP's under the WEB-INF is one of the conventions used in web
development. This seems to stem from the days when bugs in
application servers made it possible to serve up the content of a JSP
without executing it. Those days are long since past so people tend
to use that convention now either out of habit or out of the misguided
sense that it adds security.

If you check Sun's guidelines they place JSPs directly in the web
root. Though many people feel they belong under a jsp directory.

Personally I think it would be nice to be able to specify a URL
mapping for the directories, e.g., /web/WEB-INF/jsp should be
considered as a root URL along with with /web.



0
Comment actions Permalink

Has someone created a JIRA issue for this? I haven't found one, but would be interested in watching it.

0

Please sign in to leave a comment.