RE: Barracuda and using Servlet 2.3 features?

Hi Christian,

I didn't touch ObjectRepositoryAssembler, only DefaultApplicationAssembler.

Jake

At 12:36 PM 4/16/2003 -0400, you wrote:
>Hi Jake,
>
>I haven't actually looked at the changes you've made, but I did want to
>mention that I just committed a change to this class, before I realized you
>had been working in it. Shouldn't be a problem to integrate though...just
>search for csc_041603.2 and you'll see what I touched.
>
>Basically, here's what I did...
>--------------------------------
><b>csc_041603.2</b> - Added logic to ObjectRepositoryAssembler so that you
>can
>get it to continue assembling a file even if errors are encountered. This is
>useful
>because it allows your assembler file to specify things which may not always
>be there
>(depending on your deploy configuration). Of course, if those things aren't
>there,
>then subsequent assembly may not work either, so use with caution...
>
>To take advantage of this functionality, you can either specify a startup
>parameter
>in the GlobalRepositoryAssembler section of web.xml, like this:
>
><pre>
>    <init-param>
>      <param-name>LogHeartbeat</param-name>
>      <param-value>true</param-value>
>    </init-param>
><pre>
>
>or, you can specify it within the object-repository.xml file itself, like
>this:
>
><pre>
>    <object
>class="org.enhydra.barracuda.plankton.data.ObjectRepositoryAssembler">
>      <prop name="globalContinueOnErr">true</prop>
>    </object>
></pre>
>
>or, you can specify it on a per-line item in object-repository.xml, like
>this:
>
><pre>
>    <object name="$cts" class="com.atmr.kilimanjaro.CodeTables"
>continue_on_err="true" />
></pre>
>
>Note that the default remains false, so this should not affect any existing
>code
>at all...you have to explicitly turn this behavior on if you want it.
>
>----------------------------------------------
>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: Wednesday, April 16, 2003 12:48 AM
>To: [email protected]
>Subject: Re: [Barracuda] Barracuda and using Servlet 2.3 features?
>
>
>
>(see attached zip file for new DefaultApplicationAssembler to test out!)
>
>Ok, I broke down and used reflection.  Since people, thus far, are used to
>specifying a single application assembler file I figure that this is not a
>critical feature that mandates all of Barracuda moving to servlet 2.3.  If
>we, however, decided that the event model would start using filters or
>something like that, then that would be more of a reason to say that
>Barracuda, as a whole, should require servlet 2.3.
>
>So, those with servlet 2.2 engines must specify the whole relative
>path+filename of the assembler file such as...
>
>/WEB-INF/event-gateway.xml
>
>Those with servlet 2.3+ engines may do any one of the following....
>
>/WEB-INF/event-gateway.xml      //load single file as named (same as servlet
>2.2 behavior)
>/WEB-INF/assemblerFiles/          //load all files in assemblerFiles
>directory ending with ".xml" (note the ending "/")
>/WEB-INF/event                           //load all files in WEB-INF
>directory starting with "event" and ending with ".xml"
>/WEB-INF/event*way.xml            //load all files in WEB-INF directory
>starting with "event" and ending with "way.xml"
>
>I wrote up some Javadoc that may or may not be totally accurate/complete.
>Someone (Christian?) might want to look at what I started and add to it
>(once I check this into CVS or modify this version's javadoc and send it
>back to me so I can check it in).
>
>I also added some other functionality.  One can now set the DOMFactiory for
>the DefaultDOMLoader via the assembler file.  For instance....
>
><!-- sets default dom factory for the DefaultDOMLoader -->
><dom-loader
>factory="org.enhydra.barracuda.core.util.dom.XMLCDeferredParsingDOMFactory"
>/>
>
>and/or
>
><!-- registers specific dom factory for specific dom classes, leaving the
>default dom factory alone -->
><dom-loader>
>     <dom-loader-register
>factory="org.enhydra.barracuda.core.util.dom.XMLCDeferredParsingDOMFactory"
>class="org.enhydra.barracuda.contrib.dbroggisch.examples.view.xmlc.Navigatio
>nHTML" />
>     <dom-loader-register
>factory="org.enhydra.barracuda.core.util.dom.XMLCDeferredParsingDOMFactory"
>class="org.enhydra.barracuda.contrib.dbroggisch.examples.view.xmlc.FileUploa
>dHTML" />
>     <dom-loader-register
>factory="org.enhydra.barracuda.core.util.dom.XMLCDeferredParsingDOMFactory"
>class="org.enhydra.barracuda.contrib.dbroggisch.examples.view.xmlc.PrefixMap
>pingHTML" />
>     <dom-loader-register
>factory="org.enhydra.barracuda.core.util.dom.XMLCDeferredParsingDOMFactory"
>class="org.enhydra.barracuda.contrib.dbroggisch.examples.view.xmlc.Repopulat
>ionHTML" /> -->
></dom-loader>
>
>This is somewhat experimental, but I've tested it to work perfectly with
>Diez' contrib app.  Without this config, one has to set this in code such
>as...
>
>         DOMLoader domLoader = DefaultDOMLoader.getGlobalInstance();
>         DOMFactory domFactory = new XMLCDeferredParsingDOMFactory();
>         domLoader.registerDOMFactory(domFactory, NavigationHTML.class);
>         domLoader.registerDOMFactory(domFactory, FileUploadHTML.class);
>         domLoader.registerDOMFactory(domFactory, PrefixMappingHTML.class);
>         domLoader.registerDOMFactory(domFactory, RepopulationHTML.class);
>
>Setting this in code makes one have to modify and recompile the code to
>change the DOMFactory.  Having this ability in the assembly descriptor
>allows for easy changes without recompiling....although you'd have to make
>sure that you rebuild the XMLC classes with/without
>"-for-deferred-parsing" because, currently the normal XMLCStdFactory is
>unable to load dom classes compiled for deferred parsing (and vice-versa).
>I asked about this on the XMLC list and David Li provided two potential
>solutions....
>
><quote name="David Li">
>1. Implement the backward compatible document class generating. This
>shouldn't be very hard but tedious. It requires merging the std class
>generating codes with the deferred parsing generating codes.
>
>2. Just forget about the existing of StdFactory and start thinking Deferred
>parsing as the only factory. ;)
></quote>
>
>So, if #1 isn't implemented, then we might think about doing #2 by making
>the DefaultDOMFactory use XMLCDeferredParsingFactory rather than
>XMLCStdFactory.  Of course, this means using the flag
>"-for-deferred-parsing" for all XMLC compilation in the Barracuda build by
>default.  I'm not really pushing for this change in DefaultDOMFactory.  I'd
>rather see #1 implemented, but the question is, who is going to do it?
>
>Anyway, that's that.  Try the attached DefaultApplicationAssembler out if
>you like.  I'd like to get confirmation from someone using a servlet 2.2
>engine that things work .  It certainly works under my Tomcat-4.1.24.  I'll
>check this in if I hear no complaints.
>
>Jake
>
>At 01:52 PM 4/15/2003 -0500, you wrote:
>
>Jacob Kjome wrote:
>
>Anyway, let me know how ready you are to move to requiring Servlet 2.3.
>
>Maybe tag the current build as 2.2 compliant, and start a new branch that
>works with 2.3.
>
>Iman
>
>_______________________________________________
>Barracuda mailing list
>[email protected]
>http://barracudamvc.org/lists/listinfo/barracuda
>
>_______________________________________________
>Barracuda mailing list
>[email protected]
>http://barracudamvc.org/lists/listinfo/barracuda