[jsfunit-dev] XML marshalling
Dennis Byrne
dennisbyrne at apache.org
Mon Oct 29 22:21:24 EDT 2007
I didn't know they "warped" the apache jars. (off topic, I think Sun once
did something similar w/ Xerces). Well, that is good to know.
On legal, I know that redistributing apache jars is a piece of cake, due to
the non-viral nature of the license. But is there anything extra if JSFUnit
distributes the jars in a changed form (move packages or stripped classes).
I would imagine that answer is "No".
Dennis Byrne
On 10/29/07, Stan Silvert <ssilvert at redhat.com> wrote:
>
> Dennis Byrne wrote:
> > 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.
>
> Well, yes and no. They forked beanutils, collections, digester, and
> even commons logging. They just changed the package names to
> com.sun.org.apache.whatever. So what you end up with is just two jars,
> jsf-api.jar and jsf-impl.jar. The impl jar has all the forked apache
> commons stuff in it.
>
> Every project in the world seems to need these four commons packages
> these days. So I don't think it's a big issue to add them.
>
> Is there still something you want me to ping the attorney about? What
> was the exact question?
>
> >
> > Still thinking.
> >
> > Dennis Byrne
> >
> > On 10/29/07, *Stan Silvert* <ssilvert at redhat.com
> > <mailto:ssilvert at 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 at lists.jboss.org <mailto:jsfunit-dev at lists.jboss.org>
> > > https://lists.jboss.org/mailman/listinfo/jsfunit-dev
> >
> > _______________________________________________
> > jsfunit-dev mailing list
> > jsfunit-dev at lists.jboss.org <mailto:jsfunit-dev at lists.jboss.org>
> > https://lists.jboss.org/mailman/listinfo/jsfunit-dev
> >
> >
> >
> >
> > --
> > Dennis Byrne
> >
> >
> > ------------------------------------------------------------------------
> >
> > _______________________________________________
> > jsfunit-dev mailing list
> > jsfunit-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/jsfunit-dev
>
> _______________________________________________
> jsfunit-dev mailing list
> jsfunit-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jsfunit-dev
>
--
Dennis Byrne
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jsfunit-dev/attachments/20071029/c5b17e4e/attachment.html
More information about the jsfunit-dev
mailing list