I am designing my new apps using the mapping approach (actually, I'm using a
    design pattern that funnels all of the action requests through a single
    servlet for the entire context so that I can centralize access control and so
    on), but I leave the invoker set to "true" in my development environment so I

precisely the conclusion i came to back when. very powerful. to this base
HttpServlet i then linked in some singletons for db connections and the like,
a "property manager" for runtime re-configuration management, a "form
manager" to control the various form elements (this served as the cusp of the
view-control seperation of the mvc pattern), an "action manager" to manage
the get/post transactions (which is in essence the model of mvc), etc. this
seperation (factoring out and pushing down core funcationality) allowed for
various team members to work fairly automously ... and have a bit'o fun along
the way.

- james


"Craig R. McClanahan" wrote:

> pascal jacob wrote:
>
> > > I have not tried this, but see what happens with:
> > >     http://localhost:8080/servlet/snoop
> > >
> > I can tell you it works, because it is what I've always used.
> >
> > > (in other words, use the alias instead of the class name).  However,
> > > because it is so easy to map a URI prefix, or a filename extension, to a
> > > servlet in the mappings.properties file, I cannot see much need for this
> > > even if it works.
> > >
> > > The gadget that responds to the "/servlet" URI and loads anonymous
> > > servlets is often called the "invoker" in servlet engine circles.  Some
> > > environments might consider the ability to do this a security risk, so
> > > the JSDK servlet engine lets you turn it off by setting "invoker=false"
> > > in the webapp.properties file for the servlet context you are running in.
> >
> > Now I'm perplex!
> >
> > Does it means that I should define an mapping-name (in the
> > mappings.properties file) instead of using the alias defined in the
> > "servlets.properties" file when invoking my servlets ?
> >
> > Here is two URLs that I use in my HTML files ("/ephone" is the context for
> > my web-app):
> > <FORM ACTION="/ephone/servlet/controlpanel?form=header" METHOD=POST>
> > <A HREF="/ephone/servlet/logout">logout</A>
> >
> > Those URL invoke my servlets by the name defined in the
> > "servlets.properties" file - the alias as I undertand you.
> > (Here is the servlets.properties file:
> > controlpanel=com.mycompagnie.ephone.ControlPanelServlet
> > logout= com.mycompagnie.ephone.LogoutServlet)
> >
> > should I provide a mapping in the "mappings.properties" file
> > like:
> > /cp= controlpanel
> > /logout=logout
> >
> > and transform the URLs to:
> > <FORM ACTION="/ephone/cp?form=header" METHOD=POST>
> > <A HREF="/ephone/logout">logout</A>
> >
> > And turn the Invoker off ?
> >
> > Thank you for your patience Craig.
> >
> > ZartC++
> >
>
> Which approach to take is a choice, not a requirement.  You can use either
> approach, or combine them.
>
> The "invoker" approach has been historically supported, and makes life easier
> if you are converting older apps to 2.1.  It also gives you the flexibility to
> introduce new servlets that you haven't put in the configuration files.  One
> cautionary note -- the name, ane even the existence, of the "invoker" servlet
> (typically /servlet) is not currently mandated in the spec, so at the moment
> you are not guaranteed of consistency across engines.  However, it seems to be
> pretty widely implemented.
>
> The mapping approach lets you construct more readable URLs (if you care), but
> more importantly gives you slightly better security -- *only* the servlets you
> have configured in this context can be executed.  Also, based on the
> clarifications in Appendix B of the JSP spec, you can count on servlet engines
> implementing both URI mapping and extension mapping this way.
>
> I am designing my new apps using the mapping approach (actually, I'm using a
> design pattern that funnels all of the action requests through a single
> servlet for the entire context so that I can centralize access control and so
> on), but I leave the invoker set to "true" in my development environment so I
> can randomly call a session or snoop type servlet during debugging.  In
> production, though, the invoker will be turned off.
>
> Craig
>
> ___________________________________________________________________________
> To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
> of the message "signoff SERVLET-INTEREST".
>
> Archives: http://archives.java.sun.com/archives/servlet-interest.html
> Resources: http://java.sun.com/products/servlet/external-resources.html
> LISTSERV Help: http://www.lsoft.com/manuals/user/user.html

___________________________________________________________________________
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff SERVLET-INTEREST".

Archives: http://archives.java.sun.com/archives/servlet-interest.html
Resources: http://java.sun.com/products/servlet/external-resources.html
LISTSERV Help: http://www.lsoft.com/manuals/user/user.html

Reply via email to