RE: servlet context availability to non-servlet classes?

Ok, I think this can be solved more cleanly.... at least in my case, and it 
won't require any access to the ServletContext of the running 
application.  However, it also means that XMLCContext is still not really 
useable with Barrauda, but what I just thought of mostly negates its need 
and works within the framework without any real changes.  I should have 
though of it before.

What I can do is use the event gateway.  I've already got the following in 
event-gateway.xml...

<dom-loader 
factory="org.enhydra.barracuda.core.util.dom.XMLCDeferredParsingDOMFactory" />

What I can do is add...

<dom-loader 
factory="org.enhydra.barracuda.core.util.dom.XMLCDeferredParsingDOMFactory">
     <set-property 
name="reparseDirs">C:\some\arbitrary\directory\with\xmlc\templates</set-property>
     ...
     ...
</dom-loader-factory>

The only problem with this is that it isn't overrideable via a J2EE server 
APIs.  What I mean is that I can't do something like this in Tomcat...

<Context ...>
     <Parameter name="reparseDirs" 
value="C:\some\arbitrary\directory\with\xmlc\templates" override="true"/>
</Context>

If I was able to do that, then at deployment time, this could be set in an 
external context configuration file by the server admin and I wouldn't have 
to change anything in my code or in configuration files inside the .war 
such as event-gateway.xml.

The other problem I have to figure out is how to utilize deferred parsing's 
ability to load .html template directly from file instead of loading a 
pre-compiled class as the DOMFactory#getInstance(Class) forces me to do 
currently.  I'd like to be able to send in a file name (which deferred 
parsing would look for within the "resourceDirs" that it was given).

Hmm......  I guess that brings me full circle to being able to access the 
ServletContext of the app at runtime so I can use XMLCContext.  But...

1.  How should this be done?
2.  How would a DOMFactory pick this up?  Would it even be clean to access 
a ServletContext object when the DOMFactory interface makes no assumptions, 
currently, about running within a servlet container?  Do we need to extend 
the DOM loading architecture in Barracuda to be servlet api aware in general?
3.  Or is this just out-of-scope for Barracuda?  I hope not.

hmmmmm......


Jake

At 03:36 PM 5/27/2003 -0500, you wrote:

>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