RE: sorry, nevermind.... please read! - planned change that might break Barracuda apps with simple fix...

Awesome! I will check it out this morning and let you know how it goes!
Thanks much, Jake!

Christian
----------------------------------------------
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: Saturday, May 31, 2003 9:39 PM
  To: [email protected]
  Subject: Re: [Barracuda] sorry, nevermind.... please read! - planned
change that might break Barracuda apps with simple fix...



  Most everything I said below is now false.  I made it so the change won't
affect anyone.  A default dom factory is, again, provided in the
DefaultDOMLoader without creating an XMLC compile-dependency on
DefaultApplicationAssembler.

  See the new notes in the javadoc for DefaultApplicationAssembler,
DefaultDOMLoader, and also see Barracuda's sample.event-gateway.xml for
details.  The new way I set things up is actually more flexible than it was
even before.

  Sorry for any confusion my previous message may have caused.

  Jake

  At 08:29 PM 5/30/2003 -0500, you wrote:


    Hi everyone,

    A recent change that I made to the DefaultDOMLoader may break your code,
but there is a very simple fix which requires absolutely no changes to your
existing code, nor does it even require recompilation.

    If you update to the latest CVS (as of May 28th, 2003), you will notice
that if you don't explicitly set a DOMFactory implementation to the
DefaultDOMLoader, your code will fail as soon as DefaultDOMWriter#getDOM()
is called.  The reason for this is that I removed the default DOMFactory
that DefaultDOMLoader was using.  It was creating a compile-time dependency
upon XMLC which, in turn, created a compile-time dependency on XMLC for the
DefaultApplicationAssembler (because it gets a DOMLoader instance by doing
DefaultDOMLoader.getGlobalInstance()).  This was reported by James Carnegie
who doesn't use the View part of the application asembler, so he didn't want
a dependency on XMLC.  This is described in the javadoc for
DefaultDOMLoader#setDefaultDOMFactory(), but I'll spell it out here as
well...

    What is required is that you either set the DOMFactory programatically
via or via assembler configuration.  I recommend using the assembler
configuration as it requires no other change to your code.  All it takes is
a line such as this....

    <dom-loader
factory="org.enhydra.barracuda.core.util.dom.XMLCDeferredParsingDOMFactory"/
>

    If you choose to do this programmatically, then do something like the
following before calling DefaultDOMWriter#getDOM()...

    DefaultDOMLoader.getGlobalInstance().setDefaultDOMFactory(new
XMLCDeferredParsingDOMFactory());


    You will find the above <dom-loader> line in Barracuda's
event-gateway.xml file.  Actually, you will find...

    <dom-loader
factory="org.enhydra.barracuda.core.util.dom.XMLCDeferredParsingDOMFactory">
            <set-property name="servletContext" delegateRuntimeValue="true"
/>
    </dom-loader>

    This part is out of the scope of the issue at hand, but I'll explain it
anyway since it is a cool feature.  The <set-property> actually tells the
DefaultApplicationAssembler to call the
XMLCDeferredParsingFactory#setServletContext() method with the current
runtime ServletContext, allowing access to context init parameters.  More
information on this can be found in the javadoc for
DefaultApplicationAssembler and my description of changes in
A_Changes_History.java.


    If you have any comments or questions, please do not hesitate to ask.  I
want to make sure this is a smooth transition for everyone.

    thanks,

    Jake