RE: Problem with current build

As soon as we choose a default and specify it either in the DOMLoader or 
the DefaultApplicationAssembler, the DefaultApplicationAssembler will have 
a compile-dependency upon XMLC, which is exactly why I removed the 
default.  I only did it in response to James Carnegie who reported the XMLC 
dependency where he doesn't use the View part of Barracuda anyway. To be 
fair, I created the dependency by adding the <dom-loader> configuration 
stuff in the first place (because it accesses 
DefaultDOMLoader.getGlobalInstance()), but I think the <dom-loader> stuff 
only adds to Barracuda's flexibility and ease-of-use, rather than being 
something bad.

Keep in mind that the change from 1.1.1 to 1.2.0 probably broke lots of 
apps out there in much worse ways (but for much added value) than this 
change and people seem to have survived that so far as I can tell (someone 
let me know if I am assuming too much here).  Besides, <dom-oader> is 
available in the 1.2.0 release anyway so it isn't like it is completely 
brand new. It's been there for about 1 1/2 months already!  If we document 
it, I don't think it should be a problem.  <dom-loader> is mentioned in the 
changes.html doc, A_Changes_History.java, and now explained in the javadoc 
for DefaultDOMLoader#setDefaultDOMFactory().  The fix is quite simple.  No 
code needs changing.  The only thing one needs to do is make sure something 
like this line is in their assembly descriptor...

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


If this was something like an interface change that broke everything or 
something that required people to extend some particular Barracuda class, 
I'd have to admit the error of my ways, but this is just too darned simple 
an issue to fix to claim that it will "break every ounce of existing 
code".  Any user of Barracuda who is willing to update to the latest and 
greatest most likely follows this list and will know of this change (as 
soon as I mention it on the list...after all, the change just happened in 
the last 2 days).  For the few that don't, they would once they found a 
problem.  They would ask the question, and I would promptly and succinctly 
respond by saying "add this simple line to your assembler file and all will 
be well".  That really just doesn't seem so horrific to me and the upside 
is, of course, that we get total DOMFactory independence with the ability 
to switch implementations without recompiling.  I don't see the downside.

I will post an email shorty after this message which spells out what the 
new requirement is to use the View part of Barracuda.  I think that should 
take care of 90 - 99 percent of this issue and we can move on to worrying 
about more important things.

Comments?  Anyone else have an opinion?

Jake

At 05:27 PM 5/30/2003 -0600, you wrote:
>Hi Jake,
>
>I just don't think we should make a change like this that will so 
>blatantly break existing code. It was very non-obvious to me from the 
>stack trace what the error was, and I'm active on the list, familiar with 
>the code, etc. That's setting ourselves up for ticked off developers when 
>they upgrade from cvs (or to the newest build) and all of a sudden things 
>don't work.
>
>I think we CAN assume its XMLC for now, because a) that's all there is at 
>this point and b) when we get to the point of using other DOMLoaders we 
>can then add the tags to the assembler files.
>
>The bottom line is we need to try and keep existing code from breaking 
>whenever possible, and this change (as it stands now) will break every 
>ounce of existing code with a very difficult-to-diagnose error unless 
>manually updates all their assembler files.
>
>Christian
>----------------------------------------------
>Christian Cryder [[email protected]]
>Internet Architect, ATMReports.com
>Barracuda - <http://barracudamvc.org/>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: Friday, May 30, 2003 4:58 PM
>To: [email protected]
>Subject: RE: [Barracuda] Problem with current build
>
>
>Well, we can't really assume a default because, theoretically, we don't 
>know what someone is using to do their dom loading.  We can't just assume 
>it is XMLC.  If one does not want to provide the default in the assembler 
>file, then one needs to provide the default programmatically at the 
>startup of their application.  For instance...
>
>DefaultDOMLoader.getGlobalInstance().setDefaultDOMFactory(new 
>XMLCDeferredParsingDOMFactory());
>
>That is what I added to the component test cases.
>
>This is just a requirement that we have to live with if we want to claim 
>to have no particular dependency on XMLC or any other specific DOM 
>implementation in Barracuda which is what the whole DOMFactory, DOMLoader, 
>DOMWriter setup is all about is trying to archive; implementation independence.
>
>Thoughts?
>
>Jake
>
>At 04:47 PM 5/30/2003 -0600, you wrote:
>>Hi Jake,
>>
>>Ok, so in answer to my own question, I see that application-gateway.xml 
>>now has a reference to <dom-loader> tags...and I remember seeing this in 
>>emails over the past week, but I don't recall the specific details.
>>
>>I'm guessing the reason why things are blowing chunks are because I'm not 
>>explicitly specifying this in my current application-gateway.xml. Is this 
>>the case?
>>
>>If it is, we need to rethink this, because it will cause all existing 
>>installations to fail until the dom-loader is specified. I think there 
>>MUST be a default (ie. if not dom-loader tags are specified, use XXX, 
>>where XXX is probably the new and improved XMLCDeferredParsingDOMFactory).
>>
>>Thoughts? Comments? Am I missing something here?
>>
>>Christian
>>
>>(ps - my apologies for not responding to this earlier in the email 
>>discussions)
>>----------------------------------------------
>>Christian Cryder [[email protected]]
>>Internet Architect, ATMReports.com
>>Barracuda - <http://barracudamvc.org/>http://barracudamvc.org
>>----------------------------------------------
>>"Coffee? I could quit anytime, just not today"
>>-----Original Message-----
>>From: Christian Cryder [mailto:[email protected]]
>>Sent: Friday, May 30, 2003 4:40 PM
>>To: [email protected]
>>Subject: RE: [Barracuda] Problem with current build
>>
>>Ok, superclean seems to have fixed it. Which means something in the 
>>sample.* fioles changed, right? Can you tell me exactly what...
>>
>>tia,
>>CHristian
>>
>>
>>----------------------------------------------
>>Christian Cryder [[email protected]]
>>Internet Architect, ATMReports.com
>>Barracuda - <http://barracudamvc.org/>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: Friday, May 30, 2003 4:16 PM
>>To: [email protected]
>>Subject: Re: [Barracuda] Problem with current build
>>
>>Did you try doing a clean build?
>>Try checking out the Barracuda CVS to a completely separate directory 
>>than your current tree.  Then do "ant superclean".  Then do "ant 
>>catalina-install".
>>I just did exactly what I described above and everything works fine under 
>>j2sdk1.4.1_02, Ant-1.5.3, and Tomcat-4.1.24.
>>Jake
>>At 03:54 PM 5/30/2003 -0600, you wrote:
>>>Jake,
>>>Can you take a look at the current build of Barracuda (what's current in
>>>cvs)...I am getting the following exception...
>>>
>>>http://localhost:8080/Barracuda/GetLoginScreen.event
>>>Error: EventException
>>>There was an unexpected error while servicing this request...please contact
>>>your application administrator and notify them of the problem.
>>>Error dispatching request: Unexpected IOException
>>>Exception:
>>>org.enhydra.barracuda.core.event.EventException: Unexpected IOException
>>>         at
>>>org.enhydra.barracuda.core.event.DefaultBaseEventListener.handleEvent(Defaul 
>>>
>>>tBaseEventListener.java:73)
>>>         at
>>>org.enhydra.barracuda.core.event.DefaultEventDispatcher.notifyListeners(Defa 
>>>
>>>ultEventDispatcher.java:415)
>>>         at
>>>org.enhydra.barracuda.core.event.DefaultEventDispatcher.dispatch(DefaultEven 
>>>
>>>tDispatcher.java:185)
>>>         at
>>>org.enhydra.barracuda.core.event.DefaultEventDispatcher.dispatchEvent(Defaul 
>>>
>>>tEventDispatcher.java:122)
>>>         at
>>>org.enhydra.barracuda.core.event.DefaultEventBroker.dispatchEvent(DefaultEve 
>>>
>>>ntBroker.java:494)
>>>         at
>>>org.enhydra.barracuda.core.event.ApplicationGateway.handleDefaultExt(Applica 
>>>
>>>tionGateway.java:420)
>>>         at
>>>org.enhydra.barracuda.core.event.ApplicationGateway.handleDefault(Applicatio 
>>>
>>>nGateway.java:241)
>>>         at
>>>org.enhydra.barracuda.core.event.ApplicationGateway.doGet(ApplicationGateway 
>>>
>>>.java:648)
>>>         at javax.servlet.http.HttpServlet.service(HttpServlet.java:740)
>>>         at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
>>>         at
>>>org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Application 
>>>
>>>FilterChain.java:247)
>>>         at
>>>org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterCh 
>>>
>>>ain.java:193)
>>>         at
>>>org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.ja 
>>>
>>>va:260)
>>>         at
>>>org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invok 
>>>
>>>eNext(StandardPipeline.java:643)
>>>         at
>>>org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
>>>         at 
>>> org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
>>>         at
>>>org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.ja 
>>>
>>>va:191)
>>>         at
>>>org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invok 
>>>
>>>eNext(StandardPipeline.java:643)
>>>         at
>>>org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
>>>         at 
>>> org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
>>>         at
>>>org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2396)
>>>         at
>>>org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:180 
>>>
>>>)
>>>         at
>>>org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invok 
>>>
>>>eNext(StandardPipeline.java:643)
>>>         at
>>>org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherValve. 
>>>
>>>java:170)
>>>         at
>>>org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invok 
>>>
>>>eNext(StandardPipeline.java:641)
>>>         at
>>>org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:172 
>>>
>>>)
>>>         at
>>>org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invok 
>>>
>>>eNext(StandardPipeline.java:641)
>>>         at
>>>org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
>>>         at 
>>> org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
>>>         at
>>>org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java 
>>>
>>>:174)
>>>         at
>>>org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invok 
>>>
>>>eNext(StandardPipeline.java:643)
>>>         at
>>>org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
>>>         at 
>>> org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
>>>         at 
>>> org.apache.coyote.tomcat4.CoyoteAdapter.service(CoyoteAdapter.java:223)
>>>         at
>>>org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:405)
>>>         at
>>>org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConne 
>>>
>>>ction(Http11Protocol.java:380)
>>>         at
>>>org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:508)
>>>         at
>>>org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.jav 
>>>
>>>a:533)
>>>         at java.lang.Thread.run(Thread.java:536)
>>>Parameters:
>>>RequestURI:/Barracuda/GetLoginScreen.event
>>>ServletPath:/GetLoginScreen.event
>>>PathInfo:null
>>>PathTranslated:null
>>>----------------------------------------------
>>>Christian Cryder [[email protected]]
>>>Internet Architect, ATMReports.com
>>>Barracuda - http://barracudamvc.org
>>>----------------------------------------------
>>>"Coffee? I could quit anytime, just not today"
>>>_______________________________________________
>>>Barracuda mailing list
>>>[email protected]
>>>http://barracudamvc.org/lists/listinfo/barracuda