RE: Barracuda and using Servlet 2.3 features?

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