Re: RE: [Barracuda-commit] CVS Update: Barracuda

Hi Christian,

At 09:19 AM 6/19/2003 -0600, you wrote:
>Hi Jake!
>
>I read your description of what you did, but I'm still a bit confused...
>
> > concept of a "delegate runtime value". What this means is that
> > the value of the parameter to be set is a runtime object rather
> > than something that can be provided as a literal value in the
> > configuration file. Currently, the only supported delegate
>
>Do you mean by this that all you are doing is invoking a method on an
>object? (rather than setting a static variable?)

yes

>Looking at your example in the Barracuda event-gateway.xml file, I see this:
>
>     <dom-loader
>factory="org.enhydra.barracuda.core.util.dom.XMLCDeferredParsingDOMFactory">
>         <set-property name="servletContext" delegateRuntimeValue="true" />
>     </dom-loader>
>
>What exactly is this doing (ie. in terms of psuedo-code)? I'm guessing it
>involves instantiating the XMLCDeferredParsingDOMFactory and then calling
>setServletContext() on it, but I'm probably wrong about some of the
>specifics.

That's just about exactly right.  Of course, optionally, a DOMLoader class 
can be specified to store the DOMFactory instance, but the DefaultDOMLoader 
is used by default.  Since DOMLoaders store a single instance of a 
DOMFactory, creating a single DOMFactory object, configuring it, and 
storing it in the DOMLoader works perfectly.

>To step back a level, what is the high level objective of this? It looks
>like you are trying to
>a) specify a pluggable implementation of the DOMLoader

Well, yes, but more to the point, pluggable DOMFactory implementations to a 
specified DOMLoader of which the DefaultDOMLoader is used if on does not 
specify one using the "class" attribute of the <dom-loader> element.  The 
DOMLoader must have defined a public static getGlobalInstance() method.  I 
would have defined that in the DOMLoader interface, but static methods 
can't be defined in interfaces.  The DefaultApplicationAssembler simply 
throws a SAXException in this case.

So, once the implementation of the DOMLoader has been created and its 
global loader defined (returned by getGlobalInstance()), we can instantiate 
a DOMFactory and set it as the default dom factory of the global 
loader.  So, we are setting the servlet context object to the DOMFactory in 
this case, not the DOMLoader.  So, it is the "factory" class we are 
configuring, not the "class" class of the <dom-loader>.

>b) make it possible for that DOMLoader to get a reference to the servlet
>context

Like I said above, it is the DOMFactory that gets the reference to the 
servlet.  The DOMLoader is pretty stupid.  It is the DOMFactory that has 
all the knowledge about loading DOM documents from class or from file so 
that is what requires the reference to the servlet context.

>Can you confirm/correct my understanding of that? If I understand it
>correctly, then I think there may be an easier way to do this, but I'll wait
>to hear from you first before commenting further...

Sure, I'd like to hear it.  Note that the reason the servlet context is 
being stored is to be able to obtain configuration from web.xml just like 
XMLC's XMLCContext does.  In fact, XMLCContext and a DOMLoader + DOMFactory 
implementation are totally interchangeable.

Here is the setup of XMLCContext.....
         XMLCContext context = XMLCContext.getContext(this);
         XMLCFactory factory = context.getXMLCFactory();
         ....
         ....
         Document doc1 = factory.create(docClass);
         //or
         Document doc2 = 
((XMLCDeferredParsingFactory)factory).createFromFile(docFile); //might get 
exception if cast fails

And here is the equivalent setup of a DOMLoader + DOMFactory....
         DOMLoader loader = DefaultDOMLoader.getGlobalInstance();
         XMLCDeferredParsingDOMFactory lfactory = new 
XMLCDeferredParsingDOMFactory();
         lfactory.setServletContext(this.getServletContext());
         loader.setDefaultDOMFactory(lfactory);
         ....
         ....
         Document doc1 = loader.getDOM(docClass);
         //or
         Document doc2 = loader.getDOMFromFile(doc); //might get exception 
if underlying dom factory doesn't support loading from file


All the configuration for the above is done using <context-param> entries 
in web.xml.  For instance....

   <context-param>
     <param-name>xmlcReparseResourceDirs</param-name>
     <param-value>D:\xmlc\examples\tomcat\res;D:\xmlc\examples\tomcat\res\pkg</param-value>
   </context-param>
   <context-param>
     <param-name>xmlcReparsePackagePrefixes</param-name>
     <param-value>xmlc</param-value>
   </context-param>
   <context-param>
     <param-name>xmlcReparseDefaultMetaDataPath</param-name>
     <param-value>options.xmlc</param-value>
   </context-param>

XMLCContext supports a few more options, but these are either redundant or 
irrelevant to Barracuda's config requirements.  I've attached a couple 
examples taken from XMLC's tomcat example app and modified one to use 
Barracuda for dom loading just as I've described above.

Note that in the case above I was able to directly set up the 
XMLCDeferredParsingDOMFactory with the servlet context.  However, given 
that I really don't have access to the servlet context at runtime, and 
given that I shouldn't I need to do this programmatically since that would 
tie my code to a specific DOMFactory implementation, the assembler 
configuration with the "delegate runtime value" functionality is required.

Jake

>Christian
>----------------------------------------------
>Christian Cryder
>Internet Architect, ATMReports.com
>Project Chair, BarracudaMVC - http://barracudamvc.org
>----------------------------------------------
>"Coffee? I could quit anytime, just not today"
>
>
> > -----Original Message-----
> > From: Jacob Kjome [mailto:[email protected]]
> > Sent: Wednesday, June 18, 2003 10:37 PM
> > To: Christian Cryder
> > Subject: Re: [Barracuda-commit] CVS Update: Barracuda
> >
> >
> > Hi Christian,
> >
> >
> >
> > Log message:
> >         <b>csc_061803.1</b> - Modified ObjectRepositoryAssembler
> > to support the setting of
> >         Shorts, Longs, Doubles and Floats in addition to the
> > String, Boolean, and Integer
> >         support that was already there. While I was at it I
> > discovered that the previous
> >         implementation only supported the setting of primitives,
> > so I modified things so that
> >         you can set both primitives and their first class counterparts.
> >
> >
> >
> > Might we want to add the notion of the "delegate runtime value"
> > which I added to the DefaultApplicationAssembler?  Here is my
> > comment from A_Changes_History about that....
> >
> > <quote>
> > jrk_20030529.1 - Updated handling of <set-property> and
> > <constant> in DefaultApplicationAssembler to recognize the
> > concept of a "delegate runtime value". What this means is that
> > the value of the parameter to be set is a runtime object rather
> > than something that can be provided as a literal value in the
> > configuration file. Currently, the only supported delegate
> > runtime value is a ServletContext object. The syntax of this new
> > configuration option is...
> >
> >
> >    <set-property name="servletContext"
> > delegateRuntimeValue="true"/>
> >
> >
> >
> > Obviously this assumes that the class this property is to act
> > upon have either a public "setServletContext()" method or a
> > public "servletContext" field.
> >
> > Also updated XMLCDeferredParsingDOMFactory to take advantage of
> > this feature, the reason being that it needs to read context init
> > parameters to provide extra optional information to the
> > DeferredParsingFactory which the DeferredParsingDOMFactory backs.
> > Also modified it to create the DeferredParsingFactory once
> > instead of every time DOMFactory#getInstance() is called. This
> > should provide a slight performance improvement.
> > </quote>
> >
> >
> > So, this just says "I, the configuration file writer, delegate
> > the responsibility of the setting of a runtime object to a method
> > that I specify because I cannot possibly script this value in a
> > configuration file."
> >
> > does that make sense?  Of course, only certain specified
> > "delegate runtime values" would be supported, but you can look at
> > DefaultApplicationAssembler to see how I implemented this for
> > methods taking the current runtime ServletContext object.  It
> > works perfectly and allowed me to duplicate the web.xml
> > configuration functionality of XMLCContext in the
> > XMLCDeferredParsingDOMFactory.
> >
> >
> > Jake
>
>_______________________________________________
>Barracuda mailing list
>[email protected]
>http://barracudamvc.org/lists/listinfo/barracuda