[jsfunit-dev] XML marshalling
Stan Silvert
ssilvert at redhat.com
Mon Oct 29 22:28:16 EDT 2007
They did it to Tomcat too.
I think we are OK as long as we include the license.txt file. Here is
your question from the Apache license FAQ:
http://www.apache.org/foundation/licence-FAQ.html#Distribute-changes
Stan
Dennis Byrne wrote:
> 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
> <mailto: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>
> > <mailto: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>
> <mailto:jsfunit-dev at lists.jboss.org
> <mailto:jsfunit-dev at lists.jboss.org>>
> > > https://lists.jboss.org/mailman/listinfo/jsfunit-dev
> <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> <mailto:
> 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 <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
More information about the jsfunit-dev
mailing list