From rsvoboda at redhat.com  Wed May 18 09:57:00 2016
From: rsvoboda at redhat.com (Rostislav Svoboda)
Date: Wed, 18 May 2016 09:57:00 -0400 (EDT)
Subject: [jbossws-dev] Experiments with LogMessage levels for jbossws/wfly
In-Reply-To: <409863641.3953703.1463578732421.JavaMail.zimbra@redhat.com>
Message-ID: <720852733.3959205.1463579820976.JavaMail.zimbra@redhat.com>

Hi.

Just sharing small experiment with counting of LogMessage for jbossws/wfly projects

grep -i @LogMessage jbossws-api jbossws-spi jbossws-common jbossws-common-tools jbossws-cxf -R | cut -d@ -f2 | sort | uniq -c | sort -n
      7 LogMessage(level = INFO)
     19 LogMessage(level = ERROR)
     22 LogMessage(level = TRACE)
     31 LogMessage(level = DEBUG)
     34 LogMessage(level = WARN)

Here is Wildfly:
grep -i @LogMessage wildfly-core wildfly -R | cut -d@ -f2 | sed "s/Logger.Level.//g" | sed "s/Level.//g" | sed "s/l=/l =/g" | sort | uniq -c | sort -n
      1 LogMessage(level = FATAL)
     14 LogMessage(level = TRACE)
     27 LogMessage(level = DEBUG)
    195 LogMessage(level = INFO)
    253 LogMessage(level = ERROR)
    320 LogMessage(level = WARN)

WLFY vs. JBWS usage of logging levels differ a bit. Is it something to worry about ?


FYI: Raw WildFly is a bit inconsistent :)
grep -i @LogMessage wildfly -R | cut -d@ -f2 | sort | uniq -c | sort -n
      1 LogMessage(level = FATAL)
      1 LogMessage(level= Logger.Level.INFO)
      2 LogMessage(level = Logger.Level.DEBUG)
      2 LogMessage(level= Logger.Level.ERROR)
      3 LogMessage(level = Level.ERROR)
      3 LogMessage(level = Level.INFO)
      3 LogMessage(level = Logger.Level.INFO)
      4 LogMessage(level = Level.WARN)
      5 LogMessage(level = Logger.Level.ERROR)
     10 LogMessage(level = Logger.Level.WARN)
     14 LogMessage(level = TRACE)
     23 LogMessage(level = DEBUG)
     92 LogMessage(level = INFO)
    118 LogMessage(level = ERROR)
    164 LogMessage(level = WARN)
grep -i @LogMessage wildfly-core -R | cut -d@ -f2 | sort | uniq -c | sort -n
      1 LogMessage(level = Level.DEBUG)
      1 LogMessage(level = Logger.Level.DEBUG)
      2 LogMessage(level = Logger.Level.INFO)
      3 LogMessage(level = Logger.Level.ERROR)
     10 LogMessage(level = Logger.Level.WARN)
     33 LogMessage(level = Level.WARN)
     34 LogMessage(level = Level.ERROR)
     36 LogMessage(level = Level.INFO)
     58 LogMessage(level = INFO)
     88 LogMessage(level = ERROR)
     99 LogMessage(level = WARN)


Rostislav


From rsvoboda at redhat.com  Mon May 23 05:55:36 2016
From: rsvoboda at redhat.com (Rostislav Svoboda)
Date: Mon, 23 May 2016 05:55:36 -0400 (EDT)
Subject: [jbossws-dev] Fwd: Require assistance with joda-time rebuild for
	JBEAP-1366
In-Reply-To: <CANy_y4tq6c3RhQBF-ChzBdu6tj==_Da-0er91eU1ySFPD8C9fQ@mail.gmail.com>
References: <CANy_y4tq6c3RhQBF-ChzBdu6tj==_Da-0er91eU1ySFPD8C9fQ@mail.gmail.com>
Message-ID: <713273878.5200087.1463997336903.JavaMail.zimbra@redhat.com>

Hi.

CXF WS security part is using joda-time as transitive dependency. Do you think this rebuild thing can affect JBossWS?
In the meantime I'm trying to get ingo if the failures happen when using JDK7 jar but running on JDK8. 

Rostislav

----- Forwarded Message -----
From: "Filip Kujikis" <fkujikis at redhat.com>
To: eap-qe at redhat.com
Cc: "Petr Sakar" <psakar at redhat.com>
Sent: Monday, May 23, 2016 10:44:34 AM
Subject: Require assistance with joda-time rebuild for JBEAP-1366

Hi QE team,

I'm currently working on a rebuild for a couple of projects concerning
JBEAP-1366 <https://issues.jboss.org/browse/JBEAP-1366> and have run into a
problem with the rebuild of joda-time (
git.app.eng.bos.redhat.com/srv/git/joda-time.git).

The problem is that there are test failures (about 20 from ~4000) when
running the maven build against JDK 1.8. The build runs successfully
against JDK 1.7. I have confirmed this with a local build against 1.7 and
1.8.

The failing tests concern unexpected formats for short timezone string
representation.

I have attached a patch for one unit test demonstrating the problem /
potential test "fix". In the first example the expected output is "BST",
but the code produces "+01:00" under JDK 1.8.

I would appreciate any advice on how to proceed with the re-build, whether
it is safe to 'correct' the unit tests as in the example I attached, or any
alternatives otherwise.

Regards,
Filip
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test_check.patch
Type: text/x-patch
Size: 1551 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/jbossws-dev/attachments/20160523/a2084a8a/attachment.bin 

From rsvoboda at redhat.com  Mon May 23 06:29:43 2016
From: rsvoboda at redhat.com (Rostislav Svoboda)
Date: Mon, 23 May 2016 06:29:43 -0400 (EDT)
Subject: [jbossws-dev] Fwd: Require assistance with joda-time rebuild
 for	JBEAP-1366
In-Reply-To: <713273878.5200087.1463997336903.JavaMail.zimbra@redhat.com>
References: <CANy_y4tq6c3RhQBF-ChzBdu6tj==_Da-0er91eU1ySFPD8C9fQ@mail.gmail.com>
	<713273878.5200087.1463997336903.JavaMail.zimbra@redhat.com>
Message-ID: <1902757329.5210759.1463999383876.JavaMail.zimbra@redhat.com>

JAR: /home/rsvoboda/TESTING/700ER2/jboss-eap-7.0/modules/system/layers/base/org/joda/time/main/joda-time-2.7.0.redhat-2.jar

JDK8
BST vs. +01:00
GMT vs. +00:00
BST vs. +01:00

JDK7
BST vs. BST
GMT vs. GMT
BST vs. BST

Code:
    public static void main(String[] args) {
        DateTimeZone zone = DateTimeZone.forID("Europe/London");
        System.out.println("BST vs. " + zone.getShortName(TEST_TIME_SUMMER));
        System.out.println("GMT vs. " + zone.getShortName(TEST_TIME_WINTER));
        System.out.println("BST vs. " + zone.getShortName(TEST_TIME_SUMMER, Locale.ENGLISH));
    }
TEST_TIME_SUMMER and TEST_TIME_WINTER copied from https://github.com/JodaOrg/joda-time/blob/master/src/test/java/org/joda/time/TestDateTimeZone.java

So as we are running EAP with JDK8+ we always see +01:00, +00:00 etc ... so rebuild doesn't affect any of current behavior.


Rostislav

----- Original Message -----
> Hi.
> 
> CXF WS security part is using joda-time as transitive dependency. Do you
> think this rebuild thing can affect JBossWS?
> In the meantime I'm trying to get ingo if the failures happen when using JDK7
> jar but running on JDK8.
> 
> Rostislav
> 
> ----- Forwarded Message -----
> From: "Filip Kujikis" <fkujikis at redhat.com>
> To: eap-qe at redhat.com
> Cc: "Petr Sakar" <psakar at redhat.com>
> Sent: Monday, May 23, 2016 10:44:34 AM
> Subject: Require assistance with joda-time rebuild for JBEAP-1366
> 
> Hi QE team,
> 
> I'm currently working on a rebuild for a couple of projects concerning
> JBEAP-1366 <https://issues.jboss.org/browse/JBEAP-1366> and have run into a
> problem with the rebuild of joda-time (
> git.app.eng.bos.redhat.com/srv/git/joda-time.git).
> 
> The problem is that there are test failures (about 20 from ~4000) when
> running the maven build against JDK 1.8. The build runs successfully
> against JDK 1.7. I have confirmed this with a local build against 1.7 and
> 1.8.
> 
> The failing tests concern unexpected formats for short timezone string
> representation.
> 
> I have attached a patch for one unit test demonstrating the problem /
> potential test "fix". In the first example the expected output is "BST",
> but the code produces "+01:00" under JDK 1.8.
> 
> I would appreciate any advice on how to proceed with the re-build, whether
> it is safe to 'correct' the unit tests as in the example I attached, or any
> alternatives otherwise.
> 
> Regards,
> Filip
> 
> _______________________________________________
> jbossws-dev mailing list
> jbossws-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbossws-dev

From rsvoboda at redhat.com  Tue May 24 09:49:26 2016
From: rsvoboda at redhat.com (Rostislav Svoboda)
Date: Tue, 24 May 2016 09:49:26 -0400 (EDT)
Subject: [jbossws-dev] jbossws-cxf and try-catch blocks
In-Reply-To: <340210291.321418.1464097623561.JavaMail.zimbra@redhat.com>
Message-ID: <424853462.322411.1464097766890.JavaMail.zimbra@redhat.com>

Hi.

I'd like to have your feedback on 2 logging items related to jbossws-cxf and try-catch [1].

1) Usage of Exception.printStackTrace() instead of logging feature
  https://github.com/jbossws/jbossws-cxf/blob/master/modules/client/src/main/java/org/jboss/wsf/stack/cxf/client/serviceref/CXFHandlerResolverImpl.java#L331
  https://github.com/jbossws/jbossws-cxf/blob/master/modules/client/src/main/java/org/jboss/wsf/stack/cxf/client/serviceref/CXFHandlerResolverImpl.java#L373
  https://github.com/jbossws/jbossws-cxf/blob/master/modules/addons/transports/udp/src/main/java/org/jboss/wsf/stack/cxf/addons/transports/udp/UDPDestination.java#L113
  https://github.com/jbossws/jbossws-cxf/blob/master/modules/addons/transports/udp/src/main/java/org/jboss/wsf/stack/cxf/addons/transports/udp/UDPDestination.java#L200

Is there any reason to call printStackTrace() directly ? If not I can create JIRA for cleanup ++ check other jbossws-* projects.

2) // ignore in catch block
  https://github.com/jbossws/jbossws-cxf/blob/master/modules/client/src/main/java/org/jboss/wsf/stack/cxf/saaj/SOAPConnectionImpl.java#L251
  https://github.com/jbossws/jbossws-cxf/blob/master/modules/addons/transports/udp/src/main/java/org/jboss/wsf/stack/cxf/addons/transports/udp/UDPConduit.java#L165
  https://github.com/jbossws/jbossws-cxf/blob/master/modules/addons/transports/udp/src/main/java/org/jboss/wsf/stack/cxf/addons/transports/udp/UDPConduit.java#L179
  https://github.com/jbossws/jbossws-cxf/blob/master/modules/jaspi/src/main/java/org/jboss/wsf/stack/cxf/jaspi/config/JBossWSServerAuthConfig.java#L193

What about logging on trace level ? In case of UDPConduid it's catching exception on socket.send() while looping across all network interfaces ... logging at trace could potentially help when troubleshooting
What do you think about these items? Should I proceed with JIRA and other jbossws-* projects?


Thank you.
Rostislav

[1] grep -b8 catch . -R | grep -v 'modules/test' | grep -v 'Test\.java' | grep -v "\.xml" | uniq  > ~/Downloads/jbossws-cxf-try-catch.txt

From asoldano at redhat.com  Tue May 24 10:00:26 2016
From: asoldano at redhat.com (Alessio Soldano)
Date: Tue, 24 May 2016 16:00:26 +0200
Subject: [jbossws-dev] jbossws-cxf and try-catch blocks
In-Reply-To: <424853462.322411.1464097766890.JavaMail.zimbra@redhat.com>
References: <424853462.322411.1464097766890.JavaMail.zimbra@redhat.com>
Message-ID: <57445E7A.4000006@redhat.com>

Il 24/05/2016 15:49, Rostislav Svoboda ha scritto:
> Hi.
>
> I'd like to have your feedback on 2 logging items related to jbossws-cxf and try-catch [1].
>
> 1) Usage of Exception.printStackTrace() instead of logging feature
>    https://github.com/jbossws/jbossws-cxf/blob/master/modules/client/src/main/java/org/jboss/wsf/stack/cxf/client/serviceref/CXFHandlerResolverImpl.java#L331
>    https://github.com/jbossws/jbossws-cxf/blob/master/modules/client/src/main/java/org/jboss/wsf/stack/cxf/client/serviceref/CXFHandlerResolverImpl.java#L373
>    https://github.com/jbossws/jbossws-cxf/blob/master/modules/addons/transports/udp/src/main/java/org/jboss/wsf/stack/cxf/addons/transports/udp/UDPDestination.java#L113
>    https://github.com/jbossws/jbossws-cxf/blob/master/modules/addons/transports/udp/src/main/java/org/jboss/wsf/stack/cxf/addons/transports/udp/UDPDestination.java#L200
>
> Is there any reason to call printStackTrace() directly ? If not I can create JIRA for cleanup ++ check other jbossws-* projects.
Most likely leftovers from initial development; not a major issue, but 
yes, should be replaced with proper logging.

>
> 2) // ignore in catch block
>    https://github.com/jbossws/jbossws-cxf/blob/master/modules/client/src/main/java/org/jboss/wsf/stack/cxf/saaj/SOAPConnectionImpl.java#L251
>    https://github.com/jbossws/jbossws-cxf/blob/master/modules/addons/transports/udp/src/main/java/org/jboss/wsf/stack/cxf/addons/transports/udp/UDPConduit.java#L165
>    https://github.com/jbossws/jbossws-cxf/blob/master/modules/addons/transports/udp/src/main/java/org/jboss/wsf/stack/cxf/addons/transports/udp/UDPConduit.java#L179
>    https://github.com/jbossws/jbossws-cxf/blob/master/modules/jaspi/src/main/java/org/jboss/wsf/stack/cxf/jaspi/config/JBossWSServerAuthConfig.java#L193
>
> What about logging on trace level ? In case of UDPConduid it's catching exception on socket.send() while looping across all network interfaces ... logging at trace could potentially help when troubleshooting
> What do you think about these items? Should I proceed with JIRA and other jbossws-* projects?
A simple message at TRACE level could be ok in these cases, yes.

Yes, please create 2 jiras.
Thanks
Alessio

-- 
Alessio Soldano
Web Service Lead, JBoss


From rsvoboda at redhat.com  Wed May 25 06:10:47 2016
From: rsvoboda at redhat.com (Rostislav Svoboda)
Date: Wed, 25 May 2016 06:10:47 -0400 (EDT)
Subject: [jbossws-dev] jbossws-cxf and try-catch blocks
In-Reply-To: <57445E7A.4000006@redhat.com>
References: <424853462.322411.1464097766890.JavaMail.zimbra@redhat.com>
	<57445E7A.4000006@redhat.com>
Message-ID: <1255270624.1144822.1464171047121.JavaMail.zimbra@redhat.com>

https://issues.jboss.org/browse/JBEAP-4717
https://issues.jboss.org/browse/JBEAP-4718

Will look at other jbossws-* projects within few days.

Rostislav

----- Original Message -----
> Il 24/05/2016 15:49, Rostislav Svoboda ha scritto:
> > Hi.
> >
> > I'd like to have your feedback on 2 logging items related to jbossws-cxf
> > and try-catch [1].
> >
> > 1) Usage of Exception.printStackTrace() instead of logging feature
> >    https://github.com/jbossws/jbossws-cxf/blob/master/modules/client/src/main/java/org/jboss/wsf/stack/cxf/client/serviceref/CXFHandlerResolverImpl.java#L331
> >    https://github.com/jbossws/jbossws-cxf/blob/master/modules/client/src/main/java/org/jboss/wsf/stack/cxf/client/serviceref/CXFHandlerResolverImpl.java#L373
> >    https://github.com/jbossws/jbossws-cxf/blob/master/modules/addons/transports/udp/src/main/java/org/jboss/wsf/stack/cxf/addons/transports/udp/UDPDestination.java#L113
> >    https://github.com/jbossws/jbossws-cxf/blob/master/modules/addons/transports/udp/src/main/java/org/jboss/wsf/stack/cxf/addons/transports/udp/UDPDestination.java#L200
> >
> > Is there any reason to call printStackTrace() directly ? If not I can
> > create JIRA for cleanup ++ check other jbossws-* projects.
> Most likely leftovers from initial development; not a major issue, but
> yes, should be replaced with proper logging.
> 
> >
> > 2) // ignore in catch block
> >    https://github.com/jbossws/jbossws-cxf/blob/master/modules/client/src/main/java/org/jboss/wsf/stack/cxf/saaj/SOAPConnectionImpl.java#L251
> >    https://github.com/jbossws/jbossws-cxf/blob/master/modules/addons/transports/udp/src/main/java/org/jboss/wsf/stack/cxf/addons/transports/udp/UDPConduit.java#L165
> >    https://github.com/jbossws/jbossws-cxf/blob/master/modules/addons/transports/udp/src/main/java/org/jboss/wsf/stack/cxf/addons/transports/udp/UDPConduit.java#L179
> >    https://github.com/jbossws/jbossws-cxf/blob/master/modules/jaspi/src/main/java/org/jboss/wsf/stack/cxf/jaspi/config/JBossWSServerAuthConfig.java#L193
> >
> > What about logging on trace level ? In case of UDPConduid it's catching
> > exception on socket.send() while looping across all network interfaces ...
> > logging at trace could potentially help when troubleshooting
> > What do you think about these items? Should I proceed with JIRA and other
> > jbossws-* projects?
> A simple message at TRACE level could be ok in these cases, yes.
> 
> Yes, please create 2 jiras.
> Thanks
> Alessio
> 
> --
> Alessio Soldano
> Web Service Lead, JBoss
> 
> _______________________________________________
> jbossws-dev mailing list
> jbossws-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbossws-dev
>