Bug 848632 - spacewalk-java has incorrect symlinks to jar files from conflicting repositories
Summary: spacewalk-java has incorrect symlinks to jar files from conflicting repositories
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Spacewalk
Classification: Community
Component: Server
Version: 1.7
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: ---
Assignee: Jan Pazdziora
QA Contact: Red Hat Satellite QA List
URL:
Whiteboard:
Depends On:
Blocks: space18
TreeView+ depends on / blocked
 
Reported: 2012-08-16 05:14 UTC by William Brown
Modified: 2012-12-07 20:01 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-12-07 20:01:00 UTC
Embargoed:


Attachments (Terms of Use)

Description William Brown 2012-08-16 05:14:57 UTC
Background:

This system was fedora 16 pre-upgraded to fedora 17 x86_64. It was running spacewalk before the upgrade

Description of problem:
After fedora 17 upgrade, spacewalk will not be able to start tomcat6. Spacewalk itself may not operate correctly on fedora17 irrespective of the upgrade process.

Upon inspection of catalina logs, certain jar files are not able to be opened. 

It would appear that struts and hibernate3 are now avaliable in fedora-updates from f17, rather than jpackage. However, they install vastly different files. the jpackage variants install /usr/share/java/[hibernate3|struts].jar, where as the fedora-updates provided packages install to /usr/share/java/[hibernate3|struts]/<some jar files here>.jar

This makes the problem somewhat more difficult than simply moving the symlinks from /WEB-INF/lib/[hibernate3|struts].jar as they don't allign to what fedora-updates install. 

I am not sure if the upgrade from fedora 16 -> 17 affected this. I have attempted to reinstall spacewalk-java as this appears to be the package in change of the symlinks in question. 

Steps to Reproduce:
1. Install spacewalk 
2. Attempt to start spacewalk
  
Actual results:
Tomcat will not start

Expected results:
Tomcat starts

Additional info:
running "yum downgrade struts hibernate3" appears to be a temporary work around. Adding these packages to the yum excludes list will prevent the issue reoccuring. But this is not a solution, only a temporary fix.

Comment 1 Jan Pazdziora 2012-08-16 11:15:09 UTC
What are the errors in the catalina.out exactly?

What is the output of

  rpm -q spacewalk-java

?

Comment 2 William Brown 2012-08-16 11:49:30 UTC
Aug 16, 2012 1:05:38 PM org.apache.catalina.core.ContainerBase addChildInternal
SEVERE: ContainerBase.addChild: start: 
LifecycleException:  start: :  java.io.IOException: Failed to access resource /WEB-INF/lib/hibernate3.jar
	at org.apache.catalina.loader.WebappLoader.start(WebappLoader.java:709)
	at org.apache.catalina.core.StandardContext.start(StandardContext.java:4575)
	at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:799)
	at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:779)
	at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:601)
	at org.apache.catalina.startup.HostConfig.deployDescriptor(HostConfig.java:675)
	at org.apache.catalina.startup.HostConfig.deployDescriptors(HostConfig.java:601)
	at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:502)
	at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1317)
	at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:324)
	at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:142)
	at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1065)
	at org.apache.catalina.core.StandardHost.start(StandardHost.java:840)
	at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1057)
	at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:463)
	at org.apache.catalina.core.StandardService.start(StandardService.java:525)
	at org.apache.catalina.core.StandardServer.start(StandardServer.java:754)
	at org.apache.catalina.startup.Catalina.start(Catalina.java:595)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:601)
	at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:289)
	at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:414)



spacewalk-java-1.7.54-1.fc16.noarch

Comment 3 Jan Pazdziora 2012-08-16 11:55:40 UTC
Once on Fedora 17, you really should have packages built for
Fedora 17, which the .fc16 is not. Spacewalk 1.7 was not released for 
Fedora 17. Unless you plan on going with Spacewalk nightly (beware: no 
supported upgrade path from nightly to the next release), I recommend 
you restore your original Fedora 16 installation from backup..

Comment 4 William Brown 2012-08-17 06:19:26 UTC
Like I mentioned, I have a temporary work around. I will consider restoring from backups. When is the 1.8 version of spacewalk with f17 support likely to be released?

Comment 5 Jan Pazdziora 2012-12-07 20:01:00 UTC
Spacewalk 1.8 was released one months ago and it includes packages for Fedora 17. Closing as CURRENTRELEASE.


Note You need to log in before you can comment on or make changes to this bug.