I think we agree then that there *has* to be a common model for XML based and annotation based configuration details. Similar to how the AnnonationConfiguration extends Configuration in hibernate 3. <br><br>Unfortunately there is no way to rip out clogging. Myfaces and Digester both have binary dependencies on it. I agree that logging is not needed by us - just let it rip. I felt the same about performance when I wrote the code.
<br><br>I thought about using JAXB as an alternative also but that only covers JSF 1.2 conf files (JAXB requires an XSD, JSF 1.1 used a DTD). Maybe if we can determine if all JSF 1.1 documents could conform to the new JSF
1.2 schema, I could just do a string replace on the XML and replace DTD processing instruction w/ an schema reference ... then send it through JAXB.<br><br>BTW, what does the RI use for this task? I remember them having very few dependencies.
<br><br>Still thinking.<br><br>Dennis Byrne<br><br><div><span class="gmail_quote">On 10/29/07, <b class="gmail_sendername">Stan Silvert</b> <<a href="mailto:ssilvert@redhat.com">ssilvert@redhat.com</a>> wrote:</span>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">I've been working on a reply to this for awhile. I'll post what I have<br>so far, which I know does not answer the question. I'm still working on
<br>it though.<br><br>--------------------------------------------------------------<br>So at the end of the day, what do you have? It would be really great if<br>you had all the composite config info accessible through a simple API.
<br>I'm talking about the result of all the faces-config files in the<br>application. Plus a report that you can spit out to see all of your<br>configuration. Bonus points if it also shows the config that results<br>
from Seam annotations. Everybody would love that.<br><br>Right now, you have managed bean definitions coming from scads of<br>thrid-party libraries, factory declarations, etc. For instance, which<br>FacesContextFactory won the battle? Can I see the whole chain of factories?
<br><br>Same goes for web.xml. I know that MyFaces parses the web.xml. Even<br>having an API that can tell me how the FacesServlet is mapped would be<br>very useful.<br><br>So I hope that's where you are going with this, but unfortunately it
<br>doesn't answer your questions.<br><br>How hard would it be to at least get rid of commons logging? Right now<br>everything in JSFUnit just lets the exceptions bubble all the way up.<br>Then the application developer can decide if/how they are logged. I
<br>think this is a good approach for JUnit tests because in a test you<br>usually just let the exceptions bubble up and allow JUnit to report a<br>failure.<br><br><br><br>Dennis Byrne wrote:<br>> I took MyFaces 1.2.0 and stripped somewhere around 80% of the classes.
<br>> Pretty much ripped out everything but org.apache.myfaces.config<br>> package. Doing this gives you just enough to parse versions 1.0, 1.1<br>> and 1.2 of faces-config files using two lines of code.<br>>
<br>> ByteArrayInputStream bais = new<br>> ByteArrayInputStream(testFacesConfig.getBytes());<br>> dispenser.feed(unmarshaller.getFacesConfig(bais, null));<br>><br>> Here are the costs of going this route. This introduces a dependency on
<br>> digestor, commons logging, beanutils and commons collections. It also<br>> means we have to maintain the myfaces-stripped jar until the config<br>> stuff gets moved into the new myfaces commons project (which probably
<br>> won't be released before JSFUnit). It also means we have to ping a<br>> lawyer because I have never done this before (change ASF artifact,<br>> release under LGPL).<br>><br>> Let me know your thoughts. I timeboxed this at an hour so I don't have
<br>> a lot of emotions behind going this route. Part of me feels like just<br>> benching this until after the release.<br>> --<br>> Dennis Byrne<br>><br>><br>> ------------------------------------------------------------------------
<br>><br>> _______________________________________________<br>> jsfunit-dev mailing list<br>> <a href="mailto:jsfunit-dev@lists.jboss.org">jsfunit-dev@lists.jboss.org</a><br>> <a href="https://lists.jboss.org/mailman/listinfo/jsfunit-dev">
https://lists.jboss.org/mailman/listinfo/jsfunit-dev</a><br><br>_______________________________________________<br>jsfunit-dev mailing list<br><a href="mailto:jsfunit-dev@lists.jboss.org">jsfunit-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/jsfunit-dev">https://lists.jboss.org/mailman/listinfo/jsfunit-dev</a><br></blockquote></div><br><br clear="all"><br>-- <br>Dennis Byrne