RE: Problem with current build

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