You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by Dennis Byrne <de...@dbyrne.net> on 2007/02/27 00:56:11 UTC

[VOTE] Remove Static loggers from 1.2

Alright.  Here's my +1 binding.  Let's put the nail in this coffin.

Dennis Byrne

On 2/26/07, Paul McMahan <pa...@gmail.com> wrote:
>
> Excellent observation, Dennis.  In Geronimo and a few other app
> servers I am familiar with the user is provided with several knobs
> that can affect classloading.  Ideally, a component designed to run in
> different types of containers would make as few assumptions about its
> container's classloader configuration as possible.  For example,
> Geronimo's classloaders can have multiple immediate parents which
> confuses code that thinks it can find resources (like TLDs) in the
> app's classloader by walking up a direct lineage of classloaders using
> getParent().  And like you say, factories and services like logging
> can get confused when they key on classes that are available from
> multiple classloaders.
>
> Another item somewhat related to this discussion that comes to mind is
> how Geronimo provides a shared instance of the Dojo toolkit in a
> preinstalled webapp that is deployed at the context "/dojo".  Webapps
> can of course include their own private copy of the Dojo toolkit in
> their WAR but they miss out on several benefits such as improved
> resource caching across application contexts, smaller application
> footprint, and having the ability to upgrade and otherwise manage the
> Dojo component separately from their webapp.  I thought this might be
> interesting to those working on Dojo/MyFaces integration.
>
> Best wishes,
> Paul
>
> On 2/26/07, Dennis Byrne <de...@dbyrne.net> wrote:
> >     Since JSF is part of the JEE 5 spec users don't need to include the
> >
> > > JSF jars or their dependencies in their webapps when deploying into
> > > Geronimo 2.0.  This makes developing a webapp much easier but makes
> > > developing JSF a little more tricky because the MyFaces jars are part
> > > of the server runtime.
> >
> > Hi Paul,
> >
> > On this team there is an age old debate about how logging.  The gist is
> that
> > we have static loggers all over the place.  This of course is not good
> > because the jars are not going to be located in the war (where they are
> > isolated by separate class loaders).
> >
> > Well, team ... we've never had a better reason to rip out the static
> > loggers.  What do you say?
> >
> > > Best wishes,
> > > Paul
> > >
> > >
> > > On 2/26/07, Matthias Wessendorf <ma...@apache.org> wrote:
> > > > geronimo2-SNAPSHOT
> > > >
> > > > you don't need to include the jsf-xxx jars
> > > >
> > > > A Java EE 5 compliant server has to ignore the jsf-xxx libs, shipped
> > > > in WEB-INF/lib
> > > > Since Tomcat 6.x and Jetty 6.x don't ship JSF, you have to include
> > > > them in your lib, like in the past
> > > >
> > > > -M
> > > >
> > > > On 2/26/07, Martin Haimberger <ma...@gmail.com> wrote:
> > > > > Sorry for spamming, but is there another Application Server which
> will
> > > > > work with MyFaces 1.2 and Intellij Idea ?
> > > > >
> > > > > Regards,
> > > > > Martin Haimberger
> > > > >
> > > > > On 2/26/07, Martin Haimberger < martin.haimberger@gmail.com>
> wrote:
> > > > > > No nothing more. No Exception, nothing. I will try Jetty6.1.x, i
> > hope
> > > > > > the myfaces1.2 will start.
> > > > > >
> > > > > > Regards,
> > > > > > Martin Haimberger
> > > > > >
> > > > > > On 2/26/07, Matthias Wessendorf <ma...@apache.org> wrote:
> > > > > > > does the tomcat log say more?
> > > > > > >
> > > > > > > I am able to deploy a jsf 1.2 app with Jetty6.1.x
> > > > > > >
> > > > > > > -M
> > > > > > >
> > > > > > > On 2/26/07, Martin Haimberger < martin.haimberger@gmail.com>
> > wrote:
> > > > > > > > Hy *,
> > > > > > > >
> > > > > > > > i am going to help to develop myfaces 1.2. I have checked it
> > out,
> > > > > > > > compiled it (with some difficulties, because some jars were
> not
> > > > > > > > found). I installed tomcat 6.0.9 alpha and i got this error:
> > > > > > > >
> > > > > > > > DEBUG [main] ( HtmlRenderKitImpl.java:112) - add Renderer
> family
> > =
> > > > > > > > javax.faces.SelectOne rendererType = javax.faces.Radiorenderer
> > class
> > > > > > > > =
> > org.apache.myfaces.renderkit.html.HtmlRadioRenderer
> > > > > > > >   INFO [main] (FacesConfigurator.java:972) - Serialization
> > provider :
> > > > > > > > class
> > org.apache.myfaces.shared_impl.util.serial.DefaultSerialFactory
> > > > > > > > Feb 26, 2007 2:14:34 PM
> > org.apache.catalina.core.StandardContext start
> > > > > > > > SEVERE: Error listenerStart
> > > > > > > > Feb 26, 2007 2:14:34 PM
> > org.apache.catalina.core.StandardContext start
> > > > > > > >
> > > > > > > > I am running Intellij 6.0.4 and tomcat 6.0.9 on MacOsX.
> > > > > > > >
> > > > > > > > Has someone any idea what i did wrong?
> > > > > > > >
> > > > > > > > Regards,
> > > > > > > > Martin Haimberger
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > Matthias Wessendorf
> > > > > > > http://tinyurl.com/fmywh
> > > > > > >
> > > > > > > further stuff:
> > > > > > > blog: http://jroller.com/page/mwessendorf
> > > > > > > mail: mwessendorf-at-gmail-dot-com
> > > > > > >
> > > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > Matthias Wessendorf
> > > > http://tinyurl.com/fmywh
> > > >
> > > > further stuff:
> > > > blog: http://jroller.com/page/mwessendorf
> > > > mail: mwessendorf-at-gmail-dot-com
> > > >
> > >
> >
> >
> >
> > --
> > Dennis Byrne
>



-- 
Dennis Byrne

Re: [VOTE] Remove Static loggers from 1.2

Posted by Werner Punz <we...@gmail.com>.
Mario Ivankovits schrieb:

> And - some prerequisites have changed - how many sense does it make when
> all new jee container forbid to have a custom jsf jar in your webapp-lib?
> Then the gc problem should no longer exist as this library will not be
> reloaded then, no?
> 
I think it still makes sense, since a lot of people work on pure servlet
jsp containers and add their own stack.
It is very unlikely that containers like tomcat or jetty will add jsf
as third stack.


Re: [VOTE] Remove Static loggers from 1.2

Posted by Mario Ivankovits <ma...@ops.co.at>.
Hi Matthias!
> this was discussed near to death in the past.
> search for simon kitching and logging here in the myfaces list
Anyway, just that we really know what we are talking about:

We have to remove the "static" keyword from the logger
and add a method getLog() which will lazily get the logger to decrease
the performance impact of e.g. lookups of lightweight objects (they are
likely to be created en mass and so the hashtable should be avoided).

This will add tons of code, though, there is no other way, isn't it?

And - some prerequisites have changed - how many sense does it make when
all new jee container forbid to have a custom jsf jar in your webapp-lib?
Then the gc problem should no longer exist as this library will not be
reloaded then, no?

Ciao,
Mario


Re: [VOTE] Remove Static loggers from 1.2

Posted by Niall Pemberton <ni...@gmail.com>.
Theres a page about this on the logging wiki here:

http://wiki.apache.org/jakarta-commons/Logging/StaticLog

Niall

On 2/27/07, Matthias Wessendorf <ma...@apache.org> wrote:
> this was discussed near to death in the past.
>
> search for simon kitching and logging here in the myfaces list
>
> -M
>
> On 2/27/07, Bernd Bohmann <be...@atanion.com> wrote:
> > Hello,
> >
> > what is the alternative?
> >
> > How is this handled by the RI?
> >
> > What is the performance impakt?
> >
> > Why not a container can separate each jsf webapp with a separate
> > classloader? Independent of the jsf implementation is provided by the
> > container or not.
> >
> > Can we remove commons logging and use jdk logging or something else?
> >
> > Without any technical discussion you get my
> >
> > -1
> >
> > Regards
> >
> > Bernd
> >
> >
> >
> >
> > Cagatay Civici wrote:
> > > +1 non-binding
> > >
> > > On 2/27/07, Matthias Wessendorf <ma...@apache.org> wrote:
> > >>
> > >> +1
> > >>
> > >>
> > >> On 2/27/07, Mike Kienenberger <mk...@gmail.com> wrote:
> > >> > +1
> > >> >
> > >> > On 2/26/07, Dennis Byrne <de...@dbyrne.net> wrote:
> > >> > > Alright.  Here's my +1 binding.  Let's put the nail in this coffin.
> > >> > >
> > >> > > Dennis Byrne
> > >> > >
> > >> > > On 2/26/07, Paul McMahan < paulmcmahan@gmail.com> wrote:
> > >> > > > Excellent observation, Dennis.  In Geronimo and a few other app
> > >> > > > servers I am familiar with the user is provided with several knobs
> > >> > > > that can affect classloading.  Ideally, a component designed to run
> > >> in
> > >> > > > different types of containers would make as few assumptions about
> > >> its
> > >> > > > container's classloader configuration as possible.  For example,
> > >> > > > Geronimo's classloaders can have multiple immediate parents which
> > >> > > > confuses code that thinks it can find resources (like TLDs) in the
> > >> > > > app's classloader by walking up a direct lineage of classloaders
> > >> using
> > >> > > > getParent().  And like you say, factories and services like logging
> > >> > > > can get confused when they key on classes that are available from
> > >> > > > multiple classloaders.
> > >> > > >
> > >> > > > Another item somewhat related to this discussion that comes to mind
> > >> is
> > >> > > > how Geronimo provides a shared instance of the Dojo toolkit in a
> > >> > > > preinstalled webapp that is deployed at the context
> > >> "/dojo".  Webapps
> > >> > > > can of course include their own private copy of the Dojo toolkit in
> > >> > > > their WAR but they miss out on several benefits such as improved
> > >> > > > resource caching across application contexts, smaller application
> > >> > > > footprint, and having the ability to upgrade and otherwise manage
> > >> the
> > >> > > > Dojo component separately from their webapp.  I thought this might
> > >> be
> > >> > > > interesting to those working on Dojo/MyFaces integration.
> > >> > > >
> > >> > > > Best wishes,
> > >> > > > Paul
> > >> > > >
> > >> > > > On 2/26/07, Dennis Byrne <de...@dbyrne.net> wrote:
> > >> > > > >     Since JSF is part of the JEE 5 spec users don't need to
> > >> include the
> > >> > > > >
> > >> > > > > > JSF jars or their dependencies in their webapps when deploying
> > >> into
> > >> > > > > > Geronimo 2.0.  This makes developing a webapp much easier but
> > >> makes
> > >> > > > > > developing JSF a little more tricky because the MyFaces jars
> > >> are
> > >> part
> > >> > > > > > of the server runtime.
> > >> > > > >
> > >> > > > > Hi Paul,
> > >> > > > >
> > >> > > > > On this team there is an age old debate about how logging.  The
> > >> gist is
> > >> > > that
> > >> > > > > we have static loggers all over the place.  This of course is not
> > >> good
> > >> > > > > because the jars are not going to be located in the war (where
> > >> they are
> > >> > > > > isolated by separate class loaders).
> > >> > > > >
> > >> > > > > Well, team ... we've never had a better reason to rip out the
> > >> static
> > >> > > > > loggers.  What do you say?
> > >> > > > >
> > >> > > > > > Best wishes,
> > >> > > > > > Paul
> > >> > > > > >
> > >> > > > > >
> > >> > > > > > On 2/26/07, Matthias Wessendorf <ma...@apache.org> wrote:
> > >> > > > > > > geronimo2-SNAPSHOT
> > >> > > > > > >
> > >> > > > > > > you don't need to include the jsf-xxx jars
> > >> > > > > > >
> > >> > > > > > > A Java EE 5 compliant server has to ignore the jsf-xxx libs,
> > >> shipped
> > >> > > > > > > in WEB-INF/lib
> > >> > > > > > > Since Tomcat 6.x and Jetty 6.x don't ship JSF, you have to
> > >> include
> > >> > > > > > > them in your lib, like in the past
> > >> > > > > > >
> > >> > > > > > > -M
> > >> > > > > > >
> > >> > > > > > > On 2/26/07, Martin Haimberger < martin.haimberger@gmail.com>
> > >> wrote:
> > >> > > > > > > > Sorry for spamming, but is there another Application Server
> > >> which
> > >> > > will
> > >> > > > > > > > work with MyFaces 1.2 and Intellij Idea ?
> > >> > > > > > > >
> > >> > > > > > > > Regards,
> > >> > > > > > > > Martin Haimberger
> > >> > > > > > > >
> > >> > > > > > > > On 2/26/07, Martin Haimberger <
> > >> martin.haimberger@gmail.com>
> > >> > > wrote:
> > >> > > > > > > > > No nothing more. No Exception, nothing. I will try
> > >> Jetty6.1.x, i
> > >> > > > > hope
> > >> > > > > > > > > the myfaces1.2 will start.
> > >> > > > > > > > >
> > >> > > > > > > > > Regards,
> > >> > > > > > > > > Martin Haimberger
> > >> > > > > > > > >
> > >> > > > > > > > > On 2/26/07, Matthias Wessendorf <matzew@apache.org >
> > >> wrote:
> > >> > > > > > > > > > does the tomcat log say more?
> > >> > > > > > > > > >
> > >> > > > > > > > > > I am able to deploy a jsf 1.2 app with Jetty6.1.x
> > >> > > > > > > > > >
> > >> > > > > > > > > > -M
> > >> > > > > > > > > >
> > >> > > > > > > > > > On 2/26/07, Martin Haimberger <
> > >> martin.haimberger@gmail.com>
> > >> > > > > wrote:
> > >> > > > > > > > > > > Hy *,
> > >> > > > > > > > > > >
> > >> > > > > > > > > > > i am going to help to develop myfaces 1.2. I have
> > >> checked it
> > >> > > > > out,
> > >> > > > > > > > > > > compiled it (with some difficulties, because some
> > >> jars
> > >> were
> > >> > > not
> > >> > > > > > > > > > > found). I installed tomcat 6.0.9 alpha and i got this
> > >> error:
> > >> > > > > > > > > > >
> > >> > > > > > > > > > > DEBUG [main] ( HtmlRenderKitImpl.java:112) - add
> > >> Renderer
> > >> > > family
> > >> > > > > =
> > >> > > > > > > > > > > javax.faces.SelectOne rendererType =
> > >> javax.faces.Radio
> > >> > > renderer
> > >> > > > > class
> > >> > > > > > > > > > > =
> > >> > > > > org.apache.myfaces.renderkit.html.HtmlRadioRenderer
> > >> > > > > > > > > > >   INFO [main] (FacesConfigurator.java:972) -
> > >> Serialization
> > >> > > > > provider :
> > >> > > > > > > > > > > class
> > >> > > > >
> > >> > > org.apache.myfaces.shared_impl.util.serial.DefaultSerialFactory
> > >> > > > > > > > > > > Feb 26, 2007 2:14:34 PM
> > >> > > > > org.apache.catalina.core.StandardContext start
> > >> > > > > > > > > > > SEVERE: Error listenerStart
> > >> > > > > > > > > > > Feb 26, 2007 2:14:34 PM
> > >> > > > > org.apache.catalina.core.StandardContext start
> > >> > > > > > > > > > >
> > >> > > > > > > > > > > I am running Intellij 6.0.4 and tomcat 6.0.9 on
> > >> MacOsX.
> > >> > > > > > > > > > >
> > >> > > > > > > > > > > Has someone any idea what i did wrong?
> > >> > > > > > > > > > >
> > >> > > > > > > > > > > Regards,
> > >> > > > > > > > > > > Martin Haimberger
> > >> > > > > > > > > > >
> > >> > > > > > > > > >
> > >> > > > > > > > > >
> > >> > > > > > > > > > --
> > >> > > > > > > > > > Matthias Wessendorf
> > >> > > > > > > > > > http://tinyurl.com/fmywh
> > >> > > > > > > > > >
> > >> > > > > > > > > > further stuff:
> > >> > > > > > > > > > blog: http://jroller.com/page/mwessendorf
> > >> > > > > > > > > > mail: mwessendorf-at-gmail-dot-com
> > >> > > > > > > > > >
> > >> > > > > > > > >
> > >> > > > > > > >
> > >> > > > > > >
> > >> > > > > > >
> > >> > > > > > > --
> > >> > > > > > > Matthias Wessendorf
> > >> > > > > > > http://tinyurl.com/fmywh
> > >> > > > > > >
> > >> > > > > > > further stuff:
> > >> > > > > > > blog: http://jroller.com/page/mwessendorf
> > >> > > > > > > mail: mwessendorf-at-gmail-dot-com
> > >> > > > > > >
> > >> > > > > >
> > >> > > > >
> > >> > > > >
> > >> > > > >
> > >> > > > > --
> > >> > > > > Dennis Byrne
> > >> > > >
> > >> > >
> > >> > >
> > >> > >
> > >> > > --
> > >> > > Dennis Byrne
> > >> >
> > >>
> > >>
> > >> --
> > >> Matthias Wessendorf
> > >> http://tinyurl.com/fmywh
> > >>
> > >> further stuff:
> > >> blog: http://jroller.com/page/mwessendorf
> > >> mail: mwessendorf-at-gmail-dot-com
> > >>
> > >
> >
>
>
> --
> Matthias Wessendorf
> http://tinyurl.com/fmywh
>
> further stuff:
> blog: http://jroller.com/page/mwessendorf
> mail: mwessendorf-at-gmail-dot-com
>

Re: [VOTE] Remove Static loggers from 1.2

Posted by Matthias Wessendorf <ma...@apache.org>.
this was discussed near to death in the past.

search for simon kitching and logging here in the myfaces list

-M

On 2/27/07, Bernd Bohmann <be...@atanion.com> wrote:
> Hello,
>
> what is the alternative?
>
> How is this handled by the RI?
>
> What is the performance impakt?
>
> Why not a container can separate each jsf webapp with a separate
> classloader? Independent of the jsf implementation is provided by the
> container or not.
>
> Can we remove commons logging and use jdk logging or something else?
>
> Without any technical discussion you get my
>
> -1
>
> Regards
>
> Bernd
>
>
>
>
> Cagatay Civici wrote:
> > +1 non-binding
> >
> > On 2/27/07, Matthias Wessendorf <ma...@apache.org> wrote:
> >>
> >> +1
> >>
> >>
> >> On 2/27/07, Mike Kienenberger <mk...@gmail.com> wrote:
> >> > +1
> >> >
> >> > On 2/26/07, Dennis Byrne <de...@dbyrne.net> wrote:
> >> > > Alright.  Here's my +1 binding.  Let's put the nail in this coffin.
> >> > >
> >> > > Dennis Byrne
> >> > >
> >> > > On 2/26/07, Paul McMahan < paulmcmahan@gmail.com> wrote:
> >> > > > Excellent observation, Dennis.  In Geronimo and a few other app
> >> > > > servers I am familiar with the user is provided with several knobs
> >> > > > that can affect classloading.  Ideally, a component designed to run
> >> in
> >> > > > different types of containers would make as few assumptions about
> >> its
> >> > > > container's classloader configuration as possible.  For example,
> >> > > > Geronimo's classloaders can have multiple immediate parents which
> >> > > > confuses code that thinks it can find resources (like TLDs) in the
> >> > > > app's classloader by walking up a direct lineage of classloaders
> >> using
> >> > > > getParent().  And like you say, factories and services like logging
> >> > > > can get confused when they key on classes that are available from
> >> > > > multiple classloaders.
> >> > > >
> >> > > > Another item somewhat related to this discussion that comes to mind
> >> is
> >> > > > how Geronimo provides a shared instance of the Dojo toolkit in a
> >> > > > preinstalled webapp that is deployed at the context
> >> "/dojo".  Webapps
> >> > > > can of course include their own private copy of the Dojo toolkit in
> >> > > > their WAR but they miss out on several benefits such as improved
> >> > > > resource caching across application contexts, smaller application
> >> > > > footprint, and having the ability to upgrade and otherwise manage
> >> the
> >> > > > Dojo component separately from their webapp.  I thought this might
> >> be
> >> > > > interesting to those working on Dojo/MyFaces integration.
> >> > > >
> >> > > > Best wishes,
> >> > > > Paul
> >> > > >
> >> > > > On 2/26/07, Dennis Byrne <de...@dbyrne.net> wrote:
> >> > > > >     Since JSF is part of the JEE 5 spec users don't need to
> >> include the
> >> > > > >
> >> > > > > > JSF jars or their dependencies in their webapps when deploying
> >> into
> >> > > > > > Geronimo 2.0.  This makes developing a webapp much easier but
> >> makes
> >> > > > > > developing JSF a little more tricky because the MyFaces jars
> >> are
> >> part
> >> > > > > > of the server runtime.
> >> > > > >
> >> > > > > Hi Paul,
> >> > > > >
> >> > > > > On this team there is an age old debate about how logging.  The
> >> gist is
> >> > > that
> >> > > > > we have static loggers all over the place.  This of course is not
> >> good
> >> > > > > because the jars are not going to be located in the war (where
> >> they are
> >> > > > > isolated by separate class loaders).
> >> > > > >
> >> > > > > Well, team ... we've never had a better reason to rip out the
> >> static
> >> > > > > loggers.  What do you say?
> >> > > > >
> >> > > > > > Best wishes,
> >> > > > > > Paul
> >> > > > > >
> >> > > > > >
> >> > > > > > On 2/26/07, Matthias Wessendorf <ma...@apache.org> wrote:
> >> > > > > > > geronimo2-SNAPSHOT
> >> > > > > > >
> >> > > > > > > you don't need to include the jsf-xxx jars
> >> > > > > > >
> >> > > > > > > A Java EE 5 compliant server has to ignore the jsf-xxx libs,
> >> shipped
> >> > > > > > > in WEB-INF/lib
> >> > > > > > > Since Tomcat 6.x and Jetty 6.x don't ship JSF, you have to
> >> include
> >> > > > > > > them in your lib, like in the past
> >> > > > > > >
> >> > > > > > > -M
> >> > > > > > >
> >> > > > > > > On 2/26/07, Martin Haimberger < martin.haimberger@gmail.com>
> >> wrote:
> >> > > > > > > > Sorry for spamming, but is there another Application Server
> >> which
> >> > > will
> >> > > > > > > > work with MyFaces 1.2 and Intellij Idea ?
> >> > > > > > > >
> >> > > > > > > > Regards,
> >> > > > > > > > Martin Haimberger
> >> > > > > > > >
> >> > > > > > > > On 2/26/07, Martin Haimberger <
> >> martin.haimberger@gmail.com>
> >> > > wrote:
> >> > > > > > > > > No nothing more. No Exception, nothing. I will try
> >> Jetty6.1.x, i
> >> > > > > hope
> >> > > > > > > > > the myfaces1.2 will start.
> >> > > > > > > > >
> >> > > > > > > > > Regards,
> >> > > > > > > > > Martin Haimberger
> >> > > > > > > > >
> >> > > > > > > > > On 2/26/07, Matthias Wessendorf <matzew@apache.org >
> >> wrote:
> >> > > > > > > > > > does the tomcat log say more?
> >> > > > > > > > > >
> >> > > > > > > > > > I am able to deploy a jsf 1.2 app with Jetty6.1.x
> >> > > > > > > > > >
> >> > > > > > > > > > -M
> >> > > > > > > > > >
> >> > > > > > > > > > On 2/26/07, Martin Haimberger <
> >> martin.haimberger@gmail.com>
> >> > > > > wrote:
> >> > > > > > > > > > > Hy *,
> >> > > > > > > > > > >
> >> > > > > > > > > > > i am going to help to develop myfaces 1.2. I have
> >> checked it
> >> > > > > out,
> >> > > > > > > > > > > compiled it (with some difficulties, because some
> >> jars
> >> were
> >> > > not
> >> > > > > > > > > > > found). I installed tomcat 6.0.9 alpha and i got this
> >> error:
> >> > > > > > > > > > >
> >> > > > > > > > > > > DEBUG [main] ( HtmlRenderKitImpl.java:112) - add
> >> Renderer
> >> > > family
> >> > > > > =
> >> > > > > > > > > > > javax.faces.SelectOne rendererType =
> >> javax.faces.Radio
> >> > > renderer
> >> > > > > class
> >> > > > > > > > > > > =
> >> > > > > org.apache.myfaces.renderkit.html.HtmlRadioRenderer
> >> > > > > > > > > > >   INFO [main] (FacesConfigurator.java:972) -
> >> Serialization
> >> > > > > provider :
> >> > > > > > > > > > > class
> >> > > > >
> >> > > org.apache.myfaces.shared_impl.util.serial.DefaultSerialFactory
> >> > > > > > > > > > > Feb 26, 2007 2:14:34 PM
> >> > > > > org.apache.catalina.core.StandardContext start
> >> > > > > > > > > > > SEVERE: Error listenerStart
> >> > > > > > > > > > > Feb 26, 2007 2:14:34 PM
> >> > > > > org.apache.catalina.core.StandardContext start
> >> > > > > > > > > > >
> >> > > > > > > > > > > I am running Intellij 6.0.4 and tomcat 6.0.9 on
> >> MacOsX.
> >> > > > > > > > > > >
> >> > > > > > > > > > > Has someone any idea what i did wrong?
> >> > > > > > > > > > >
> >> > > > > > > > > > > Regards,
> >> > > > > > > > > > > Martin Haimberger
> >> > > > > > > > > > >
> >> > > > > > > > > >
> >> > > > > > > > > >
> >> > > > > > > > > > --
> >> > > > > > > > > > Matthias Wessendorf
> >> > > > > > > > > > http://tinyurl.com/fmywh
> >> > > > > > > > > >
> >> > > > > > > > > > further stuff:
> >> > > > > > > > > > blog: http://jroller.com/page/mwessendorf
> >> > > > > > > > > > mail: mwessendorf-at-gmail-dot-com
> >> > > > > > > > > >
> >> > > > > > > > >
> >> > > > > > > >
> >> > > > > > >
> >> > > > > > >
> >> > > > > > > --
> >> > > > > > > Matthias Wessendorf
> >> > > > > > > http://tinyurl.com/fmywh
> >> > > > > > >
> >> > > > > > > further stuff:
> >> > > > > > > blog: http://jroller.com/page/mwessendorf
> >> > > > > > > mail: mwessendorf-at-gmail-dot-com
> >> > > > > > >
> >> > > > > >
> >> > > > >
> >> > > > >
> >> > > > >
> >> > > > > --
> >> > > > > Dennis Byrne
> >> > > >
> >> > >
> >> > >
> >> > >
> >> > > --
> >> > > Dennis Byrne
> >> >
> >>
> >>
> >> --
> >> Matthias Wessendorf
> >> http://tinyurl.com/fmywh
> >>
> >> further stuff:
> >> blog: http://jroller.com/page/mwessendorf
> >> mail: mwessendorf-at-gmail-dot-com
> >>
> >
>


-- 
Matthias Wessendorf
http://tinyurl.com/fmywh

further stuff:
blog: http://jroller.com/page/mwessendorf
mail: mwessendorf-at-gmail-dot-com

Re: [VOTE] Remove Static loggers from 1.2

Posted by Bernd Bohmann <be...@atanion.com>.
Hello,

what is the alternative?

How is this handled by the RI?

What is the performance impakt?

Why not a container can separate each jsf webapp with a separate 
classloader? Independent of the jsf implementation is provided by the 
container or not.

Can we remove commons logging and use jdk logging or something else?

Without any technical discussion you get my

-1

Regards

Bernd




Cagatay Civici wrote:
> +1 non-binding
> 
> On 2/27/07, Matthias Wessendorf <ma...@apache.org> wrote:
>>
>> +1
>>
>>
>> On 2/27/07, Mike Kienenberger <mk...@gmail.com> wrote:
>> > +1
>> >
>> > On 2/26/07, Dennis Byrne <de...@dbyrne.net> wrote:
>> > > Alright.  Here's my +1 binding.  Let's put the nail in this coffin.
>> > >
>> > > Dennis Byrne
>> > >
>> > > On 2/26/07, Paul McMahan < paulmcmahan@gmail.com> wrote:
>> > > > Excellent observation, Dennis.  In Geronimo and a few other app
>> > > > servers I am familiar with the user is provided with several knobs
>> > > > that can affect classloading.  Ideally, a component designed to run
>> in
>> > > > different types of containers would make as few assumptions about
>> its
>> > > > container's classloader configuration as possible.  For example,
>> > > > Geronimo's classloaders can have multiple immediate parents which
>> > > > confuses code that thinks it can find resources (like TLDs) in the
>> > > > app's classloader by walking up a direct lineage of classloaders
>> using
>> > > > getParent().  And like you say, factories and services like logging
>> > > > can get confused when they key on classes that are available from
>> > > > multiple classloaders.
>> > > >
>> > > > Another item somewhat related to this discussion that comes to mind
>> is
>> > > > how Geronimo provides a shared instance of the Dojo toolkit in a
>> > > > preinstalled webapp that is deployed at the context
>> "/dojo".  Webapps
>> > > > can of course include their own private copy of the Dojo toolkit in
>> > > > their WAR but they miss out on several benefits such as improved
>> > > > resource caching across application contexts, smaller application
>> > > > footprint, and having the ability to upgrade and otherwise manage
>> the
>> > > > Dojo component separately from their webapp.  I thought this might
>> be
>> > > > interesting to those working on Dojo/MyFaces integration.
>> > > >
>> > > > Best wishes,
>> > > > Paul
>> > > >
>> > > > On 2/26/07, Dennis Byrne <de...@dbyrne.net> wrote:
>> > > > >     Since JSF is part of the JEE 5 spec users don't need to
>> include the
>> > > > >
>> > > > > > JSF jars or their dependencies in their webapps when deploying
>> into
>> > > > > > Geronimo 2.0.  This makes developing a webapp much easier but
>> makes
>> > > > > > developing JSF a little more tricky because the MyFaces jars 
>> are
>> part
>> > > > > > of the server runtime.
>> > > > >
>> > > > > Hi Paul,
>> > > > >
>> > > > > On this team there is an age old debate about how logging.  The
>> gist is
>> > > that
>> > > > > we have static loggers all over the place.  This of course is not
>> good
>> > > > > because the jars are not going to be located in the war (where
>> they are
>> > > > > isolated by separate class loaders).
>> > > > >
>> > > > > Well, team ... we've never had a better reason to rip out the
>> static
>> > > > > loggers.  What do you say?
>> > > > >
>> > > > > > Best wishes,
>> > > > > > Paul
>> > > > > >
>> > > > > >
>> > > > > > On 2/26/07, Matthias Wessendorf <ma...@apache.org> wrote:
>> > > > > > > geronimo2-SNAPSHOT
>> > > > > > >
>> > > > > > > you don't need to include the jsf-xxx jars
>> > > > > > >
>> > > > > > > A Java EE 5 compliant server has to ignore the jsf-xxx libs,
>> shipped
>> > > > > > > in WEB-INF/lib
>> > > > > > > Since Tomcat 6.x and Jetty 6.x don't ship JSF, you have to
>> include
>> > > > > > > them in your lib, like in the past
>> > > > > > >
>> > > > > > > -M
>> > > > > > >
>> > > > > > > On 2/26/07, Martin Haimberger < martin.haimberger@gmail.com>
>> wrote:
>> > > > > > > > Sorry for spamming, but is there another Application Server
>> which
>> > > will
>> > > > > > > > work with MyFaces 1.2 and Intellij Idea ?
>> > > > > > > >
>> > > > > > > > Regards,
>> > > > > > > > Martin Haimberger
>> > > > > > > >
>> > > > > > > > On 2/26/07, Martin Haimberger < 
>> martin.haimberger@gmail.com>
>> > > wrote:
>> > > > > > > > > No nothing more. No Exception, nothing. I will try
>> Jetty6.1.x, i
>> > > > > hope
>> > > > > > > > > the myfaces1.2 will start.
>> > > > > > > > >
>> > > > > > > > > Regards,
>> > > > > > > > > Martin Haimberger
>> > > > > > > > >
>> > > > > > > > > On 2/26/07, Matthias Wessendorf <matzew@apache.org >
>> wrote:
>> > > > > > > > > > does the tomcat log say more?
>> > > > > > > > > >
>> > > > > > > > > > I am able to deploy a jsf 1.2 app with Jetty6.1.x
>> > > > > > > > > >
>> > > > > > > > > > -M
>> > > > > > > > > >
>> > > > > > > > > > On 2/26/07, Martin Haimberger <
>> martin.haimberger@gmail.com>
>> > > > > wrote:
>> > > > > > > > > > > Hy *,
>> > > > > > > > > > >
>> > > > > > > > > > > i am going to help to develop myfaces 1.2. I have
>> checked it
>> > > > > out,
>> > > > > > > > > > > compiled it (with some difficulties, because some 
>> jars
>> were
>> > > not
>> > > > > > > > > > > found). I installed tomcat 6.0.9 alpha and i got this
>> error:
>> > > > > > > > > > >
>> > > > > > > > > > > DEBUG [main] ( HtmlRenderKitImpl.java:112) - add
>> Renderer
>> > > family
>> > > > > =
>> > > > > > > > > > > javax.faces.SelectOne rendererType = 
>> javax.faces.Radio
>> > > renderer
>> > > > > class
>> > > > > > > > > > > =
>> > > > > org.apache.myfaces.renderkit.html.HtmlRadioRenderer
>> > > > > > > > > > >   INFO [main] (FacesConfigurator.java:972) -
>> Serialization
>> > > > > provider :
>> > > > > > > > > > > class
>> > > > >
>> > > org.apache.myfaces.shared_impl.util.serial.DefaultSerialFactory
>> > > > > > > > > > > Feb 26, 2007 2:14:34 PM
>> > > > > org.apache.catalina.core.StandardContext start
>> > > > > > > > > > > SEVERE: Error listenerStart
>> > > > > > > > > > > Feb 26, 2007 2:14:34 PM
>> > > > > org.apache.catalina.core.StandardContext start
>> > > > > > > > > > >
>> > > > > > > > > > > I am running Intellij 6.0.4 and tomcat 6.0.9 on
>> MacOsX.
>> > > > > > > > > > >
>> > > > > > > > > > > Has someone any idea what i did wrong?
>> > > > > > > > > > >
>> > > > > > > > > > > Regards,
>> > > > > > > > > > > Martin Haimberger
>> > > > > > > > > > >
>> > > > > > > > > >
>> > > > > > > > > >
>> > > > > > > > > > --
>> > > > > > > > > > Matthias Wessendorf
>> > > > > > > > > > http://tinyurl.com/fmywh
>> > > > > > > > > >
>> > > > > > > > > > further stuff:
>> > > > > > > > > > blog: http://jroller.com/page/mwessendorf
>> > > > > > > > > > mail: mwessendorf-at-gmail-dot-com
>> > > > > > > > > >
>> > > > > > > > >
>> > > > > > > >
>> > > > > > >
>> > > > > > >
>> > > > > > > --
>> > > > > > > Matthias Wessendorf
>> > > > > > > http://tinyurl.com/fmywh
>> > > > > > >
>> > > > > > > further stuff:
>> > > > > > > blog: http://jroller.com/page/mwessendorf
>> > > > > > > mail: mwessendorf-at-gmail-dot-com
>> > > > > > >
>> > > > > >
>> > > > >
>> > > > >
>> > > > >
>> > > > > --
>> > > > > Dennis Byrne
>> > > >
>> > >
>> > >
>> > >
>> > > --
>> > > Dennis Byrne
>> >
>>
>>
>> -- 
>> Matthias Wessendorf
>> http://tinyurl.com/fmywh
>>
>> further stuff:
>> blog: http://jroller.com/page/mwessendorf
>> mail: mwessendorf-at-gmail-dot-com
>>
> 

Re: [VOTE] Remove Static loggers from 1.2

Posted by Craig McClanahan <cr...@apache.org>.
On 2/26/07, Cagatay Civici <ca...@gmail.com> wrote:
> +1 non-binding
>

Just as a procedural note, the only votes that PMC members have
binding votes on is releases.  For technical issues (like this one),
all committer votes are not only binding, but a -1 (supported by
adequate reasoning) is a blocker (whereas a release vote is majority
rules).

Craig

Re: [VOTE] Remove Static loggers from 1.2

Posted by Cagatay Civici <ca...@gmail.com>.
+1 non-binding

On 2/27/07, Matthias Wessendorf <ma...@apache.org> wrote:
>
> +1
>
>
> On 2/27/07, Mike Kienenberger <mk...@gmail.com> wrote:
> > +1
> >
> > On 2/26/07, Dennis Byrne <de...@dbyrne.net> wrote:
> > > Alright.  Here's my +1 binding.  Let's put the nail in this coffin.
> > >
> > > Dennis Byrne
> > >
> > > On 2/26/07, Paul McMahan < paulmcmahan@gmail.com> wrote:
> > > > Excellent observation, Dennis.  In Geronimo and a few other app
> > > > servers I am familiar with the user is provided with several knobs
> > > > that can affect classloading.  Ideally, a component designed to run
> in
> > > > different types of containers would make as few assumptions about
> its
> > > > container's classloader configuration as possible.  For example,
> > > > Geronimo's classloaders can have multiple immediate parents which
> > > > confuses code that thinks it can find resources (like TLDs) in the
> > > > app's classloader by walking up a direct lineage of classloaders
> using
> > > > getParent().  And like you say, factories and services like logging
> > > > can get confused when they key on classes that are available from
> > > > multiple classloaders.
> > > >
> > > > Another item somewhat related to this discussion that comes to mind
> is
> > > > how Geronimo provides a shared instance of the Dojo toolkit in a
> > > > preinstalled webapp that is deployed at the context
> "/dojo".  Webapps
> > > > can of course include their own private copy of the Dojo toolkit in
> > > > their WAR but they miss out on several benefits such as improved
> > > > resource caching across application contexts, smaller application
> > > > footprint, and having the ability to upgrade and otherwise manage
> the
> > > > Dojo component separately from their webapp.  I thought this might
> be
> > > > interesting to those working on Dojo/MyFaces integration.
> > > >
> > > > Best wishes,
> > > > Paul
> > > >
> > > > On 2/26/07, Dennis Byrne <de...@dbyrne.net> wrote:
> > > > >     Since JSF is part of the JEE 5 spec users don't need to
> include the
> > > > >
> > > > > > JSF jars or their dependencies in their webapps when deploying
> into
> > > > > > Geronimo 2.0.  This makes developing a webapp much easier but
> makes
> > > > > > developing JSF a little more tricky because the MyFaces jars are
> part
> > > > > > of the server runtime.
> > > > >
> > > > > Hi Paul,
> > > > >
> > > > > On this team there is an age old debate about how logging.  The
> gist is
> > > that
> > > > > we have static loggers all over the place.  This of course is not
> good
> > > > > because the jars are not going to be located in the war (where
> they are
> > > > > isolated by separate class loaders).
> > > > >
> > > > > Well, team ... we've never had a better reason to rip out the
> static
> > > > > loggers.  What do you say?
> > > > >
> > > > > > Best wishes,
> > > > > > Paul
> > > > > >
> > > > > >
> > > > > > On 2/26/07, Matthias Wessendorf <ma...@apache.org> wrote:
> > > > > > > geronimo2-SNAPSHOT
> > > > > > >
> > > > > > > you don't need to include the jsf-xxx jars
> > > > > > >
> > > > > > > A Java EE 5 compliant server has to ignore the jsf-xxx libs,
> shipped
> > > > > > > in WEB-INF/lib
> > > > > > > Since Tomcat 6.x and Jetty 6.x don't ship JSF, you have to
> include
> > > > > > > them in your lib, like in the past
> > > > > > >
> > > > > > > -M
> > > > > > >
> > > > > > > On 2/26/07, Martin Haimberger < martin.haimberger@gmail.com>
> wrote:
> > > > > > > > Sorry for spamming, but is there another Application Server
> which
> > > will
> > > > > > > > work with MyFaces 1.2 and Intellij Idea ?
> > > > > > > >
> > > > > > > > Regards,
> > > > > > > > Martin Haimberger
> > > > > > > >
> > > > > > > > On 2/26/07, Martin Haimberger < martin.haimberger@gmail.com>
> > > wrote:
> > > > > > > > > No nothing more. No Exception, nothing. I will try
> Jetty6.1.x, i
> > > > > hope
> > > > > > > > > the myfaces1.2 will start.
> > > > > > > > >
> > > > > > > > > Regards,
> > > > > > > > > Martin Haimberger
> > > > > > > > >
> > > > > > > > > On 2/26/07, Matthias Wessendorf <matzew@apache.org >
> wrote:
> > > > > > > > > > does the tomcat log say more?
> > > > > > > > > >
> > > > > > > > > > I am able to deploy a jsf 1.2 app with Jetty6.1.x
> > > > > > > > > >
> > > > > > > > > > -M
> > > > > > > > > >
> > > > > > > > > > On 2/26/07, Martin Haimberger <
> martin.haimberger@gmail.com>
> > > > > wrote:
> > > > > > > > > > > Hy *,
> > > > > > > > > > >
> > > > > > > > > > > i am going to help to develop myfaces 1.2. I have
> checked it
> > > > > out,
> > > > > > > > > > > compiled it (with some difficulties, because some jars
> were
> > > not
> > > > > > > > > > > found). I installed tomcat 6.0.9 alpha and i got this
> error:
> > > > > > > > > > >
> > > > > > > > > > > DEBUG [main] ( HtmlRenderKitImpl.java:112) - add
> Renderer
> > > family
> > > > > =
> > > > > > > > > > > javax.faces.SelectOne rendererType = javax.faces.Radio
> > > renderer
> > > > > class
> > > > > > > > > > > =
> > > > > org.apache.myfaces.renderkit.html.HtmlRadioRenderer
> > > > > > > > > > >   INFO [main] (FacesConfigurator.java:972) -
> Serialization
> > > > > provider :
> > > > > > > > > > > class
> > > > >
> > > org.apache.myfaces.shared_impl.util.serial.DefaultSerialFactory
> > > > > > > > > > > Feb 26, 2007 2:14:34 PM
> > > > > org.apache.catalina.core.StandardContext start
> > > > > > > > > > > SEVERE: Error listenerStart
> > > > > > > > > > > Feb 26, 2007 2:14:34 PM
> > > > > org.apache.catalina.core.StandardContext start
> > > > > > > > > > >
> > > > > > > > > > > I am running Intellij 6.0.4 and tomcat 6.0.9 on
> MacOsX.
> > > > > > > > > > >
> > > > > > > > > > > Has someone any idea what i did wrong?
> > > > > > > > > > >
> > > > > > > > > > > Regards,
> > > > > > > > > > > Martin Haimberger
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > --
> > > > > > > > > > Matthias Wessendorf
> > > > > > > > > > http://tinyurl.com/fmywh
> > > > > > > > > >
> > > > > > > > > > further stuff:
> > > > > > > > > > blog: http://jroller.com/page/mwessendorf
> > > > > > > > > > mail: mwessendorf-at-gmail-dot-com
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > Matthias Wessendorf
> > > > > > > http://tinyurl.com/fmywh
> > > > > > >
> > > > > > > further stuff:
> > > > > > > blog: http://jroller.com/page/mwessendorf
> > > > > > > mail: mwessendorf-at-gmail-dot-com
> > > > > > >
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Dennis Byrne
> > > >
> > >
> > >
> > >
> > > --
> > > Dennis Byrne
> >
>
>
> --
> Matthias Wessendorf
> http://tinyurl.com/fmywh
>
> further stuff:
> blog: http://jroller.com/page/mwessendorf
> mail: mwessendorf-at-gmail-dot-com
>

Re: [VOTE] Remove Static loggers from 1.2

Posted by Matthias Wessendorf <ma...@apache.org>.
+1


On 2/27/07, Mike Kienenberger <mk...@gmail.com> wrote:
> +1
>
> On 2/26/07, Dennis Byrne <de...@dbyrne.net> wrote:
> > Alright.  Here's my +1 binding.  Let's put the nail in this coffin.
> >
> > Dennis Byrne
> >
> > On 2/26/07, Paul McMahan < paulmcmahan@gmail.com> wrote:
> > > Excellent observation, Dennis.  In Geronimo and a few other app
> > > servers I am familiar with the user is provided with several knobs
> > > that can affect classloading.  Ideally, a component designed to run in
> > > different types of containers would make as few assumptions about its
> > > container's classloader configuration as possible.  For example,
> > > Geronimo's classloaders can have multiple immediate parents which
> > > confuses code that thinks it can find resources (like TLDs) in the
> > > app's classloader by walking up a direct lineage of classloaders using
> > > getParent().  And like you say, factories and services like logging
> > > can get confused when they key on classes that are available from
> > > multiple classloaders.
> > >
> > > Another item somewhat related to this discussion that comes to mind is
> > > how Geronimo provides a shared instance of the Dojo toolkit in a
> > > preinstalled webapp that is deployed at the context "/dojo".  Webapps
> > > can of course include their own private copy of the Dojo toolkit in
> > > their WAR but they miss out on several benefits such as improved
> > > resource caching across application contexts, smaller application
> > > footprint, and having the ability to upgrade and otherwise manage the
> > > Dojo component separately from their webapp.  I thought this might be
> > > interesting to those working on Dojo/MyFaces integration.
> > >
> > > Best wishes,
> > > Paul
> > >
> > > On 2/26/07, Dennis Byrne <de...@dbyrne.net> wrote:
> > > >     Since JSF is part of the JEE 5 spec users don't need to include the
> > > >
> > > > > JSF jars or their dependencies in their webapps when deploying into
> > > > > Geronimo 2.0.  This makes developing a webapp much easier but makes
> > > > > developing JSF a little more tricky because the MyFaces jars are part
> > > > > of the server runtime.
> > > >
> > > > Hi Paul,
> > > >
> > > > On this team there is an age old debate about how logging.  The gist is
> > that
> > > > we have static loggers all over the place.  This of course is not good
> > > > because the jars are not going to be located in the war (where they are
> > > > isolated by separate class loaders).
> > > >
> > > > Well, team ... we've never had a better reason to rip out the static
> > > > loggers.  What do you say?
> > > >
> > > > > Best wishes,
> > > > > Paul
> > > > >
> > > > >
> > > > > On 2/26/07, Matthias Wessendorf <ma...@apache.org> wrote:
> > > > > > geronimo2-SNAPSHOT
> > > > > >
> > > > > > you don't need to include the jsf-xxx jars
> > > > > >
> > > > > > A Java EE 5 compliant server has to ignore the jsf-xxx libs, shipped
> > > > > > in WEB-INF/lib
> > > > > > Since Tomcat 6.x and Jetty 6.x don't ship JSF, you have to include
> > > > > > them in your lib, like in the past
> > > > > >
> > > > > > -M
> > > > > >
> > > > > > On 2/26/07, Martin Haimberger < martin.haimberger@gmail.com> wrote:
> > > > > > > Sorry for spamming, but is there another Application Server which
> > will
> > > > > > > work with MyFaces 1.2 and Intellij Idea ?
> > > > > > >
> > > > > > > Regards,
> > > > > > > Martin Haimberger
> > > > > > >
> > > > > > > On 2/26/07, Martin Haimberger < martin.haimberger@gmail.com>
> > wrote:
> > > > > > > > No nothing more. No Exception, nothing. I will try Jetty6.1.x, i
> > > > hope
> > > > > > > > the myfaces1.2 will start.
> > > > > > > >
> > > > > > > > Regards,
> > > > > > > > Martin Haimberger
> > > > > > > >
> > > > > > > > On 2/26/07, Matthias Wessendorf <matzew@apache.org > wrote:
> > > > > > > > > does the tomcat log say more?
> > > > > > > > >
> > > > > > > > > I am able to deploy a jsf 1.2 app with Jetty6.1.x
> > > > > > > > >
> > > > > > > > > -M
> > > > > > > > >
> > > > > > > > > On 2/26/07, Martin Haimberger < martin.haimberger@gmail.com>
> > > > wrote:
> > > > > > > > > > Hy *,
> > > > > > > > > >
> > > > > > > > > > i am going to help to develop myfaces 1.2. I have checked it
> > > > out,
> > > > > > > > > > compiled it (with some difficulties, because some jars were
> > not
> > > > > > > > > > found). I installed tomcat 6.0.9 alpha and i got this error:
> > > > > > > > > >
> > > > > > > > > > DEBUG [main] ( HtmlRenderKitImpl.java:112) - add Renderer
> > family
> > > > =
> > > > > > > > > > javax.faces.SelectOne rendererType = javax.faces.Radio
> > renderer
> > > > class
> > > > > > > > > > =
> > > > org.apache.myfaces.renderkit.html.HtmlRadioRenderer
> > > > > > > > > >   INFO [main] (FacesConfigurator.java:972) - Serialization
> > > > provider :
> > > > > > > > > > class
> > > >
> > org.apache.myfaces.shared_impl.util.serial.DefaultSerialFactory
> > > > > > > > > > Feb 26, 2007 2:14:34 PM
> > > > org.apache.catalina.core.StandardContext start
> > > > > > > > > > SEVERE: Error listenerStart
> > > > > > > > > > Feb 26, 2007 2:14:34 PM
> > > > org.apache.catalina.core.StandardContext start
> > > > > > > > > >
> > > > > > > > > > I am running Intellij 6.0.4 and tomcat 6.0.9 on MacOsX.
> > > > > > > > > >
> > > > > > > > > > Has someone any idea what i did wrong?
> > > > > > > > > >
> > > > > > > > > > Regards,
> > > > > > > > > > Martin Haimberger
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > --
> > > > > > > > > Matthias Wessendorf
> > > > > > > > > http://tinyurl.com/fmywh
> > > > > > > > >
> > > > > > > > > further stuff:
> > > > > > > > > blog: http://jroller.com/page/mwessendorf
> > > > > > > > > mail: mwessendorf-at-gmail-dot-com
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Matthias Wessendorf
> > > > > > http://tinyurl.com/fmywh
> > > > > >
> > > > > > further stuff:
> > > > > > blog: http://jroller.com/page/mwessendorf
> > > > > > mail: mwessendorf-at-gmail-dot-com
> > > > > >
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Dennis Byrne
> > >
> >
> >
> >
> > --
> > Dennis Byrne
>


-- 
Matthias Wessendorf
http://tinyurl.com/fmywh

further stuff:
blog: http://jroller.com/page/mwessendorf
mail: mwessendorf-at-gmail-dot-com

Re: [VOTE] Remove Static loggers from 1.2

Posted by Mike Kienenberger <mk...@gmail.com>.
+1

On 2/26/07, Dennis Byrne <de...@dbyrne.net> wrote:
> Alright.  Here's my +1 binding.  Let's put the nail in this coffin.
>
> Dennis Byrne
>
> On 2/26/07, Paul McMahan < paulmcmahan@gmail.com> wrote:
> > Excellent observation, Dennis.  In Geronimo and a few other app
> > servers I am familiar with the user is provided with several knobs
> > that can affect classloading.  Ideally, a component designed to run in
> > different types of containers would make as few assumptions about its
> > container's classloader configuration as possible.  For example,
> > Geronimo's classloaders can have multiple immediate parents which
> > confuses code that thinks it can find resources (like TLDs) in the
> > app's classloader by walking up a direct lineage of classloaders using
> > getParent().  And like you say, factories and services like logging
> > can get confused when they key on classes that are available from
> > multiple classloaders.
> >
> > Another item somewhat related to this discussion that comes to mind is
> > how Geronimo provides a shared instance of the Dojo toolkit in a
> > preinstalled webapp that is deployed at the context "/dojo".  Webapps
> > can of course include their own private copy of the Dojo toolkit in
> > their WAR but they miss out on several benefits such as improved
> > resource caching across application contexts, smaller application
> > footprint, and having the ability to upgrade and otherwise manage the
> > Dojo component separately from their webapp.  I thought this might be
> > interesting to those working on Dojo/MyFaces integration.
> >
> > Best wishes,
> > Paul
> >
> > On 2/26/07, Dennis Byrne <de...@dbyrne.net> wrote:
> > >     Since JSF is part of the JEE 5 spec users don't need to include the
> > >
> > > > JSF jars or their dependencies in their webapps when deploying into
> > > > Geronimo 2.0.  This makes developing a webapp much easier but makes
> > > > developing JSF a little more tricky because the MyFaces jars are part
> > > > of the server runtime.
> > >
> > > Hi Paul,
> > >
> > > On this team there is an age old debate about how logging.  The gist is
> that
> > > we have static loggers all over the place.  This of course is not good
> > > because the jars are not going to be located in the war (where they are
> > > isolated by separate class loaders).
> > >
> > > Well, team ... we've never had a better reason to rip out the static
> > > loggers.  What do you say?
> > >
> > > > Best wishes,
> > > > Paul
> > > >
> > > >
> > > > On 2/26/07, Matthias Wessendorf <ma...@apache.org> wrote:
> > > > > geronimo2-SNAPSHOT
> > > > >
> > > > > you don't need to include the jsf-xxx jars
> > > > >
> > > > > A Java EE 5 compliant server has to ignore the jsf-xxx libs, shipped
> > > > > in WEB-INF/lib
> > > > > Since Tomcat 6.x and Jetty 6.x don't ship JSF, you have to include
> > > > > them in your lib, like in the past
> > > > >
> > > > > -M
> > > > >
> > > > > On 2/26/07, Martin Haimberger < martin.haimberger@gmail.com> wrote:
> > > > > > Sorry for spamming, but is there another Application Server which
> will
> > > > > > work with MyFaces 1.2 and Intellij Idea ?
> > > > > >
> > > > > > Regards,
> > > > > > Martin Haimberger
> > > > > >
> > > > > > On 2/26/07, Martin Haimberger < martin.haimberger@gmail.com>
> wrote:
> > > > > > > No nothing more. No Exception, nothing. I will try Jetty6.1.x, i
> > > hope
> > > > > > > the myfaces1.2 will start.
> > > > > > >
> > > > > > > Regards,
> > > > > > > Martin Haimberger
> > > > > > >
> > > > > > > On 2/26/07, Matthias Wessendorf <matzew@apache.org > wrote:
> > > > > > > > does the tomcat log say more?
> > > > > > > >
> > > > > > > > I am able to deploy a jsf 1.2 app with Jetty6.1.x
> > > > > > > >
> > > > > > > > -M
> > > > > > > >
> > > > > > > > On 2/26/07, Martin Haimberger < martin.haimberger@gmail.com>
> > > wrote:
> > > > > > > > > Hy *,
> > > > > > > > >
> > > > > > > > > i am going to help to develop myfaces 1.2. I have checked it
> > > out,
> > > > > > > > > compiled it (with some difficulties, because some jars were
> not
> > > > > > > > > found). I installed tomcat 6.0.9 alpha and i got this error:
> > > > > > > > >
> > > > > > > > > DEBUG [main] ( HtmlRenderKitImpl.java:112) - add Renderer
> family
> > > =
> > > > > > > > > javax.faces.SelectOne rendererType = javax.faces.Radio
> renderer
> > > class
> > > > > > > > > =
> > > org.apache.myfaces.renderkit.html.HtmlRadioRenderer
> > > > > > > > >   INFO [main] (FacesConfigurator.java:972) - Serialization
> > > provider :
> > > > > > > > > class
> > >
> org.apache.myfaces.shared_impl.util.serial.DefaultSerialFactory
> > > > > > > > > Feb 26, 2007 2:14:34 PM
> > > org.apache.catalina.core.StandardContext start
> > > > > > > > > SEVERE: Error listenerStart
> > > > > > > > > Feb 26, 2007 2:14:34 PM
> > > org.apache.catalina.core.StandardContext start
> > > > > > > > >
> > > > > > > > > I am running Intellij 6.0.4 and tomcat 6.0.9 on MacOsX.
> > > > > > > > >
> > > > > > > > > Has someone any idea what i did wrong?
> > > > > > > > >
> > > > > > > > > Regards,
> > > > > > > > > Martin Haimberger
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > --
> > > > > > > > Matthias Wessendorf
> > > > > > > > http://tinyurl.com/fmywh
> > > > > > > >
> > > > > > > > further stuff:
> > > > > > > > blog: http://jroller.com/page/mwessendorf
> > > > > > > > mail: mwessendorf-at-gmail-dot-com
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Matthias Wessendorf
> > > > > http://tinyurl.com/fmywh
> > > > >
> > > > > further stuff:
> > > > > blog: http://jroller.com/page/mwessendorf
> > > > > mail: mwessendorf-at-gmail-dot-com
> > > > >
> > > >
> > >
> > >
> > >
> > > --
> > > Dennis Byrne
> >
>
>
>
> --
> Dennis Byrne

Re: [VOTE] Remove Static loggers from 1.2

Posted by Manfred Geiler <ma...@gmail.com>.
-0.9 for removing commons-logging from jsf1.2 branch (now)

Explanation:
In the near future we will have to manage two "branches" that
originate from the same source: jsf 1.1.x and 1.2.x. Making massive
changes to the jsf1.2 codebase that are NOT alone based on jsf 1.1 and
1.2 spec differences are no good idea IMHO. This would make it much
more difficult to apply the same fix patche to both branches.

In the far future when we come to a point where we have the feeling
that the majority of code lines is different (ie. the two branches
went their own way and no longer have much common source) we can do
such changes in the jsf1.2 codebase. But not now please.

--Manfred



On 2/27/07, Grant Smith <wo...@gmail.com> wrote:
> +1 for removing static, +1 for using java.util.logging. I'm also somewhat
> against using commons logging; what real benefit would it afford us ?
>
> On 2/27/07, Werner Punz <we...@gmail.com> wrote:
> > good point if you can hook commons.logging (I know this is somewhat
> > insane because commons is just a meta logger)
> > below it, I do not know the core java logging api good enough
> > but every dependency we can remove is a + from me.
> >
> > Problem is if we cannot provide a path to hook commons logging into
> > it we get a huge clash with application and server vendors which
> > build upon that lib.
> >
> >
> > Mathias Brökelmann schrieb:
> > > +1 for removing the static.
> > >
> > > What is about java.util.logging? Can/Should we use it for 1.2?
> > >
> > > IMO it is better to use java.util.logging. Apart from the unusable
> > > default implementation for java.util.logging the reason not to use it
> > > in myfaces 1.1 was the dependency to java 1.4. But jsf 1.2 will only
> > > run with java 5 or higher. So that should not be the problem now. The
> > > default implementation should also not be a problem. IMO it is out of
> > > scope of myfaces. The container vendor is responsible to supply a
> > > better solution as it is done for tomcat. And even if that is not the
> > > case the user might plug its own implementation into
> > > java.util.logging.
> > >
> > > 2007/2/27, Dennis Byrne <de...@dbyrne.net>:
> > >> Alright.  Here's my +1 binding.  Let's put the nail in this coffin.
> > >>
> > >> Dennis Byrne
> >
> >
>
>
>
> --
> Grant Smith
>

Re: [VOTE] Remove Static loggers from 1.2

Posted by Grant Smith <wo...@gmail.com>.
+1 for removing static, +1 for using java.util.logging. I'm also somewhat
against using commons logging; what real benefit would it afford us ?

On 2/27/07, Werner Punz <we...@gmail.com> wrote:
>
> good point if you can hook commons.logging (I know this is somewhat
> insane because commons is just a meta logger)
> below it, I do not know the core java logging api good enough
> but every dependency we can remove is a + from me.
>
> Problem is if we cannot provide a path to hook commons logging into
> it we get a huge clash with application and server vendors which
> build upon that lib.
>
>
> Mathias Brökelmann schrieb:
> > +1 for removing the static.
> >
> > What is about java.util.logging? Can/Should we use it for 1.2?
> >
> > IMO it is better to use java.util.logging. Apart from the unusable
> > default implementation for java.util.logging the reason not to use it
> > in myfaces 1.1 was the dependency to java 1.4. But jsf 1.2 will only
> > run with java 5 or higher. So that should not be the problem now. The
> > default implementation should also not be a problem. IMO it is out of
> > scope of myfaces. The container vendor is responsible to supply a
> > better solution as it is done for tomcat. And even if that is not the
> > case the user might plug its own implementation into
> > java.util.logging.
> >
> > 2007/2/27, Dennis Byrne <de...@dbyrne.net>:
> >> Alright.  Here's my +1 binding.  Let's put the nail in this coffin.
> >>
> >> Dennis Byrne
>
>


-- 
Grant Smith

Re: [VOTE] Remove Static loggers from 1.2

Posted by Paul Spencer <pa...@apache.org>.
+1 for removing static logging.

-1 for java.util.logging. I like the freedom that commons logging 
provides.  In my case, I use log4j to email log entries that meet a 
specific criteria while others are written to a rotating log.  Their may 
be way to do this using java.util.logging, I am pretty invested in 
commons logging and log4j to change overnight.

Paul Spencer



Werner Punz wrote:
> good point if you can hook commons.logging (I know this is somewhat
> insane because commons is just a meta logger)
> below it, I do not know the core java logging api good enough
> but every dependency we can remove is a + from me.
> 
> Problem is if we cannot provide a path to hook commons logging into
> it we get a huge clash with application and server vendors which
> build upon that lib.
> 
> 
> Mathias Brökelmann schrieb:
>> +1 for removing the static.
>>
>> What is about java.util.logging? Can/Should we use it for 1.2?
>>
>> IMO it is better to use java.util.logging. Apart from the unusable
>> default implementation for java.util.logging the reason not to use it
>> in myfaces 1.1 was the dependency to java 1.4. But jsf 1.2 will only
>> run with java 5 or higher. So that should not be the problem now. The
>> default implementation should also not be a problem. IMO it is out of
>> scope of myfaces. The container vendor is responsible to supply a
>> better solution as it is done for tomcat. And even if that is not the
>> case the user might plug its own implementation into
>> java.util.logging.
>>
>> 2007/2/27, Dennis Byrne <de...@dbyrne.net>:
>>> Alright.  Here's my +1 binding.  Let's put the nail in this coffin.
>>>
>>> Dennis Byrne
> 
> 


Re: [VOTE] Remove Static loggers from 1.2

Posted by Werner Punz <we...@gmail.com>.
good point if you can hook commons.logging (I know this is somewhat
insane because commons is just a meta logger)
below it, I do not know the core java logging api good enough
but every dependency we can remove is a + from me.

Problem is if we cannot provide a path to hook commons logging into
it we get a huge clash with application and server vendors which
build upon that lib.


Mathias Brökelmann schrieb:
> +1 for removing the static.
> 
> What is about java.util.logging? Can/Should we use it for 1.2?
> 
> IMO it is better to use java.util.logging. Apart from the unusable
> default implementation for java.util.logging the reason not to use it
> in myfaces 1.1 was the dependency to java 1.4. But jsf 1.2 will only
> run with java 5 or higher. So that should not be the problem now. The
> default implementation should also not be a problem. IMO it is out of
> scope of myfaces. The container vendor is responsible to supply a
> better solution as it is done for tomcat. And even if that is not the
> case the user might plug its own implementation into
> java.util.logging.
> 
> 2007/2/27, Dennis Byrne <de...@dbyrne.net>:
>> Alright.  Here's my +1 binding.  Let's put the nail in this coffin.
>>
>> Dennis Byrne


Re: [VOTE] Remove Static loggers from 1.2

Posted by Mathias Brökelmann <mb...@googlemail.com>.
+1 for removing the static.

What is about java.util.logging? Can/Should we use it for 1.2?

IMO it is better to use java.util.logging. Apart from the unusable
default implementation for java.util.logging the reason not to use it
in myfaces 1.1 was the dependency to java 1.4. But jsf 1.2 will only
run with java 5 or higher. So that should not be the problem now. The
default implementation should also not be a problem. IMO it is out of
scope of myfaces. The container vendor is responsible to supply a
better solution as it is done for tomcat. And even if that is not the
case the user might plug its own implementation into
java.util.logging.

2007/2/27, Dennis Byrne <de...@dbyrne.net>:
> Alright.  Here's my +1 binding.  Let's put the nail in this coffin.
>
> Dennis Byrne
>
> On 2/26/07, Paul McMahan < paulmcmahan@gmail.com> wrote:
> > Excellent observation, Dennis.  In Geronimo and a few other app
> > servers I am familiar with the user is provided with several knobs
> > that can affect classloading.  Ideally, a component designed to run in
> > different types of containers would make as few assumptions about its
> > container's classloader configuration as possible.  For example,
> > Geronimo's classloaders can have multiple immediate parents which
> > confuses code that thinks it can find resources (like TLDs) in the
> > app's classloader by walking up a direct lineage of classloaders using
> > getParent().  And like you say, factories and services like logging
> > can get confused when they key on classes that are available from
> > multiple classloaders.
> >
> > Another item somewhat related to this discussion that comes to mind is
> > how Geronimo provides a shared instance of the Dojo toolkit in a
> > preinstalled webapp that is deployed at the context "/dojo".  Webapps
> > can of course include their own private copy of the Dojo toolkit in
> > their WAR but they miss out on several benefits such as improved
> > resource caching across application contexts, smaller application
> > footprint, and having the ability to upgrade and otherwise manage the
> > Dojo component separately from their webapp.  I thought this might be
> > interesting to those working on Dojo/MyFaces integration.
> >
> > Best wishes,
> > Paul
> >
> > On 2/26/07, Dennis Byrne <de...@dbyrne.net> wrote:
> > >     Since JSF is part of the JEE 5 spec users don't need to include the
> > >
> > > > JSF jars or their dependencies in their webapps when deploying into
> > > > Geronimo 2.0.  This makes developing a webapp much easier but makes
> > > > developing JSF a little more tricky because the MyFaces jars are part
> > > > of the server runtime.
> > >
> > > Hi Paul,
> > >
> > > On this team there is an age old debate about how logging.  The gist is
> that
> > > we have static loggers all over the place.  This of course is not good
> > > because the jars are not going to be located in the war (where they are
> > > isolated by separate class loaders).
> > >
> > > Well, team ... we've never had a better reason to rip out the static
> > > loggers.  What do you say?
> > >
> > > > Best wishes,
> > > > Paul
> > > >
> > > >
> > > > On 2/26/07, Matthias Wessendorf <ma...@apache.org> wrote:
> > > > > geronimo2-SNAPSHOT
> > > > >
> > > > > you don't need to include the jsf-xxx jars
> > > > >
> > > > > A Java EE 5 compliant server has to ignore the jsf-xxx libs, shipped
> > > > > in WEB-INF/lib
> > > > > Since Tomcat 6.x and Jetty 6.x don't ship JSF, you have to include
> > > > > them in your lib, like in the past
> > > > >
> > > > > -M
> > > > >
> > > > > On 2/26/07, Martin Haimberger < martin.haimberger@gmail.com> wrote:
> > > > > > Sorry for spamming, but is there another Application Server which
> will
> > > > > > work with MyFaces 1.2 and Intellij Idea ?
> > > > > >
> > > > > > Regards,
> > > > > > Martin Haimberger
> > > > > >
> > > > > > On 2/26/07, Martin Haimberger < martin.haimberger@gmail.com>
> wrote:
> > > > > > > No nothing more. No Exception, nothing. I will try Jetty6.1.x, i
> > > hope
> > > > > > > the myfaces1.2 will start.
> > > > > > >
> > > > > > > Regards,
> > > > > > > Martin Haimberger
> > > > > > >
> > > > > > > On 2/26/07, Matthias Wessendorf <matzew@apache.org > wrote:
> > > > > > > > does the tomcat log say more?
> > > > > > > >
> > > > > > > > I am able to deploy a jsf 1.2 app with Jetty6.1.x
> > > > > > > >
> > > > > > > > -M
> > > > > > > >
> > > > > > > > On 2/26/07, Martin Haimberger < martin.haimberger@gmail.com>
> > > wrote:
> > > > > > > > > Hy *,
> > > > > > > > >
> > > > > > > > > i am going to help to develop myfaces 1.2. I have checked it
> > > out,
> > > > > > > > > compiled it (with some difficulties, because some jars were
> not
> > > > > > > > > found). I installed tomcat 6.0.9 alpha and i got this error:
> > > > > > > > >
> > > > > > > > > DEBUG [main] ( HtmlRenderKitImpl.java:112) - add Renderer
> family
> > > =
> > > > > > > > > javax.faces.SelectOne rendererType = javax.faces.Radio
> renderer
> > > class
> > > > > > > > > =
> > > org.apache.myfaces.renderkit.html.HtmlRadioRenderer
> > > > > > > > >   INFO [main] (FacesConfigurator.java:972) - Serialization
> > > provider :
> > > > > > > > > class
> > >
> org.apache.myfaces.shared_impl.util.serial.DefaultSerialFactory
> > > > > > > > > Feb 26, 2007 2:14:34 PM
> > > org.apache.catalina.core.StandardContext start
> > > > > > > > > SEVERE: Error listenerStart
> > > > > > > > > Feb 26, 2007 2:14:34 PM
> > > org.apache.catalina.core.StandardContext start
> > > > > > > > >
> > > > > > > > > I am running Intellij 6.0.4 and tomcat 6.0.9 on MacOsX.
> > > > > > > > >
> > > > > > > > > Has someone any idea what i did wrong?
> > > > > > > > >
> > > > > > > > > Regards,
> > > > > > > > > Martin Haimberger
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > --
> > > > > > > > Matthias Wessendorf
> > > > > > > > http://tinyurl.com/fmywh
> > > > > > > >
> > > > > > > > further stuff:
> > > > > > > > blog: http://jroller.com/page/mwessendorf
> > > > > > > > mail: mwessendorf-at-gmail-dot-com
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Matthias Wessendorf
> > > > > http://tinyurl.com/fmywh
> > > > >
> > > > > further stuff:
> > > > > blog: http://jroller.com/page/mwessendorf
> > > > > mail: mwessendorf-at-gmail-dot-com
> > > > >
> > > >
> > >
> > >
> > >
> > > --
> > > Dennis Byrne
> >
>
>
>
> --
> Dennis Byrne


-- 
Mathias

Re: [VOTE] Remove Static loggers from 1.2

Posted by Manfred Geiler <ma...@gmail.com>.
+1

--Manfred


On 2/27/07, Werner Punz <we...@gmail.com> wrote:
> Dennis Byrne schrieb:
> > Alright.  Here's my +1 binding.  Let's put the nail in this coffin.
> >
> > Dennis Byrne
> +1 for that as well, this has been a code burden for too long.
>
>

Re: [VOTE] Remove Static loggers from 1.2

Posted by Werner Punz <we...@gmail.com>.
Dennis Byrne schrieb:
> Alright.  Here's my +1 binding.  Let's put the nail in this coffin.
> 
> Dennis Byrne
+1 for that as well, this has been a code burden for too long.