ox update 6.20. -> 6.22

[pewi]

Hallo, ich habe nach der Anleitung in oxpedia auf unserem Testsystem mit Debian 6.0 den update von ox 6.20.7 Rev10 -> 6.22 durchgeführt. Der update lief problemlos. Allerdings stellt sich heraus, dass es Paketabhängigkeiten zur Version 6.20.7 bestehen, so zB in open-xchange-meta-mobility:
open-xchange-meta-mobility
Depends: open-xchange-eas 6.20.7.0-3
Depends: open-xchange-eas-provisioning-gui 6.22.1-7
Depends: open-xchange-eas-provisioning-mail 6.22.1-9
Depends: open-xchange-help-usm-eas 6.22.1-7
Depends: open-xchange-usm 6.22.1-6

Kann das wirklich sein?

In der Anleitung zum Upgrade von 6.20-> 6.22 heißte es :
It is safe to remove:
All files and subdirectories below:
/opt/open-xchange/etc/admindaemon
/opt/open-xchange/etc/common
/opt/open-xchange/etc/groupware

Wenn man o.g. Verzeichnisse löscht, löscht man u.a die Konfiguration für das open-xchange-eas Paket welches ja aufgrund der Abhängigkeit installiert bleiben muss. Deswegen läuft auch folgendes bundle nicht, weil die entsprechende Konfigurationsdatei fehlt:
bundlename: com.openexchange.system.extension status: RESOLVED

Leider kann man das Paket open-xchange-eas nicht mehr nachinstallieren, weil es nicht mehr im Repositorie von 6.22 zur Verfügung steht.


Kann das jemand bestätigen oder was mache ich hier falsch?

Gruß
Peter

[Martin Heiland]

Hallo Peter,

die Repositories für EAS stehen auch mit 6.22 zur Verfügung, unter http://software.open-xchange.com/OX6...ilityOXtender/. Wenn noch 6.20 Pakete auf dem System installiert sind, kann man die genannten Verzeichnisse natürlich *nicht* gefahrlos löschen. Die Aussage bezieht sich auf ein abgeschlossenes Update bei dem alle Pakete aktualisiert wurden.

Gruß
Martin

[pewi]

Hallo Martin, Danke! Ich hatte das Repository für EAS nicht eingetragen, deswegen wurden nicht alle Pakte aktualisiert.
Gruß
Peter

[pewi]

Nachdem ich den update von ox 6.20 -> 6.22 auf unserem Debian 6 Testsystem noch einmal durchgeführt habe, habe ich festgestellt, dass folgendes bundle auf "RESOLVED" steht:
bundlename: com.openexchange.system.extension status: RESOLVED

Wenn ich das bundle starte, steht folgendes im Logfile open-xchange.log.0 :

Jan 10, 2013 4:58:14 PM com.openexchange.log.internal.LoggerTask call
INFO: Logged at: com.openexchange.control.internal.GeneralControl.s tart(GeneralControl.java:103)
control command: start package com.openexchange.system.extension
Jan 10, 2013 4:58:14 PM com.openexchange.log.internal.LoggerTask call
SEVERE: Logged at: com.openexchange.control.internal.GeneralControl.s tart(GeneralControl.java:112)
cannot start bundle: com.openexchange.system.extension
org.osgi.framework.BundleException: A fragment bundle cannot be started: com.openexchange.system.extension_6.22.1 [130]
at org.eclipse.osgi.framework.internal.core.BundleFra gment.startWorker(BundleFragment.java:224)
at org.eclipse.osgi.framework.internal.core.AbstractB undle.start(AbstractBundle.java:299)
at org.eclipse.osgi.framework.internal.core.AbstractB undle.start(AbstractBundle.java:291)
at com.openexchange.control.internal.GeneralControl.s tart(GeneralControl.java:107)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Nativ e Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Native MethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(De legatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:616)
at com.sun.jmx.mbeanserver.StandardMBeanIntrospector. invokeM2(StandardMBeanIntrospector.java:111)
at com.sun.jmx.mbeanserver.StandardMBeanIntrospector. invokeM2(StandardMBeanIntrospector.java:45)
at com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM( MBeanIntrospector.java:226)
at com.sun.jmx.mbeanserver.PerInterface.invoke(PerInt erface.java:138)
at com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanS upport.java:251)
at com.sun.jmx.interceptor.DefaultMBeanServerIntercep tor.invoke(DefaultMBeanServerInterceptor.java:857)
at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxM BeanServer.java:795)
at javax.management.remote.rmi.RMIConnectionImpl.doOp eration(RMIConnectionImpl.java:1450)
at javax.management.remote.rmi.RMIConnectionImpl.acce ss$200(RMIConnectionImpl.java:90)
at javax.management.remote.rmi.RMIConnectionImpl$Priv ilegedOperation.run(RMIConnectionImpl.java:1285)
at javax.management.remote.rmi.RMIConnectionImpl.doPr ivilegedOperation(RMIConnectionImpl.java:1383)
at javax.management.remote.rmi.RMIConnectionImpl.invo ke(RMIConnectionImpl.java:807)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Nativ e Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Native MethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(De legatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:616)
at sun.rmi.server.UnicastServerRef.dispatch(UnicastSe rverRef.java:322)
at sun.rmi.transport.Transport$1.run(Transport.java:1 77)
at java.security.AccessController.doPrivileged(Native Method)
at sun.rmi.transport.Transport.serviceCall(Transport. java:173)
at sun.rmi.transport.tcp.TCPTransport.handleMessages( TCPTransport.java:553)
at sun.rmi.transport.tcp.TCPTransport$ConnectionHandl er.run0(TCPTransport.java:808)
at sun.rmi.transport.tcp.TCPTransport$ConnectionHandl er.run(TCPTransport.java:667)
at java.util.concurrent.ThreadPoolExecutor.runWorker( ThreadPoolExecutor.java:1110)
at java.util.concurrent.ThreadPoolExecutor$Worker.run (ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:636)

Kann ich bitte hierzu nochmal eine Info bekommen, was hier zu tun ist?
Gruß
Peter

[Martin Heiland]

Hallo,

das ist kein Problem da es sich um ein fragment bundle handelt, es muss nicht zwingend gestartet sein sondern nur im OSGI context "existieren".

Gruß
Martin