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

At 12:02 PM 6/19/2003 -0600, you wrote:
> >  So, it is the "factory" class we are configuring, not the
> > "class" class of the <dom-loader>.
>
>Ok, so if I understand correctly, the bottom line of all this is that your
>factory class needs to be able to get access to the ServletConfig object, is
>this correct?
>
>What if all you had to do in your factory class was this:
>
>     ObjectRepository lor = ObjectRepository.getLocalRepository();
>     ServletConfig sc = (ServletConfig)
>lor.get(ServletConfig.class.getName());
>
>It seems to me that the cleanest way to solve your problem is simply to
>
>a) use ObjectRepositoryAssembler to configure a static var that will
>determine which specific implementation gets used (thereby achieving the
>desired pluggability)

Well, it is more than just the default implementation.  It is also specific 
implementations per/DOM class (if desired).  And this is all per DOMLoader 
instance with the global loader storing the default instance which is 
obtained via getGlobalInstance().

>b) modify ComponentGateway and ApplicationGateway to store references to
>servlet specific objects (ServletConfig, HttpServletRequest,
>HttpServletResponse) in the local repository (using their class names as
>keys), which makes it possible for any downline classes to access and
>utilize them without having to know anything about ComponentGateway,
>ApplicationGateway, etc.
>
>Thoughts?

I suppose this could be done, but that means that a servlet would have had 
to set up the object repository.  This is easy to guarantee in the 
framework, but what about the example that I just showed where a Barracuda 
DOMLoader+DOMFactory does the equivalent job of XMLCContext in a demo that 
knows nothing about Barracuda except for the two classes I was using from 
Barracuda?  I was able to set the servlet context to 
setServletContext(Servletcontext) because I had it available 
already.  Seems like setting up an object repository in that case would be 
a bit of overkill.

Hmm....  the object repository can solve some things, but for some reason 
I'm a bit uncomfortable with it in this situation.  The assumption I make 
in the DOMFactory is that one is able to call 
setServletContext(ServletContext) if they want to.  The configuration side 
with the concept of a "delegate runtime value" is just a way to be able to 
call this method as if it was being done programatically by user defined 
code so that the DOMFactory really don't have any knowledge about where it 
might get the ServletContext object from.  Once it has it, it uses it.  If 
it doesn't have it, it doesn't use it.  It is optional.

There are lots of cases where the object repository seems like a good way 
to go.  I'm just not convinced if this is one of those cases.  I think 
adding the concept of the "delegate runtime value" to the the configuration 
side of the object repository (just like the ApplicationAssembler supports) 
without necessarily storing the value in the object repository would be a 
nice alternative feature.  People can choose whatever method makes sense to 
them for their own code.

Your thoughts?

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: [email protected]
> > [mailto:[email protected]]On Behalf Of Jacob Kjome
> > Sent: Thursday, June 19, 2003 10:55 AM
> > To: [email protected]
> > Subject: Re: [Barracuda] 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.XMLCDeferredParsingDO
> > MFactory">
> >         <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\r
> > es\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
>
>_______________________________________________
>Barracuda mailing list
>[email protected]
>http://barracudamvc.org/lists/listinfo/barracuda