RE: Problem with current build
"Christian Cryder" <[email protected]>
| Newsgroups | gmane.comp.java.enhydra.barracuda.general |
|---|---|
| Message-ID | <[email protected]> |
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 ---------------------------------------------- "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 ---------------------------------------------- "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 ---------------------------------------------- "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