RE: Problem with current build
"Christian Cryder" <[email protected]>
| Newsgroups | gmane.comp.java.enhydra.barracuda.general |
|---|---|
| Message-ID | <[email protected]> |
Hi Jake, Here's my question in a nutshell: why can't there still be a default if the <dom-loader> tag is not present? This would still not cuse James' code to be tied to XMLC, because all he has to do is specify the <dom-loader>. But for everyone else, things keep purring along. I don't see what the problem is with this approach...Barracuda already has a compile time dependency on XMLC (since we use it), but James' code would not...all he has to do is specify the tag. Or am I still missing something here? The solution seems relatively simple - you just use a lazy/deferred instantiation of the defaultDOMFactory object, and you provide a way to override the class that the instantiation uses. Don't specify anything, and when you try to load something it instantiates the loader via the default class. But if you want a different loader, then you specify that at startup (and I would be inclined to set that property via the ObjectRepositoryAssembler, rather than the ApplicationAssembler...if all you are overriding is a static constant, you could actually do it from either). In either case, there is not a compile time dependency on XMLC. My point here is that I think its totally possible to a) provide the new functionality while b) not breaking existing installations, and so I think we should pursue that approach. If it really is impossible to do that, please just be patient and try to explain it to me...I can be dense sometimes ;-) 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 7:06 PM To: [email protected] Subject: RE: [Barracuda] 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 ---------------------------------------------- "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