[Bug 1247793] New: /usr/bin/gradle-local missing in F22
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1247793
Bug ID: 1247793
Summary: /usr/bin/gradle-local missing in F22
Product: Fedora
Version: 22
Component: javapackages-tools
Assignee: mizdebsk(a)redhat.com
Reporter: orion(a)cora.nwra.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
Description of problem:
/usr/bin/gradle isn't shipped in the F22 version of gradle-local. Since gradle
is in F22, would be nice to have gradle-local as well.
Version-Release number of selected component (if applicable):
4.3.2-6.fc22
--
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=0bT4lTdKRV&a=cc_unsubscribe
8 years, 5 months
[Bug 1276729] New: xmvn: goal org.fedoraproject.xmvn:xmvn-mojo:2.5.0:builddep failed. UnsupportedOperationException
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1276729
Bug ID: 1276729
Summary: xmvn: goal
org.fedoraproject.xmvn:xmvn-mojo:2.5.0:builddep
failed. UnsupportedOperationException
Product: Fedora
Version: rawhide
Component: xmvn
Assignee: mizdebsk(a)redhat.com
Reporter: msrb(a)redhat.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
Description of problem:
Jenkins fails to build with new XMvn:
[ERROR] Failed to execute goal org.fedoraproject.xmvn:xmvn-mojo:2.5.0:builddep
(default-cli) on project pom: Execution default-cli of goal
org.fedoraproject.xmvn:xmvn-mojo:2.5.0:builddep failed.
UnsupportedOperationException -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal
org.fedoraproject.xmvn:xmvn-mojo:2.5.0:builddep (default-cli) on project pom:
Execution default-cli of goal org.fedoraproject.xmvn:xmvn-mojo:2.5.0:builddep
failed.
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:224)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
at
org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:307)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:193)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:106)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:862)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:286)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:197)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
at
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
at
org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
Caused by: org.apache.maven.plugin.PluginExecutionException: Execution
default-cli of goal org.fedoraproject.xmvn:xmvn-mojo:2.5.0:builddep failed.
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:145)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
... 20 more
Caused by: java.lang.UnsupportedOperationException
at java.util.AbstractList.set(AbstractList.java:132)
at java.util.AbstractList$ListItr.set(AbstractList.java:426)
at
org.fedoraproject.xmvn.model.impl.DefaultModelProcessor.visitBuildResource(DefaultModelProcessor.java:622)
at
org.fedoraproject.xmvn.model.impl.DefaultModelProcessor.visitBuild(DefaultModelProcessor.java:369)
at
org.fedoraproject.xmvn.model.impl.DefaultModelProcessor.visit(DefaultModelProcessor.java:311)
at
org.fedoraproject.xmvn.model.impl.DefaultModelProcessor.processModel(DefaultModelProcessor.java:83)
at org.fedoraproject.xmvn.mojo.BuilddepMojo.execute(BuilddepMojo.java:145)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
... 21 more
Version-Release number of selected component (if applicable):
xmvn-2.5.0-2.fc24.noarch
javapackages-tools-4.6.0-8.fc24.noarch
java-1.8.0-openjdk-1.8.0.60-15.b28.fc24.x86_64
How reproducible:
always
Steps to Reproduce:
1. rebuild jenkins package in master from 961bbdcc
2.
3.
--
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=b9vB16PauX&a=cc_unsubscribe
8 years, 5 months
[Bug 1261458] New: Zookeeper service fails to start due to classpath errors, logging no error
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1261458
Bug ID: 1261458
Summary: Zookeeper service fails to start due to classpath
errors, logging no error
Product: Fedora
Version: 22
Component: zookeeper
Assignee: tstclair(a)redhat.com
Reporter: KevinFarshaw(a)mailinator.com
QA Contact: extras-qa(a)fedoraproject.org
CC: ctubbsii-fedora(a)apache.org, 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 1071694
--> https://bugzilla.redhat.com/attachment.cgi?id=1071694&action=edit
Patched /usr/libexec/zkEnv.sh
I've reviewed the other zookeeper issues, they report other problems and
concern f21 rather the the current f22.
Description of problem:
After sudo cp /etc/zookeeper/zoo_sample.cfg /etc/zookeeper/zoo.cfg,
Starting the zookeeper service fails silently without logging any error
to console or journal.
Manually starting it in the foreground using:
sudo -u zookeeper /usr/bin/zkServer.sh start-foreground
Gives:
JMX enabled by default
Using config: /etc/zookeeper/zoo.cfg
SLF4J: Class path contains multiple SLF4J bindings.
SLF4J: Found binding in
[jar:file:/usr/share/java/slf4j/slf4j-log4j12.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: Found binding in
[jar:file:/usr/share/java/slf4j/slf4j-simple.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: Found binding in
[jar:file:/usr/share/java/slf4j/slf4j-nop.jar!/org/slf4j/impl/StaticLoggerBinder.class]
Version-Release number of selected component (if applicable):
zookeeper-3.4.6-4.fc22.x86_64
How reproducible:
always
Steps to Reproduce:
1. sudo cp /etc/zookeeper/zoo_sample.cfg /etc/zookeeper/zoo.cfg
2. systemctl start zookeeper (fails, nothing logged)
3. sudo -u zookeeper /usr/bin/zkServer.sh start-foreground (logs error to
stderr)
Additional info:
Tipped off by https://issues.apache.org/jira/browse/SOLR-2369, it appears
that:
1. The classpath used to launch zk contains multiple jars of
slog4j logging providers.
2. This is not allowed as documented by sl4fj at
http://www.slf4j.org/codes.html#multiple_bindings
3. Inspection of the classpath setup by /usr/libexec/zkEnv.sh shows much
duplication, including multiple bindings.
Attached modified zkEnv.sh in which I've:
1. Removed duplicates.
2. Commented out alternate bindings and allegedly redundant jars.
3. I did not intentionally remove any jars originally in the file (only
commented).
4. Added individual log4j jars from appropriate package.
After updating zkEnv.sh, starting the service with systemctl complains
about missing precondition of file at /var/lib/zookeeper/data/myid.
After creating the file (with a single line containing an id such as
the digit '1'), zookeeper starts.
I have not exercised zookeeper to see whether something else is broken
(or was broken by the changes), but it does start up properly now.
--
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=laEkcaD2Z1&a=cc_unsubscribe
_______________________________________________
java-sig-commits mailing list
java-sig-commits(a)lists.fedoraproject.org
http://lists.fedoraproject.org/postorius/java-sig-commits@lists.fedorapro...
8 years, 5 months
[Bug 1147105] New: CATALINA_OPTS are only read when SECURITY_MANAGER is true
by Red Hat Bugzilla
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
8 years, 5 months