RE: servlet context availability to non-servlet classes?

"Christian Cryder" <[email protected]>
Newsgroups gmane.comp.java.enhydra.barracuda.general
Message-ID <[email protected]>
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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.