https://bugzilla.redhat.com/show_bug.cgi?id=1195244
Bug ID: 1195244
Summary: Mis-configured logging mutes log messages
Product: Fedora
Version: 22
Component: javapackages-tools
Assignee: mizdebsk(a)redhat.com
Reporter: leamas.alec(a)gmail.com
QA Contact: extras-qa(a)fedoraproject.org
CC: java-sig-commits(a)lists.fedoraproject.org,
mat.booth(a)redhat.com, mizdebsk(a)redhat.com,
msimacek(a)redhat.com, msrb(a)redhat.com
Created attachment 994371
--> https://bugzilla.redhat.com/attachment.cgi?id=994371&action=edit
Test case provoking bug with non-readable metadata.
Description of problem:
Version-Release number of selected component (if applicable):
How reproducible: Always
Steps to Reproduce:
1. Install DecodeIrCaller from
https://copr.fedoraproject.org/coprs/leamas/harctoolbox/
2. For the example, create a bug:
$ sudo chmod 600 /usr/share/maven-metadata/DecodeIrCaller.xml
3.Run attached maven.req. It is a patched version of the thing
run by rpmbuild
$ ./maven.req
4. Watch in output
Processing files: IrpMaster-1.0.2-1.fc21.noarch
No handlers could be found for logger "pyxb.binding.basis"
No handlers could be found for logger "pyxb.binding.basis"
The messages stems from the XML parsing in
javapackages/metadata/pyxbmetadata.py around line 59. Obviously, they are not
really helpful, loggers should be configure
Actual results:
Useless messages
Expected results:
Good messages.
Additional info:
Same thing is likely to happen for any maven-driver spec given a non-readable
metadata dependency. And there are other things which might got wrong, needing
configured logger I guess.
--
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=AcTChb0Kzb&a=cc_unsubscribe
https://bugzilla.redhat.com/show_bug.cgi?id=1187426
Bug ID: 1187426
Summary: Powermock: junit 4.12 throws Field 'fTestClass' was
not found in class
org.junit.internal.runners.MethodValidator exception
Product: Fedora
Version: 21
Component: powermock
Severity: medium
Assignee: rkennke(a)redhat.com
Reporter: dchen(a)redhat.com
QA Contact: extras-qa(a)fedoraproject.org
CC: java-sig-commits(a)lists.fedoraproject.org,
jerboaa(a)gmail.com, msimacek(a)redhat.com,
neugens(a)redhat.com, rkennke(a)redhat.com
Description of problem:
See https://code.google.com/p/powermock/issues/detail?id=531 for detail
Version-Release number of selected component (if applicable):
powermock-junit4-1.4.12-12.fc21.noarch
How reproducible:
Always
Additional info:
Upstream fixed it in powermock-easymock-junit-1.6.1.zip
--
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=oTkzgdvOGv&a=cc_unsubscribe
https://bugzilla.redhat.com/show_bug.cgi?id=1147963
Bug ID: 1147963
Summary: JENKINS script for showing failed jobs is not working
Product: Fedora
Version: 21
Component: jenkins
Severity: medium
Assignee: msrb(a)redhat.com
Reporter: amsharma(a)redhat.com
QA Contact: extras-qa(a)fedoraproject.org
CC: java-sig-commits(a)lists.fedoraproject.org,
msrb(a)redhat.com
Description of problem:
JENKINS script for showing failed jobs is not working
Version-Release number of selected component (if applicable):
[root@dhcp201-185 ~]# rpm -qa | grep jenkins
jenkins-icon-shim-1.0.3-1.fc21.noarch
js-yui2-jenkins-2.9.0-6.fc21.noarch
jenkins-task-reactor-1.4-2.fc21.noarch
jenkins-external-monitor-job-plugin-1.2-1.fc21.noarch
jenkins-javadoc-plugin-1.2-1.fc21.noarch
jenkins-commons-jelly-1.1.20120928-6.fc21.noarch
jenkins-instance-identity-1.3-4.fc21.noarch
jenkins-sshd-1.6-4.fc21.noarch
jenkins-1.581-2.fc21.noarch
jenkins-ant-plugin-1.2-1.fc21.noarch
jenkins-executable-war-1.29-3.fc21.noarch
jenkins-xstream-1.4.7-3.jenkins1.fc21.noarch
trilead-ssh2-217-4.jenkins4.fc21.noarch
jenkins-ssh-cli-auth-1.2-4.fc21.noarch
jenkins-core-1.581-2.fc21.noarch
jenkins-remoting-2.43-1.fc21.noarch
jenkins-json-lib-2.4-7.fc21.noarch
jenkins-junit-plugin-1.1-1.fc21.noarch
jenkins-mailer-plugin-1.11-1.fc21.noarch
jenkins-extras-memory-monitor-1.8-1.fc21.noarch
jenkins-crypto-util-1.4-2.fc21.noarch
jenkins-version-number-1.1-4.fc21.noarch
jenkins-webapp-1.581-2.fc21.noarch
jenkins-winstone-2.3-1.fc21.noarch
jenkins-jexl-1.1-3.20111212.fc21.noarch
jenkins-cli-1.581-2.fc21.noarch
How reproducible:
Always
Steps to Reproduce:
1.go to https://wiki.jenkins-ci.org/display/JENKINS/Failed+Jobs
2. copy script and paste in localhost:8080/script
Actual results:
It does not display anything in output.
Result
Result: []
Expected results:
It should display all failed jobs
Additional info:
I had failed jobs in my jenkins
--
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=63mWa2HTjL&a=cc_unsubscribe
https://bugzilla.redhat.com/show_bug.cgi?id=1147105
Bug ID: 1147105
Summary: CATALINA_OPTS are only read when SECURITY_MANAGER is
true
Product: Fedora
Version: 20
Component: tomcat
Assignee: ivan.afonichev(a)gmail.com
Reporter: awood(a)redhat.com
QA Contact: extras-qa(a)fedoraproject.org
CC: ivan.afonichev(a)gmail.com,
java-sig-commits(a)lists.fedoraproject.org,
krzysztof.daniel(a)gmail.com
Description of problem:
The CATALINA_OPTS configuration value is ignored during Tomcat start-up unless
the SECURITY_MANAGER configuration value is set to true. By default
SECURITY_MANAGER is set to "false" so this issue can be pretty confusing if
you're trying to add to CATALINA_OPTS and nothing happens.
Version-Release number of selected component (if applicable):
tomcat-7.0.52-1.fc20.noarch
How reproducible: Always
Steps to Reproduce:
1. Edit /etc/tomcat/tomcat.conf
2. Set CATALINA_OPTS to something.
"-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=8000" for
example.
3. Set SECURITY_MANAGER to "false"
3. Restart tomcat.
4. pgrep -fla tomcat
Actual results: The pgrep command reveals that Tomcat is running without the
values set in CATALINA_OPTS.
Expected results: CATALINA_OPTS are present.
Additional info: This bug is actually due to the fix to bug 1051194. In the
bugfix, the reading in of CATALINA_OPTS has been moved in
/usr/libexec/tomcat/server into a block that requires SECURITY_MANAGER to be
true.
if [ "$1" = "start" ] ; then
if [ "${SECURITY_MANAGER}" = "true" ] ; then
FLAGS="${FLAGS} $CATALINA_OPTS"
OPTIONS="${OPTIONS} \
-Djava.security.manager \
-Djava.security.policy==${CATALINA_BASE}/conf/catalina.policy"
fi
run start
I propose that the flags be read before looking at the security manager
settings. Like
if [ "$1" = "start" ] ; then
FLAGS="${FLAGS} $CATALINA_OPTS"
if [ "${SECURITY_MANAGER}" = "true" ] ; then
OPTIONS="${OPTIONS} \
-Djava.security.manager \
-Djava.security.policy==${CATALINA_BASE}/conf/catalina.policy"
fi
run start
Possible OPTIONS should be read outside of the block too?
--
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=H3lP9UbWQ1&a=cc_unsubscribe
https://bugzilla.redhat.com/show_bug.cgi?id=1177153
Bug ID: 1177153
Summary: zookeeper-lib-devel is missing
Product: Fedora
Version: 21
Component: zookeeper
Assignee: tstclair(a)redhat.com
Reporter: fedora(a)famillecollet.com
QA Contact: extras-qa(a)fedoraproject.org
CC: ethan(a)ethantuttle.com,
java-sig-commits(a)lists.fedoraproject.org,
jeff(a)ocjtech.us, s(a)shk.io, tstclair(a)redhat.com
Up to Fedora 20 zookeeper-lib-devel was available.
I understand that zookeeper-devel provides the needed stuf.
I think zookeeper-devel have to obsoletes and provides zookeeper-lib-devel
And zookeeper have to obsoletes and provides zookeeper-lib
This will allow smoth update from Fedora < 21
And avoid having to conditionalize the BR in dependent packages
(even if I prefer the previous layout, which pull much less dependency)
P.S. I use this to build php-pecl-zookeper (but not yet submitted for Fedora
repo)
--
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=6r7IOnjNPg&a=cc_unsubscribe
https://bugzilla.redhat.com/show_bug.cgi?id=1018485
Bug ID: 1018485
Summary: EclipseLink 2.5.1 is available
Product: Fedora
Version: rawhide
Component: eclipselink
Assignee: puntogil(a)libero.it
Reporter: gerard(a)ryan.lt
QA Contact: extras-qa(a)fedoraproject.org
CC: java-sig-commits(a)lists.fedoraproject.org,
puntogil(a)libero.it
Description of problem:
Latest release of eclipselink in rawhide & f20 is 2.4.2, and in f19 is 2.3.2.
Eclipselink 2.5.1 was released in late September [0].
Since eclipselink 2.5.x is part of Kepler simultaneous release[1], and 2.5.1
came out with Kepler SR1, I wonder if we should have 2.5.1 everywhere we have
eclipse 4.3.1 and other eclipse projects that came with SR1 release?
I think we should have it for rawhide/f20, and maybe f19 too.
[0] http://www.eclipse.org/eclipselink/releases/2.5.php
[1] http://projects.eclipse.org/releases/kepler
--
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=GacQneKW2m&a=cc_unsubscribe
https://bugzilla.redhat.com/show_bug.cgi?id=1157983
Bug ID: 1157983
Summary: maven-shared-utils: Test failures
Product: Fedora
Version: rawhide
Component: maven-shared-utils
Assignee: msrb(a)redhat.com
Reporter: mizdebsk(a)redhat.com
QA Contact: extras-qa(a)fedoraproject.org
CC: java-sig-commits(a)lists.fedoraproject.org,
mizdebsk(a)redhat.com, msrb(a)redhat.com,
tradej(a)redhat.com
Description of problem:
Update of maven-shared-utils to version 0.7 introduced 2 test failures, which
shourd be investigated.
Version-Release number of selected component (if applicable):
0.7-1
Failed tests:
FileUtilsTest.isASymbolicLink:1375 null
DirectoryScannerTest.followSymlinksFalse:132 expected:<9> but was:<11>
Tests run: 843, Failures: 2, Errors: 0, Skipped: 24
isASymbolicLink(org.apache.maven.shared.utils.io.FileUtilsTest) Time elapsed:
0.011 sec <<< FAILURE!
java.lang.AssertionError: null
at org.junit.Assert.fail(Assert.java:86)
at org.junit.Assert.assertTrue(Assert.java:41)
at org.junit.Assert.assertTrue(Assert.java:52)
at
org.apache.maven.shared.utils.io.FileUtilsTest.isASymbolicLink(FileUtilsTest.java:1375)
followSymlinksFalse(org.apache.maven.shared.utils.io.DirectoryScannerTest)
Time elapsed: 0.002 sec <<< FAILURE!
java.lang.AssertionError: expected:<9> but was:<11>
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.failNotEquals(Assert.java:743)
at org.junit.Assert.assertEquals(Assert.java:118)
at org.junit.Assert.assertEquals(Assert.java:555)
at org.junit.Assert.assertEquals(Assert.java:542)
at
org.apache.maven.shared.utils.io.DirectoryScannerTest.followSymlinksFalse(DirectoryScannerTest.java:132)
--
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=JOXEy6pH7e&a=cc_unsubscribe
https://bugzilla.redhat.com/show_bug.cgi?id=1189956
Bug ID: 1189956
Summary: ZooKeeper client (zkCli.sh) fails to start
Product: Fedora
Version: 21
Component: zookeeper
Severity: urgent
Assignee: tstclair(a)redhat.com
Reporter: ctubbsii-fedora(a)apache.org
QA Contact: extras-qa(a)fedoraproject.org
CC: ethan(a)ethantuttle.com,
java-sig-commits(a)lists.fedoraproject.org,
jeff(a)ocjtech.us, s(a)shk.io, tstclair(a)redhat.com
Created attachment 988644
--> https://bugzilla.redhat.com/attachment.cgi?id=988644&action=edit
stack trace
Description of problem:
zkCli.sh fails to start, due to classpath issues
Version-Release number of selected component (if applicable):
zookeeper-3.4.6-2.fc21.x86_64
How reproducible:
Always
Steps to Reproduce:
1. yum install zookeeper
2. zkCli.sh
Actual results:
A ClassNotFoundException occurs regarding a log4j LogManager class.
Expected results:
Connect to specified zookeeper service or error message about service not
running.
Additional info:
May be related to #1181487
--
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=n1BwQYSngu&a=cc_unsubscribe