RE: Barracuda and using Servlet 2.3 features?

Ah, ok. My bad ;-)

----------------------------------------------
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:44 PM
  To: [email protected]
  Subject: RE: [Barracuda] 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