rado

Erstellte Forenantworten

6 Beiträge anzeigen - 1 bis 6 (von insgesamt 6)
  • Autor
    Beiträge
  • als Antwort auf: Fehlermeldung nach Server-Upgrade von v2.0.0.4 auf v2.0.1.0 #5095
    rado
    Teilnehmer

    Hallo Jens,

    das System lief jetzt einige Monate mit der Version 2.0.0.4 stabil, bis vor kurzem plötzlich keine Anmeldung mehr möglich war. Beim Start des Systems ist uns jetzt aufgefallen, dass damals anscheinend doch eine (teilweise) Migration auf Datenbankschema 2.0.1.0 durchgeführt wurde.

    Die aktuelle Fehlermeldung beim Start der Version 2.0.0.4 lautet:

    19:15:31,163 INFO [stdout] (ServerService Thread Pool — 77) Starting j-lawyer.org database migrations…
    19:15:31,188 INFO [org.flywaydb.core.internal.license.VersionPrinter] (ServerService Thread Pool — 77) Flyway Community Edition 5.2.1 by Boxfuse
    19:15:31,199 INFO [org.flywaydb.core.internal.database.DatabaseFactory] (ServerService Thread Pool — 77) Database: jdbc:mysql://xxx.xxx.xxx.xxx:3306/jlawyerdb (MySQL 5.5)
    19:15:31,542 INFO [org.flywaydb.core.internal.command.DbValidate] (ServerService Thread Pool — 77) Successfully validated 78 migrations (execution time 00:00.233s)
    19:15:31,557 INFO [org.flywaydb.core.internal.command.DbMigrate] (ServerService Thread Pool — 77) Current version of schema jlawyerdb: 2.0.1.0
    19:15:31,558 WARN [org.flywaydb.core.internal.command.DbMigrate] (ServerService Thread Pool — 77) Schema jlawyerdb has a version (2.0.1.0) that is newer than the latest available migration (2.0.0.4) !
    19:15:31,558 WARN [org.flywaydb.core.internal.command.DbMigrate] (ServerService Thread Pool — 77) Schema jlawyerdb contains a failed future migration to version 2.0.1.0 !

    Hier einmal das aktuelle Schema der security_users Tabelle:

    principalId varchar(50) NO PRI NULL
    password varchar(200) YES NULL
    lawyer tinyint(4) YES NULL
    countryCode varchar(10) YES NULL
    areaCode varchar(10) YES NULL
    emailAddress varchar(80) YES NULL
    emailInType varchar(15) YES NULL
    emailInServer varchar(80) YES NULL
    emailInUser varchar(75) YES NULL
    emailInPwd varchar(75) YES NULL
    emailOutServer varchar(80) YES NULL
    emailOutUser varchar(75) YES NULL
    emailOutPwd varchar(75) YES NULL
    emailSenderName varchar(150) YES NULL
    emailSignature varchar(3500) YES NULL
    emailInSsl tinyint(4) YES NULL
    emailOutSsl tinyint(4) YES NULL
    emailStartTls tinyint(4) YES NULL
    settings mediumblob YES NULL
    beaCertificate mediumblob YES NULL
    beaCertificateAutoLogin tinyint(4) YES NULL
    beaCertificatePassword varchar(50) YES NULL
    emailOutPort varchar(30) YES NULL
    abbreviation varchar(50) YES NULL
    primary_group varchar(50) YES MUL NULL
    cloudHost varchar(250) YES NULL
    cloudPort int(11) NO NULL
    cloudSsl tinyint(4) YES NULL
    cloudUser varchar(50) YES NULL
    cloudPassword varchar(50) YES NULL
    cloudPath varchar(250) YES NULL
    displayName varchar(250) YES NULL
    voipUser varchar(100) YES NULL
    voipPassword varchar(100) YES NULL
    voipId varchar(50) YES NULL

    Ein Start mit Version 2.0.1.0 bekräftigt die Annahme einer nicht vollständig erfolgreichen Migration. Hier starten die Fehlermeldungen mit:

    18:00:41,223 INFO [org.flywaydb.core.internal.database.DatabaseFactory] (ServerService Thread Pool — 75) Database: jdbc:mysql://xxx.xxx.xxx.xxx:3306/jlawyerdb (MySQL 5.5)
    18:00:41,599 ERROR [org.jlawyer.persistence.DatabaseMigrator] (ServerService Thread Pool — 75) exception caught: org.flywaydb.core.api.FlywayException: Validate failed: Detected failed migration to version 2.0.1.0 (AddVoipIdToUser)
    at org.flywaydb.core.Flyway.doValidate(Flyway.java:1467)
    at org.flywaydb.core.Flyway.access$100(Flyway.java:82)
    at org.flywaydb.core.Flyway$1.execute(Flyway.java:1349)
    at org.flywaydb.core.Flyway$1.execute(Flyway.java:1341)
    at org.flywaydb.core.Flyway.execute(Flyway.java:1696)
    at org.flywaydb.core.Flyway.migrate(Flyway.java:1341)
    at org.jlawyer.persistence.DatabaseMigrator.integrate(DatabaseMigrator.java:732)
    at org.hibernate.internal.SessionFactoryImpl.<init>(SessionFactoryImpl.java:276)
    at org.hibernate.boot.internal.SessionFactoryBuilderImpl.build(SessionFactoryBuilderImpl.java:467)
    at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:939)
    at org.jboss.as.jpa.hibernate5.TwoPhaseBootstrapImpl.build(TwoPhaseBootstrapImpl.java:44)
    at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:170)
    at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:128)
    at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:649)
    at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1.run(PersistenceUnitServiceImpl.java:212)
    at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
    at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982)
    at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
    at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1377)
    at java.lang.Thread.run(Thread.java:748)
    at org.jboss.threads.JBossThread.run(JBossThread.java:485)

    Wir wären dir für Lösungsvorschläge sehr dankbar, weil wir so mit J-Lawyer gar nicht mehr arbeiten können und dringend auf die Daten angewiesen sind.

    Viele Grüße

    Dirk

    rado
    Teilnehmer

    Vielen Dank,
    jetzt funktioniert alles perfekt. Docker auf dem NAS, die Datenbank (MariaDB 10) und Daten außerhalb auf dem NAS, so dass sie gebackupt werden können.
    Docker benotigt m.E. weniger Overhead und ist absolut unproblematisch. Viele Wege führen aber ja nach Rom. 😉
    Eine Bitte aber noch: Das beA-Softwarezertifikat-Passwort liegt unverschlüsselt in der Datenbank, ist also nicht verschlüsselt, wie das j-lawyer-Passwort. Das sollte m.E. geändert werden, wenn möglich.
    Vielen Dank nochmal und sonnige Grüße
    Dirk

    als Antwort auf: Aktennummern von Hand vergeben #841
    rado
    Teilnehmer

    Hallo Jens,

    ich habe die einzelnen Schriftstücke einer Akte für die vergangenen Jahre schon in einer zusammengebauten PDF-Datei zusammengefasst, so dass ich für die Erfassung von einem erträglichen Bearbeiterengagement ausging.

    Für die Zukunft bin ich mit j-Lawyer ja gerüstet, da auch hohe Aktenzahlen offenbar gut verwaltet werden können.

    Wenn da was geht, wäre es super.

    Gruß
    Dirk

    als Antwort auf: Aktennummern von Hand vergeben #839
    rado
    Teilnehmer

    Hallo Jens,

    danke für die schnelle Antwort. Es geht um rund 300 Akten jährlich.

    Gruß
    Dirk

    als Antwort auf: Aktennummern von Hand vergeben #836
    rado
    Teilnehmer

    Hallo J-Lawyer,

    ich habe leider ein ähnliches Problem (mit Kubuntu 13.10 64-bit). Ich habe nur für das Jahr 2014 meine Akten wunderbar anlegen können. Nun würde ich gern für 2013 u.s.w. meine vorherigen Akten einpflegen. Die Aktenzeichenautomatik scheint aber nur das aktuelle Jahr (2014) zu generieren. Gibt es hier eine Abhilfemöglichkeit? Ich bin nämlich ansonsten bisher sehr angetan von dem hervorragenden Programm.

    Vielen Dank & viele Grüße

    Dirk

    als Antwort auf: PDF Standardrogramm #835
    rado
    Teilnehmer

    Hallo J-Lawyer,

    ich habe leider dasselbe Problem (mit Kubuntu 13.10 64-bit). Auch bei mir wird PDF Studio 9 ignoriert. Unter Systemeinstellung-Dateizuordnungen-application-pdf steht in der Rangfolge PDF Studio 9 oben und der Dokument-Betrachter unten: ohne Erfolg. Auch eine Vertauschung der beiden Plätze bringt nicht das gewünschte Ergebnis. Was kann ich tun?

    Vielen Dank & viele Grüße

    Dirk

6 Beiträge anzeigen - 1 bis 6 (von insgesamt 6)