RE: servlet context availability to non-servlet classes?

Hi Christian,

Actually, no.  I don't need any access to a request object nor am I 
currently proposing a way to create manually.  I literally need access to 
the ServletContext object.  There are a couple ways to do this.  One is 
directly via the HttpServlet.getServletContext().  Another is also 
available via the HttpRequest object (actually via the ServletConfig 
object) via this.getServletConfig().getServletContext().  One can also get 
this via a ServletContextListener, but that is servlet-2.3 specific.

The place where I'd need it is, for instance, in a DOMFactory.  For 
instance, the XMLCDeferredParsingDOMFactory.  My problem is being able to 
add information to the XMLCDeferredParsingFactory object which is used to 
generate the Document returned document from the 
XMLCDeferredParsingDOMFactory#getInstance() method.  XMLC's deferred 
parsing supports adding resource paths to file system locations where html 
templates exist.  Additionally, deferred parsing is able to load html 
templates directly rather than requiring one to pre-compile html templates 
to XMLC classes which requires the ability to provide the resource 
paths.  Currently, deferred parsing is only working in Barracuda by loading 
an XMLC class and copying the .xmlc files and .html files associated with 
that class to the class's location.  This is very limiting.  If I had 
access to the ServletContext from the XMLCDeferredParsingDOMFactory, I 
could use XMLCContext to load up an XMLCFactory with all the resource paths 
configured via the web.xml.  This would make the full feature set of 
deferred parsing available in Barracuda.

Hopefully that is enough info.  Have to head out on an errand.  Back later 
tonight.

Jake

At 01:47 PM 5/27/2003 -0600, you wrote:
>Hi Jake,
>
>I'm not sure if this is exactly what you're talking about, but we face this
>same issue in that many of our classes are meant to be run outside of the
>servlet context (ie. directly). In some cases they even need to be able to
>support both (being run as a servlet, and directly as an app).
>
>We handle this by doing the following...
>
>     public static void main(String[] args) {
>         try {
>             //manually configure the log4j stuff
>             DOMConfigurator.configure("../log4j.xml");
>
>             //setup the object repository
>             AppUtil.setupObjectRepository();
>
>             //now backup the data
>             new Foo().doSomething();
>         } catch (Exception e) {
>             System.out.println("Unexpected Exception: "+e);
>             e.printStackTrace();
>         }
>     }
>
>So if the code is being run within Tomcat, this stuff occurs by default via
>Barracuda. But if its being run directly in standalone mode, this gives us
>access to logging, datasources, etc, exactly as if we were running in the
>servlet context. Plus, the code being invoked can make full use of the
>object repositories from the ObjectRepository class.
>
>The one thing this approach DOESN'T handle is getting stuff out of the http
>request (because there is no http request). But we haven't really had a need
>to solve that particular limitation yet.
>
>So it sounds like what you are proposing is that we find a way to address
>this, by making it possible to a) create/configure a servlet request apart
>manually, and b) access that info without actually having a reference to the
>HttpRequest object...is that correct? I would definitely be interested in
>considering how best to make this happen...
>
>Christian
>
>----------------------------------------------
>Christian Cryder [[email protected]]
>Internet Architect, ATMReports.com
>Barracuda - http://barracudamvc.org
>----------------------------------------------
>"Coffee? I could quit anytime, just not today"
>
> > -----Original Message-----
> > From: [email protected]
> > [mailto:[email protected]]On Behalf Of Jacob Kjome
> > Sent: Tuesday, May 27, 2003 1:22 PM
> > To: BarracudaMVC Users List
> > Subject: [Barracuda] servlet context availability to non-servlet
> > classes?
> >
> >
> >
> > When using a servlet MVC framework, most of the classes one
> > directly deals
> > with have very little to do with servlets since that is really taken care
> > of behind the scenes.  However, I wonder if we shouldn't provide static
> > access to something so fundamental as the ServletContext object or maybe
> > even the ServletConig object of the ApplicationGateway?
> >
> > One way this would be beneficial is that it would allow for use of the
> > XMLCContext object which provides a very convenient way to both configure
> > XMLC via the web.xml and get an XMLCFactory object which is all
> > set up with
> > this provided configuration.  Currently, the XMLCContext can only be used
> > directly from a class which extends HttpServlet.  This makes it less than
> > useable under Barracuda.
> >
> > Would there be any danger in doing this?  Is there another way to provide
> > this that might be better/safer?  Is there anyone else who thinks they
> > might need this, or do people not see this as much of an issue?
> >
> >
> > Note that the above stuff about XMLCContext is not currently true since
> > XMLCContext requires a call to
> > XMLCContext.getContext(HttpServlet).  However, I plan to add a
> > method which
> > would be XMLCContext.getContext(ServletContext).  This makes sense since
> > the only real reason the instance of the HttpServlet is needed for is
> > access to the ServletContext via getServletContext().  I still have some
> > investigation to do on this, though.
> >
> >
> > Jake
> >
> > _______________________________________________
> > Barracuda mailing list
> > [email protected]
> > http://barracudamvc.org/lists/listinfo/barracuda
>
>_______________________________________________
>Barracuda mailing list
>[email protected]
>http://barracudamvc.org/lists/listinfo/barracuda