Re: 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.NavigationHTML" 
/>
     <dom-loader-register 
factory="org.enhydra.barracuda.core.util.dom.XMLCDeferredParsingDOMFactory" 
class="org.enhydra.barracuda.contrib.dbroggisch.examples.view.xmlc.FileUploadHTML" 
/>
     <dom-loader-register 
factory="org.enhydra.barracuda.core.util.dom.XMLCDeferredParsingDOMFactory" 
class="org.enhydra.barracuda.contrib.dbroggisch.examples.view.xmlc.PrefixMappingHTML" 
/>
     <dom-loader-register 
factory="org.enhydra.barracuda.core.util.dom.XMLCDeferredParsingDOMFactory" 
class="org.enhydra.barracuda.contrib.dbroggisch.examples.view.xmlc.RepopulationHTML" 
/> -->
</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