What to put in web.xml or cactus-web.xml, and what not.

[Pedro Nevado <pn...@javato.com>]

Hi there,

As a Cactus' beginner, I find intriguing things that probably are not.

For instance, in the examples in jakarta-cactus-13-1.6.1\samples\servlet:
- the test.jsp used to assert a dispatch-forward is referenced in the
(cactus-)web.xml.
- the SampleServlet which defines the dispatch is not defined in either of
the two deployment descriptors.

However, if we have a look at the example in the JUnit in Action book
(servlet example of chapter 9), the opposite happens:
- the securityError.jsp used in a (SecurityFilter) dispatch-forward is not
included in the deployment descriptors.
- the AdminServlet is included in the web.xml file. BTW, the SecurityFilter
is not included.

My question is: does it matter what is included in the deployment
descriptors?

This is my guess:

- test.jsp should be included in the deployment descriptor because it is not
in the context root directory. For the same reason, securityError.jsp could
not be included, because it is in the context root.
- since the instances of the servlets and filters used in the tests are
plain Java objects, it is irrelevant if they are included, so AdminServlet
could be excluded of the web.xml.

Any more guesses?
Regards,

Pedro Nevado

RE: What to put in web.xml or cactus-web.xml, and what not.

[Vincent Massol <vm...@pivolis.com>]

> -----Original Message-----
> From: Pedro Nevado [mailto:pnevado@javato.com]
> Sent: jeudi 9 septembre 2004 16:54
> To: Cactus Users List
> Subject: RE: What to put in web.xml or cactus-web.xml, and what not.
> 
> Allow me to elaborate futher my previous e-mail.
> I know that in a production simulated environment, you must put every
> (non-test)component in your web.xml. The point of my e-mail is about the
> relevance of the web.xml in an only test environment.
> 
> From that point of view, the only thing we need is a deployment descriptor
> file with the three redirector components. No need for anything else; it
> is
> enough with precise path references to the jsp's to use and the classes to
> test in the classpath.
> Sorry for the verbosity.

Yes, this should be enough.

Thanks
-Vincent

PS: Sorry for the delay in the answer...

> 
> -----Mensaje original-----
> De: Pedro Nevado [mailto:pnevado@javato.com]
> Enviado el: jueves, 09 de septiembre de 2004 16:24
> Para: cactus-user@jakarta.apache.org
> Asunto: What to put in web.xml or cactus-web.xml, and what not.
> 
> 
> Hi there,
> 
> As a Cactus' beginner, I find      intriguingthingsthatprobablyarenot.
> 
> For instance, in the examples in jakarta-cactus-13-1.6.1\samples\servlet:
> - the test.jsp used to assert a dispatch-forward is referenced in the
> (cactus-)web.xml.
> - the SampleServlet which defines the dispatch is not defined in either of
> the two deployment descriptors.
> 
> However, if we have a look at the example in the JUnit in Action book
> (servlet example of chapter 9), the opposite happens:
> - the securityError.jsp used in a (SecurityFilter) dispatch-forward is not
> included in the deployment descriptors.
> - the AdminServlet is included in the web.xml file. BTW, the
> SecurityFilter
> is not included.
> 
> My question is: does it matter what is included in the deployment
> descriptors?
> 
> This is my guess:
> 
> - test.jsp should be included in the deployment descriptor because it is
> not
> in the context root directory. For the same reason, securityError.jsp
> could
> not be included, because it is in the context root.
> - since the instances of the servlets and filters used in the tests are
> plain Java objects, it is irrelevant if they are included, so AdminServlet
> could be excluded of the web.xml.
> 
> Any more guesses?
> Regards,
> 
> Pedro Nevado
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cactus-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: cactus-user-help@jakarta.apache.org
> 
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cactus-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: cactus-user-help@jakarta.apache.org

RE: What to put in web.xml or cactus-web.xml, and what not.

[Pedro Nevado <pn...@javato.com>]

Allow me to elaborate futher my previous e-mail.
I know that in a production simulated environment, you must put every
(non-test)component in your web.xml. The point of my e-mail is about the
relevance of the web.xml in an only test environment.

RE: What to put in web.xml or cactus-web.xml, and what not.

[Vincent Massol <vm...@pivolis.com>]

Hi Pedro,

> -----Original Message-----
> From: Pedro Nevado [mailto:pnevado@javato.com]
> Sent: jeudi 9 septembre 2004 16:24
> To: cactus-user@jakarta.apache.org
> Subject: What to put in web.xml or cactus-web.xml, and what not.
> 
> Hi there,
> 
> As a Cactus' beginner, I find      intriguingthingsthatprobablyarenot.
> 
> For instance, in the examples in jakarta-cactus-13-1.6.1\samples\servlet:
> - the test.jsp used to assert a dispatch-forward is referenced in the
> (cactus-)web.xml.
> - the SampleServlet which defines the dispatch is not defined in either of
> the two deployment descriptors.
> 
> However, if we have a look at the example in the JUnit in Action book
> (servlet example of chapter 9), the opposite happens:
> - the securityError.jsp used in a (SecurityFilter) dispatch-forward is not
> included in the deployment descriptors.
> - the AdminServlet is included in the web.xml file. BTW, the
> SecurityFilter
> is not included.
> 
> My question is: does it matter what is included in the deployment
> descriptors?
> 
> This is my guess:
> 
> - test.jsp should be included in the deployment descriptor because it is
> not
> in the context root directory. For the same reason, securityError.jsp
> could
> not be included, because it is in the context root.
> - since the instances of the servlets and filters used in the tests are
> plain Java objects, it is irrelevant if they are included, so AdminServlet
> could be excluded of the web.xml.

This is the Servlet spec and Cactus is abiding by it. In the spec, JSP
resources do not have to be defined in the web.xml file. They can be, which
is useful if you wish to provide a special mapping for JSPs but that's up to
you. OTOH Servlets *must* be present in web.xml so that mappings can be
defined for them (they have no default mappings).

Hope it helps,
-Vincent