RE: Problem with current build

Hi Christian,

Ok, the fix has been made.  There now is no necessity to provide the 
default dom factory either programmatically or via the assembly 
descriptor.  It is entirely optional and DefaultDOMLoader does provide a 
default DOMFactory (which is now the XMLCDeferredParsingDOMFactory).  I 
avoided any compile-time dependency on XMLC for the 
DefaultApplicationAssembler by making sure obtain the global instance of 
the dom factory via runtime reflection.  Actually, this is quite an 
improvement since now, one can specify a different DOMLoader.  Before, the 
only DOMLoader that could be configured via the assembly file was the 
DefaultDOMLoader.  The one stipulation is that the DOMLoader must provide a 
public static method called getGlobalInstance().  I would have added that 
to the DOMLoader interface, but interfaces can't take static methods.  I 
don't think this should be an issue.

One thing I'd like you to do is modify DefaultDOMLoader and set up 
lazy/deferred instantiation of the default dom factory the way you would 
like to do it.  I'm too tired to think about it right now.  It currently 
looks like this...

protected DOMFactory defaultDOMFactory = new XMLCDeferredParsingDOMFactory();

After that, the only question about the DOM stuff is whether to change 
DefaultDOMWriter to something like DefaultXMLCDOMWriter or XMLCDOMWriter, 
but that can wait for more public comment.

Jake

At 02:05 AM 5/31/2003 -0500, you wrote:
>At 10:40 PM 5/30/2003 -0600, you wrote:
>>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?
>>
>
>Yes, you are missing something.  Actually, the problem is that the way I 
>set the DOMFactory in the DefaultDOMLoader.  I first needed to obtain an 
>instance of the DefaultDOMLoader via...
>
>DOMLoader domLoader = DefaultDOMLoader.getGlobalInstance();
>
>I set that as an instance variable of the xml parser inner class.  Since 
>the DefaultDOMLoader used a default implementation of of a DOMFactory 
>which used the XMLCStdFactory, the DefaultApplicationAssembler, by proxy, 
>ended up having a compile-dependency on XMLC.
>
>I've now actually solved this in my local tree by using reflection and 
>adding one new attribute to the <dom-loader> element.  For instance....
>
><dom-loader class="org.enhydra.barracuda.core.util.dom.DefaultDOMLoader" 
>factory="org.enhydra.barracuda.core.util.dom.XMLCDeferredParsingDOMFactory">
>
>The class is the specified dom loader and it must have a 
>"getGlobalInstance()" method in it.  I find that out using 
>reflection.  Now we can add back in a default to the DefaultDOMLoader and 
>there is no dependency.  I have to work out a few kinks but, what you do 
>you think about that?
>
>>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.
>>
>
>lazy instantiation in the getGlobalInstance() method?  That might work 
>too.  Actually that is probably less involved than what I did.  However, 
>what I did now lets you define a DOMLoader to use in the configuration 
>which is kind of cool, I think.
>
>>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 ;-)
>>
>
>You are right.  Actually, I was being kind of dense.  Had my mind on one 
>track, but after thinking about it, I saw the solution(s) staring me in 
>the face.
>
>I'll try to commit this stuff later this weekend after I think about the 
>best way to go about all this stuff.
>
>>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 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/>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