6:32 p.m.
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
5:55 p.m.
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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jsfunit-dev
11:36 p.m.
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(a)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(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jsfunit-dev
_______________________________________________
jsfunit-dev mailing list
jsfunit-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jsfunit-dev
--
Dennis Byrne
2:51 a.m.
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(a)redhat.com
<mailto: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(a)lists.jboss.org <mailto:jsfunit-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/jsfunit-dev
_______________________________________________
jsfunit-dev mailing list
jsfunit-dev(a)lists.jboss.org <mailto:jsfunit-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/jsfunit-dev
--
Dennis Byrne
------------------------------------------------------------------------
_______________________________________________
jsfunit-dev mailing list
jsfunit-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jsfunit-dev
3:21 a.m.
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(a)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(a)redhat.com
> <mailto: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(a)lists.jboss.org <mailto:jsfunit-dev@lists.jboss.org>
> > https://lists.jboss.org/mailman/listinfo/jsfunit-dev
>
> _______________________________________________
> jsfunit-dev mailing list
> jsfunit-dev(a)lists.jboss.org <mailto:jsfunit-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/jsfunit-dev
>
>
>
>
> --
> Dennis Byrne
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> jsfunit-dev mailing list
> jsfunit-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jsfunit-dev
_______________________________________________
jsfunit-dev mailing list
jsfunit-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jsfunit-dev
--
Dennis Byrne
3:28 a.m.
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(a)redhat.com
<mailto:ssilvert@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(a)redhat.com
<mailto:ssilvert@redhat.com>
> <mailto:ssilvert@redhat.com <mailto: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(a)lists.jboss.org
<mailto:jsfunit-dev@lists.jboss.org>
<mailto:jsfunit-dev@lists.jboss.org
<mailto:jsfunit-dev@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(a)lists.jboss.org
<mailto:jsfunit-dev@lists.jboss.org> <mailto:
jsfunit-dev(a)lists.jboss.org <mailto:jsfunit-dev@lists.jboss.org>>
> https://lists.jboss.org/mailman/listinfo/jsfunit-dev
>
>
>
>
> --
> Dennis Byrne
>
>
>
------------------------------------------------------------------------
>
> _______________________________________________
> jsfunit-dev mailing list
> jsfunit-dev(a)lists.jboss.org <mailto:jsfunit-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/jsfunit-dev
_______________________________________________
jsfunit-dev mailing list
jsfunit-dev(a)lists.jboss.org <mailto:jsfunit-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/jsfunit-dev
--
Dennis Byrne
------------------------------------------------------------------------
_______________________________________________
jsfunit-dev mailing list
jsfunit-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jsfunit-dev
6016
days inactive
6019
days old
5 comments
2 participants
participants (2)
-
Dennis Byrne -
Stan Silvert