From: Przemek M. Zawada on
Dear Friends,

Regarding to my last problems, I have few new problems, which I have no
idea how to manage them.

1. I've followed the NetBeans tutorial, which I've found here:
http://netbeans.org/kb/docs/javaee/ecommerce/intro.html (pretty nice
tutorial anyway - I recommend it!)

// I've build the website environment as described in the tutorial - all
works perfect!

2. I've created the *.jspf files including header and footer files as
described in tutorial, with web.xml annotations, as following:

<jsp-config>
<jsp-property-group>
<description>Header and footer settings.</description>
<url-pattern>/index.jsp</url-pattern>
<url-pattern>/WEB-INF/view/*</url-pattern>
<include-prelude>/WEB-INF/jspf/header.jspf</include-prelude>
<include-coda>/WEB-INF/jspf/footer.jspf</include-coda>
</jsp-property-group>
</jsp-config>

3. I've create a control servlet, named "UserControl", which is also
managed in the web.xml file:

<servlet>
<servlet-name>UserControl</servlet-name>
<servlet-class>User.UserControl</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>UserControl</servlet-name>
<url-pattern>/userBrowse</url-pattern>
</servlet-mapping>
(...)

4. The servlet is designed/created as tips suggested in the tutorial. In
the doGet() method, I've used suggested code:

String url = "/WEB-INF/view" + userPrefix + userPath + ".jsp";

try {
request.getRequestDispatcher(url).forward(request, response);
} catch (Exception ex) {
System.err.println("UserControl.doGet(): " + ex.getMessage());
}

Everything works fine, BUT I have problem. In example, each of sub-pages
should have dynamic elements - regarding to such schema:

[ ]
[ header.jspf ] (each time included, static)
[ ]
-------------------
[ included ]
[ page ] (non-static elements)
-------------------
[ ]
[ footer.jspf ] (each time included, static)
[ ]

What if, in the included page, I'd like to add dynamic elements (kind of
menu with subitems)?
Shall I use the <jsp:include/> with forwarded parameters (if required) ?
Shall I define and manage it somehow in the servlet-side part?

I would not like to copy&paste in each servlet-included jsp file my
different (sometimes) nor same (sometimes, too) menu elements. I'd like
to auto-manage it somehow.

What I was thinking is to generate each servlet (managing each of my
page-plugins) XML config file, which contains menu-tree, which is
parsed/displayed regarding to URL parameters (in range of servlet mappings).

Sorry if I'm still thinking in PHP-way, but I'm trying to do my best ;)

Thank you for your help.

All the best,
Przemek M. Zawada
From: Przemek M. Zawada on
[Continue]

Regarding to my problem, while I've done some tests, I have jsp:include
problem - I'm not able to access the WEB-INF directory (even if I
include "/WEB-INF/view/Menu/User/browse.jsp" it does not treat is as
absolute path, it adds some annoying parent directories for current
file), where I have the *.jspf files (with my menus), nevertheless I
cannot store my menu files in the /WEB-INF/view/* directory, because I
automatically add the footer&header pre and suffixes - as configured in
web.xml file.

I thought about <c:import/>, but it works over URL, as I suppose, so I
also do not think is a good idea.

Damn, I'm stuck.

All the best,
Przemek M. Zawada
From: Simon Brooke on
On Sun, 01 Aug 2010 19:49:12 +0200, Przemek M. Zawada wrote:

> [Continue]
>
> Regarding to my problem, while I've done some tests, I have jsp:include
> problem - I'm not able to access the WEB-INF directory (even if I
> include "/WEB-INF/view/Menu/User/browse.jsp" it does not treat is as
> absolute path, it adds some annoying parent directories for current
> file), where I have the *.jspf files (with my menus), nevertheless I
> cannot store my menu files in the /WEB-INF/view/* directory, because I
> automatically add the footer&header pre and suffixes - as configured in
> web.xml file.
>
> I thought about <c:import/>, but it works over URL, as I suppose, so I
> also do not think is a good idea.
>
> Damn, I'm stuck.
>
> All the best,

No, this is intentional. The servlet container intentionally will not
serve anything within the WEB-INF directory - obviously, because if a
hacker could get hold of, e.g., your web.xml it would be very easy to
compromise your site.

Content which you wish to serve cannot and must not be stored in WEB-INF.

--

;; Semper in faecibus sumus, sole profundam variat

From: Lew on
Simon Brooke wrote:
> The servlet container intentionally will not
> serve anything within the WEB-INF directory - obviously, because if a
> hacker could get hold of, e.g., your web.xml it would be very easy to
> compromise your site.
>

It will not *directly* serve the contents of the WEB-INF/ directory
tree, that is, it will not respond to a client-side request for
resources so protected. The container will deliver content from the
WEB-INF/ tree if the server-side artifacts include it, e.g., through a
<jsp:include> action.

It is standard to put JSP fragments (.jspf files), images and other
resources, configuration files and such under the WEB-INF/ hierarchy.

> Content which you wish to serve cannot and must not be stored in WEB-INF.
>

That is, unless you plan to incorporate it through server-side
actions, in which case it's a best practice to store things in the WEB-
INF/ tree that you don't want accessed directly from the client, but
do want to serve indirectly.

--
Lew

From: Arne Vajhøj on
On 03-08-2010 18:33, Lew wrote:
> Simon Brooke wrote:
>> The servlet container intentionally will not
>> serve anything within the WEB-INF directory - obviously, because if a
>> hacker could get hold of, e.g., your web.xml it would be very easy to
>> compromise your site.
>
> It will not *directly* serve the contents of the WEB-INF/ directory
> tree, that is, it will not respond to a client-side request for
> resources so protected. The container will deliver content from the
> WEB-INF/ tree if the server-side artifacts include it, e.g., through a
> <jsp:include> action.
>
> It is standard to put JSP fragments (.jspf files), images and other
> resources, configuration files and such under the WEB-INF/ hierarchy.
>
>> Content which you wish to serve cannot and must not be stored in WEB-INF.
>
> That is, unless you plan to incorporate it through server-side
> actions, in which case it's a best practice to store things in the WEB-
> INF/ tree that you don't want accessed directly from the client, but
> do want to serve indirectly.

All this was BTW mentioned in PMZ's previous thread.

Arne