I cannot see any real consequences yet, but in catalina.out I find:

    2016-09-13 09:08:24,616 localhost-startStop-9 ERROR appender has no 
parameter that matches element policies
    2016-09-13 09:08:24,618 localhost-startStop-9 ERROR appender has no 
parameter that matches element policies

Regards,
  Steffen


On 09/13/2016 08:47 AM, Steffen Offermann wrote:
I have to take a look at the respective code (I did not write it), but it seems 
I can already give the all-clear: The latest master does not break any of our 
logging-specific test cases any more
(except within Eclipse, but that's probably related to a very specific 
requirement of ours in those test cases).

I have yet to test it in our other artefacts, where the actual logging takes 
place.

Regards,
  Steffeh

On 09/12/2016 05:27 PM, Matt Sicker wrote:
Steffen, is the code you're looking at using the factory methods? Or are you 
using the builder class?

On 12 September 2016 at 02:33, Steffen Offermann <steffen.offerm...@aixigo.de 
<mailto:steffen.offerm...@aixigo.de>> wrote:


    Nope, this does not work. The test case mentioned in LOG4J2-1573 works if I 
remove the @Required annotation, like Gary suggested, but then most of the 
other tests break.

    Regards,
      Steffen


    On 09/12/2016 09:17 AM, Steffen Offermann wrote:

        Hmmm, would that still guarantee the correct defaults (as mentioned in 
the documentation) though?


        On 09/12/2016 09:16 AM, Steffen Offermann wrote:

            Looks like this would also fix 
https://issues.apache.org/jira/browse/LOG4J2-1573 
<https://issues.apache.org/jira/browse/LOG4J2-1573>. I'll try that shortly.

            On 09/12/2016 07:55 AM, Gary Gregory wrote:

                I understand now, thank you. All build methods do not use the 
same default. I'll remove the @Required tomorrow.

                Gary


                On Sep 11, 2016 9:11 PM, "Matt Sicker" <boa...@gmail.com 
<mailto:boa...@gmail.com> <mailto:boa...@gmail.com <mailto:boa...@gmail.com>>> wrote:

                    I mean if you do something like this:

                    @PluginElement("Layout")
                    @Required
                    private Layout layout = PatternLayout.defaultLayout();

                    Then it should work. But if you defer the creation of a 
default layout until you execute the build() method, then the validator will 
err out before build() is called.

                    On 11 September 2016 at 21:20, Gary Gregory <garydgreg...@gmail.com 
<mailto:garydgreg...@gmail.com> <mailto:garydgreg...@gmail.com 
<mailto:garydgreg...@gmail.com>>> wrote:

                        HI Matt,

                        Right now, all of the build() methods handle null 
layouts by using a default layout. That works for programmatic configs. But in 
order for that to work from a config file, the
                @Required needs
                        to be removed.

                        I feel like I am not understanding something in your 
message :-(

                        Gary

                        On Sun, Sep 11, 2016 at 11:43 AM, Matt Sicker <boa...@gmail.com 
<mailto:boa...@gmail.com> <mailto:boa...@gmail.com <mailto:boa...@gmail.com>>> 
wrote:

                            I thought that @Required would check the field at 
build time, not injection time. If the field was set to null, then you're going 
to have a bad time.

                            On 11 September 2016 at 10:50, Gary Gregory <garydgreg...@gmail.com 
<mailto:garydgreg...@gmail.com> <mailto:garydgreg...@gmail.com 
<mailto:garydgreg...@gmail.com>>> wrote:

                                I forgot to say that:

                                
org.apache.logging.log4j.core.appender.ConsoleAppender.Builder.build()
                                
org.apache.logging.log4j.core.appender.FileAppender.Builder.build()
                                
org.apache.logging.log4j.core.appender.RollingFileAppender.Builder.build()
                                
org.apache.logging.log4j.core.appender.SocketAppender.Builder.build()

                                All provide default layouts.

                                Gary


                                On Sun, Sep 11, 2016 at 8:48 AM, Gary Gregory 
<garydgreg...@gmail.com <mailto:garydgreg...@gmail.com> <mailto:garydgreg...@gmail.com 
<mailto:garydgreg...@gmail.com>>>
                wrote:

                                    I'm pretty sure we no longer need @Required 
on layout on 
org.apache.logging.log4j.core.appender.AbstractAppender.Builder.layout.

                                    Would it be OK to say that an appender 
should provide a default layout?

                                    Gary

                                    --
                                    E-Mail: garydgreg...@gmail.com 
<mailto:garydgreg...@gmail.com> <mailto:garydgreg...@gmail.com 
<mailto:garydgreg...@gmail.com>> | ggreg...@apache.org
                <mailto:ggreg...@apache.org> <mailto:ggreg...@apache.org 
<mailto:ggreg...@apache.org>>
                                    Java Persistence with Hibernate, Second Edition 
<http://www.manning.com/bauer3/ <http://www.manning.com/bauer3/>>
                                    JUnit in Action, Second Edition 
<http://www.manning.com/tahchiev/ <http://www.manning.com/tahchiev/>>
                                    Spring Batch in Action 
<http://www.manning.com/templier/ <http://www.manning.com/templier/>>
                                    Blog: http://garygregory.wordpress.com 
<http://garygregory.wordpress.com> <http://garygregory.wordpress.com/ 
<http://garygregory.wordpress.com/>>
                                    Home: http://garygregory.com/
                                    Tweet! http://twitter.com/GaryGregory




                                --
                                E-Mail: garydgreg...@gmail.com 
<mailto:garydgreg...@gmail.com> <mailto:garydgreg...@gmail.com 
<mailto:garydgreg...@gmail.com>> | ggreg...@apache.org
                <mailto:ggreg...@apache.org> <mailto:ggreg...@apache.org 
<mailto:ggreg...@apache.org>>
                                Java Persistence with Hibernate, Second Edition 
<http://www.manning.com/bauer3/ <http://www.manning.com/bauer3/>>
                                JUnit in Action, Second Edition 
<http://www.manning.com/tahchiev/ <http://www.manning.com/tahchiev/>>
                                Spring Batch in Action <http://www.manning.com/templier/ 
<http://www.manning.com/templier/>>
                                Blog: http://garygregory.wordpress.com 
<http://garygregory.wordpress.com> <http://garygregory.wordpress.com/ 
<http://garygregory.wordpress.com/>>
                                Home: http://garygregory.com/
                                Tweet! http://twitter.com/GaryGregory




                            --
                            Matt Sicker <boa...@gmail.com <mailto:boa...@gmail.com> 
<mailto:boa...@gmail.com <mailto:boa...@gmail.com>>>




                        --
                        E-Mail: garydgreg...@gmail.com <mailto:garydgreg...@gmail.com> 
<mailto:garydgreg...@gmail.com <mailto:garydgreg...@gmail.com>> | ggreg...@apache.org
                <mailto:ggreg...@apache.org> <mailto:ggreg...@apache.org 
<mailto:ggreg...@apache.org>>
                        Java Persistence with Hibernate, Second Edition 
<http://www.manning.com/bauer3/ <http://www.manning.com/bauer3/>>
                        JUnit in Action, Second Edition 
<http://www.manning.com/tahchiev/ <http://www.manning.com/tahchiev/>>
                        Spring Batch in Action <http://www.manning.com/templier/ 
<http://www.manning.com/templier/>>
                        Blog: http://garygregory.wordpress.com 
<http://garygregory.wordpress.com> <http://garygregory.wordpress.com/ 
<http://garygregory.wordpress.com/>>
                        Home: http://garygregory.com/
                        Tweet! http://twitter.com/GaryGregory




                    --
                    Matt Sicker <boa...@gmail.com <mailto:boa...@gmail.com> 
<mailto:boa...@gmail.com <mailto:boa...@gmail.com>>>







    --
    aixigo AG - financial solutions & technology
    Karl-Friedrich-Straße 68, 52072 Aachen, Germany
    fon: +49 (0)241 559709-65 <tel:%2B49%20%280%29241%20559709-65>, fax: +49 (0)241 
559709-99 <tel:%2B49%20%280%29241%20559709-99>
    eMail: steffen.offerm...@aixigo.de <mailto:steffen.offerm...@aixigo.de>, 
web: http://www.aixigo.de

    Amtsgericht Aachen - HRB 8057
    Vorstand: Erich Borsch, Christian Friedrich, Tobias Haustein
    Vors. des Aufsichtsrates: Prof. Dr. Rüdiger von Nitzsch

    ---------------------------------------------------------------------
    To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org 
<mailto:log4j-dev-unsubscr...@logging.apache.org>
    For additional commands, e-mail: log4j-dev-h...@logging.apache.org 
<mailto:log4j-dev-h...@logging.apache.org>




--
Matt Sicker <boa...@gmail.com <mailto:boa...@gmail.com>>




--
aixigo AG - financial solutions & technology
Karl-Friedrich-Straße 68, 52072 Aachen, Germany
fon: +49 (0)241 559709-65, fax: +49 (0)241 559709-99
eMail: steffen.offerm...@aixigo.de, web: http://www.aixigo.de

Amtsgericht Aachen - HRB 8057
Vorstand: Erich Borsch, Christian Friedrich, Tobias Haustein
Vors. des Aufsichtsrates: Prof. Dr. Rüdiger von Nitzsch

---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

Reply via email to