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.
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.
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.
BTW, what does the RI use for this task? I remember them having very few dependencies.
Still thinking.
Dennis Byrne
On 10/29/07, Stan Silvert <ssilvert@redhat.com> wrote:
I've been working on a reply to this for awhile. I'll post what I have
so far, which I know does not answer the question. I'm still working on
it though.
--------------------------------------------------------------
So at the end of the day, what do you have? It would be really great if
you had all the composite config info accessible through a simple API.
I'm talking about the result of all the faces-config files in the
application. Plus a report that you can spit out to see all of your
configuration. Bonus points if it also shows the config that results
from Seam annotations. Everybody would love that.
Right now, you have managed bean definitions coming from scads of
thrid-party libraries, factory declarations, etc. For instance, which
FacesContextFactory won the battle? Can I see the whole chain of factories?
Same goes for web.xml. I know that MyFaces parses the web.xml. Even
having an API that can tell me how the FacesServlet is mapped would be
very useful.
So I hope that's where you are going with this, but unfortunately it
doesn't answer your questions.
How hard would it be to at least get rid of commons logging? Right now
everything in JSFUnit just lets the exceptions bubble all the way up.
Then the application developer can decide if/how they are logged. I
think this is a good approach for JUnit tests because in a test you
usually just let the exceptions bubble up and allow JUnit to report a
failure.
Dennis Byrne wrote:
> I took MyFaces 1.2.0 and stripped somewhere around 80% of the classes.
> Pretty much ripped out everything but org.apache.myfaces.config
> package. Doing this gives you just enough to parse versions 1.0, 1.1
> and 1.2 of faces-config files using two lines of code.
>
> ByteArrayInputStream bais = new
> ByteArrayInputStream(testFacesConfig.getBytes());
> dispenser.feed(unmarshaller.getFacesConfig(bais, null));
>
> Here are the costs of going this route. This introduces a dependency on
> digestor, commons logging, beanutils and commons collections. It also
> means we have to maintain the myfaces-stripped jar until the config
> stuff gets moved into the new myfaces commons project (which probably
> won't be released before JSFUnit). It also means we have to ping a
> lawyer because I have never done this before (change ASF artifact,
> release under LGPL).
>
> Let me know your thoughts. I timeboxed this at an hour so I don't have
> a lot of emotions behind going this route. Part of me feels like just
> benching this until after the release.
> --
> Dennis Byrne
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> jsfunit-dev mailing list
> jsfunit-dev@lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/jsfunit-dev
_______________________________________________
jsfunit-dev mailing list
jsfunit-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jsfunit-dev
--
Dennis Byrne