I am trying to upgrade keycloak(running in standalone mode) from version 8 to 12. I have followed the steps mentioned here
I deleted the data/tx-object-store/ transaction directory, and copied the standalone directory from version 8.
I ran the upgrade script. I can see that there are no failures and all the steps were SUCCESS.
I try to start the server with this command
sudo ./standalone.sh -b 0.0.0.0 &
Server started successfully, I can reach keycloak admin console and also able to login. I can see that the data(users, groups, etc) is successfully migrated as well.
After this, I stopped keycloak
sudo ./jboss-cli.sh --connect command=:shutdown
Which ran Okay. Now If I try to start it again, I see the following errors and keycloak doesn't boot up
06:30:00,080 FATAL [org.keycloak.services] (ServerService Thread Pool -- 66) Error during startup: java.lang.RuntimeException: Failed to connect to database
at org.keycloak.connections.jpa.DefaultJpaConnectionProviderFactory.getConnection(DefaultJpaConnectionProviderFactory.java:377)
at org.keycloak.connections.jpa.updater.liquibase.lock.LiquibaseDBLockProvider.lazyInit(LiquibaseDBLockProvider.java:65)
at org.keycloak.connections.jpa.updater.liquibase.lock.LiquibaseDBLockProvider.lambda$waitForLock$2(LiquibaseDBLockProvider.java:96)
at org.keycloak.models.utils.KeycloakModelUtils.suspendJtaTransaction(KeycloakModelUtils.java:654)
at org.keycloak.connections.jpa.updater.liquibase.lock.LiquibaseDBLockProvider.waitForLock(LiquibaseDBLockProvider.java:94)
at org.keycloak.services.resources.KeycloakApplication$1.run(KeycloakApplication.java:136)
at org.keycloak.models.utils.KeycloakModelUtils.runJobInTransaction(KeycloakModelUtils.java:228)
at org.keycloak.services.resources.KeycloakApplication.startup(KeycloakApplication.java:129)
at org.keycloak.provider.wildfly.WildflyPlatform.onStartup(WildflyPlatform.java:29)
at org.keycloak.services.resources.KeycloakApplication.<init>(KeycloakApplication.java:115)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
at org.jboss.resteasy.core.ConstructorInjectorImpl.construct(ConstructorInjectorImpl.java:152)
at org.jboss.resteasy.spi.ResteasyProviderFactory.createProviderInstance(ResteasyProviderFactory.java:2815)
at org.jboss.resteasy.spi.ResteasyDeployment.createApplication(ResteasyDeployment.java:371)
at org.jboss.resteasy.spi.ResteasyDeployment.startInternal(ResteasyDeployment.java:283)
at org.jboss.resteasy.spi.ResteasyDeployment.start(ResteasyDeployment.java:93)
at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.init(ServletContainerDispatcher.java:140)
at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.init(HttpServletDispatcher.java:42)
at io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:117)
at org.wildfly.extension.undertow.security.RunAsLifecycleInterceptor.init(RunAsLifecycleInterceptor.java:78)
at io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:103)
at io.undertow.servlet.core.ManagedServlet$DefaultInstanceStrategy.start(ManagedServlet.java:305)
at io.undertow.servlet.core.ManagedServlet.createServlet(ManagedServlet.java:145)
at io.undertow.servlet.core.DeploymentManagerImpl$2.call(DeploymentManagerImpl.java:588)
at io.undertow.servlet.core.DeploymentManagerImpl$2.call(DeploymentManagerImpl.java:559)
at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:42)
at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1530)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1530)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1530)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1530)
at io.undertow.servlet.core.DeploymentManagerImpl.start(DeploymentManagerImpl.java:601)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:97)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:78)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1990)
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:513)
Caused by: java.sql.SQLException: javax.resource.ResourceException: IJ000453: Unable to get managed connection for java:jboss/datasources/KeycloakDS
at org.jboss.jca.adapters.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:159)
at org.jboss.as.connector.subsystems.datasources.WildFlyDataSource.getConnection(WildFlyDataSource.java:64)
at org.keycloak.connections.jpa.DefaultJpaConnectionProviderFactory.getConnection(DefaultJpaConnectionProviderFactory.java:371)
... 45 more
Caused by: javax.resource.ResourceException: IJ000453: Unable to get managed connection for java:jboss/datasources/KeycloakDS
at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.getManagedConnection(AbstractConnectionManager.java:690)
at org.jboss.jca.core.connectionmanager.tx.TxConnectionManagerImpl.getManagedConnection(TxConnectionManagerImpl.java:440)
at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.allocateConnection(AbstractConnectionManager.java:789)
at org.jboss.jca.adapters.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:151)
... 47 more
Caused by: javax.resource.ResourceException: IJ031084: Unable to create connection
at org.jboss.jca.adapters.jdbc.local.LocalManagedConnectionFactory.createLocalManagedConnection(LocalManagedConnectionFactory.java:345)
at org.jboss.jca.adapters.jdbc.local.LocalManagedConnectionFactory.getLocalManagedConnection(LocalManagedConnectionFactory.java:352)
at org.jboss.jca.adapters.jdbc.local.LocalManagedConnectionFactory.createManagedConnection(LocalManagedConnectionFactory.java:287)
at org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreConcurrentLinkedDequeManagedConnectionPool.createConnectionEventListener(SemaphoreConcurrentLinkedDequeManagedConnectionPool.java:1322)
at org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreConcurrentLinkedDequeManagedConnectionPool.getConnection(SemaphoreConcurrentLinkedDequeManagedConnectionPool.java:499)
at org.jboss.jca.core.connectionmanager.pool.AbstractPool.getSimpleConnection(AbstractPool.java:632)
at org.jboss.jca.core.connectionmanager.pool.AbstractPool.getConnection(AbstractPool.java:604)
at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.getManagedConnection(AbstractConnectionManager.java:624)
... 50 more
Caused by: org.h2.jdbc.JdbcSQLException: Constraint "FK_OUSE064PLMLR732LXJCN1Q5F1" already exists; SQL statement:
ALTER TABLE PUBLIC.SCOPE_MAPPING ADD CONSTRAINT PUBLIC.FK_OUSE064PLMLR732LXJCN1Q5F1 FOREIGN KEY(CLIENT_ID) INDEX PUBLIC.FK_OUSE064PLMLR732LXJCN1Q5F1_INDEX_8 REFERENCES PUBLIC.CLIENT(ID) NOCHECK [90045-197]
at org.h2.message.DbException.getJdbcSQLException(DbException.java:357)
at org.h2.message.DbException.get(DbException.java:179)
at org.h2.message.DbException.get(DbException.java:155)
at org.h2.command.ddl.AlterTableAddConstraint.tryUpdate(AlterTableAddConstraint.java:110)
at org.h2.command.ddl.AlterTableAddConstraint.update(AlterTableAddConstraint.java:78)
at org.h2.engine.MetaRecord.execute(MetaRecord.java:58)
at org.h2.engine.Database.open(Database.java:775)
at org.h2.engine.Database.openDatabase(Database.java:286)
at org.h2.engine.Database.<init>(Database.java:280)
at org.h2.engine.Engine.openSession(Engine.java:66)
at org.h2.engine.Engine.openSession(Engine.java:179)
at org.h2.engine.Engine.createSessionAndValidate(Engine.java:157)
at org.h2.engine.Engine.createSession(Engine.java:140)
at org.h2.engine.Engine.createSession(Engine.java:28)
at org.h2.engine.SessionRemote.connectEmbeddedOrServer(SessionRemote.java:351)
at org.h2.jdbc.JdbcConnection.<init>(JdbcConnection.java:124)
at org.h2.jdbc.JdbcConnection.<init>(JdbcConnection.java:103)
at org.h2.Driver.connect(Driver.java:69)
at org.jboss.jca.adapters.jdbc.local.LocalManagedConnectionFactory.createLocalManagedConnection(LocalManagedConnectionFactory.java:321)
... 57 more
I am using H2 in memory database. I tried installing keycloak 12 and upgrading several times. Everytime I have the same issue, Starts successfully the first time, and then fails there after.
Can anyone please help? It looks like when I start the server the second time, it is trying to do migration again.. Not sure though.
1.Get a copy of H2 1.4.196 (bug as noted here and at Keycloak H2 login failure: constraint already exists is with 4.1.197)
https://repo1.maven.org/maven2/com/h2database/h2/1.4.196/h2-1.4.196.jar
2.Get a copy of H2 1.4.197or later
https://repo1.maven.org/maven2/com/h2database/h2/1.4.199/h2-1.4.199.jar
Take a copy of DB backup from before the upgrade (ours was from 4.6.0)
Create a dump (will create backup.sql) with:
java -cp ~/ba-docker/h2-1.4.196.jar org.h2.tools.Script -url "jdbc:h2:./kc-data/keycloak;AUTO_SERVER=TRUE" -user sa -password sa (user and password can be confirmed in your standalone file)
Restore DB with newer version of H2
Command by default uses backup.sql
java -cp ~/ba-docker/h2-1.4.199.jar org.h2.tools.RunScript -url "jdbc:h2:./kcdata-restore;AUTO_SERVER=TRUE" -user sa -password sa
In KC data directory
Delete keycloak.mv.db and keycloak.trace.db
rm keycloak.trace.db
rm keycloak.mv.db
Copy your kcdata-restore.mv.db from step 4 to keycloak.mv.db
cp ../../kcdata-restore.mv.db keycloak.mv.db
Follow standard KC upgrade
Delete tx-object-store
rm -Rf tx-object-store/
And you should now be able to start, stop and restart without issues.
Copied answer from : https://keycloak.discourse.group/t/keycloak-10-0-2-doesnt-start-locally-twice/3320
Courtesy : #lieven_wk
Came across the same problem when trying to upgrade 3.1.0.Final to 11.0.2. Found out this was caused by https://github.com/h2database/h2database/issues/1247 26.
As a workaround, I dumped & restored the keycloak H2 datasource file before starting the new version:
Given:
Old KeyCloak is installed in keycloak-3.1.0.Final
New KeyCloak is installed in keycloak-11.0.2
Running standalone setup
Datasource is configured with below connection URL
jdbc:h2:${jboss.server.data.dir}/keycloak;AUTO_SERVER=TRUE
Dump old sql:
java -cp keycloak-3.1.0.Final/modules/system/layers/base/com/h2database/h2/main/h2-1.3.173.jar org.h2.tools.Script -url jdbc:h2:keycloak-3.1.0.Final/standalone/data/keycloak -user sa -password MYPASS -script ~/keycloak-testbackup.sql
Restore to new H2 file (make sure file doesn’t exists prior to running the restore):
java -cp keycloak-11.0.2/modules/system/layers/base/com/h2database/h2/main/h2-1.4.197.jar org.h2.tools.RunScript -url jdbc:h2:keycloak-11.0.2/standalone/data/keycloak -user sa -password MYPASS -script ~/keycloak-testbackup.sql
Now upon starting the application server (keycloak-11.0.2) for the first time, the schema is migrated to the latest version, and remains running properly at each restart.
Related
My Appsmith instance just upgraded to v1.6.4 and it's not booting up anymore. In the logs, I can see the exception below:
Caused by: com.mongodb.MongoCommandException: Command failed with error 17 (ProtocolError): 'Attempt to switch database target during SASL authentication.' on server mongo:27017. The full response is {"ok": 0.0, "errmsg": "Attempt to switch database target during SASL authentication.", "code": 17, "codeName": "ProtocolError"}
Is there anything I can do to bring up my Appsmith instance?
This is a breaking change that was introduced in v1.6.4 of Appsmith because of Spring library upgrades. A complete fix is described at: https://docs.appsmith.com/troubleshooting-guide/deployment-errors#server-not-booting-because-of-mongocommandexception
Step 1: Edit MongoDB URI
Adding &authSource=admin to the end of your APPSMITH_MONGODB_URI variable’s value in your docker.env file. For example, in your docker.env file, if you have the following line:
# Old config
APPSMITH_MONGODB_URI=mongodb://<your_username>:<your_password>#mongo/appsmith?retryWrites=true
Change it to the following (notice the only change is &authSource=admin. Do NOT copy-paste this whole line. Only add the &authSource=admin part to your existing value.
# New config
APPSMITH_MONGODB_URI=mongodb://<your_username>:<your_password>#mongo/appsmith?retryWrites=true&authSource=admin
Save the file.
Step 2: Restart server
Now restart your container with the following command:
sudo docker-compose up -d --force-recreate appsmith-internal-server
In a minute or two, the server should now come up and be ready.
CentOS 7
Docker 20.10.5
In my machine run PostgreSQL 9.5 and success open my db:
localhost:5432/sonar
And success open DB by PGAdmin
Nice.
Now in Docker I installed SonarQube 4.5. And want to connect to my db.
I try this:
sudo docker run -e SONARQUBE_JDBC_USERNAME=sonar -e SONARQUBE_JDBC_PASSWORD=sonar -e SONARQUBE_JDBC_URL=jdbc:postgresql://localhost:5432/sonar sonarqube:4.5.7
But I get error:
2021.04.20 11:47:55 INFO web[o.s.s.p.ServerImpl] SonarQube Server / 4.5.7 / e2afb0bff1b8be759789d2c1bc9348de6f519f83
2021.04.20 11:47:55 INFO web[o.s.c.p.Database] Create JDBC datasource for jdbc:postgresql://localhost:5432/sonar
2021.04.20 11:47:55 ERROR web[o.a.c.c.C.[.[.[/]] Exception sending context initialized event to listener instance of class org.sonar.server.platform.PlatformServletContextListener
java.lang.IllegalStateException: Can not connect to database. Please check connectivity and settings (see the properties prefixed by 'sonar.jdbc.').
at org.sonar.core.persistence.DefaultDatabase.checkConnection(DefaultDatabase.java:115) ~[sonar-core-4.5.7.jar:na]
at org.sonar.core.persistence.DefaultDatabase.start(DefaultDatabase.java:73) ~[sonar-core-4.5.7.jar:na]
I am upgrading my heroku database from a hobby dev to Standard 0 (using the official instructions https://devcenter.heroku.com/articles/upgrading-heroku-postgres-databases#upgrade-with-pg-copy-default).
All went well, until I promoted the new database and restarted the app. I then get the following error:
o.s.boot.SpringApplication : Application startup failed
...
org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'flywayInitializer' defined in class path resource [org/springframework/boot/autoconfigure/flyway/FlywayAutoConfiguration$FlywayConfiguration.class]: Invocation of init method failed; nested exception is org.flywaydb.core.api.FlywayException: Unable to obtain Jdbc connection from DataSource
...
Caused by: org.flywaydb.core.api.FlywayException: Unable to obtain Jdbc connection from DataSource
...
Caused by: org.postgresql.util.PSQLException: FATAL: no pg_hba.conf entry for host "54.xxx.xx.xxx", user "u94bf9vxxxxxx", database "d2mqk0b6xxxxxx", SSL off
...
If I swap back to the old database again, everything works again. The only thing that I am changing is the promoted database.
Is there a difference between connecting to hobby and standard databases that I need to be aware of?
The relevant part of my application.yml looks as follows:
spring:
datasource:
driverClassName: org.postgresql.Driver
url: ${JDBC_DATABASE_URL}
username: ${JDBC_DATABASE_USERNAME}
password: ${JDBC_DATABASE_PASSWORD}
flyway:
enabled: true
locations: classpath:db/migrations
Any suggestions on how I can debug this would be very welcome too.
Looks like you aren't connecting with SSL where it is required by Heroku PostgreSQL installs.
See Herokus documentation on SSL for PostgreSQL.
See also Herokus documentation for enabling SSL on JDBC connections.
You will need to add something like &ssl=true&sslfactory=org.postgresql.ssl.NonValidatingFactory to your JDBC URL.
I am naive in Postgres and clojure
I wanted to run this https://gitlab.com/dzaporozhets/clojure-picture-gallery
Install
git clone https://gitlab.com/clojure-code-examples/picture-gallery.git
cd picture-gallery
# Install dependencies
lein deps
# Create database
psql -c 'CREATE DATABASE gallery TEMPLATE template0'
Running
To start a web server for the application, run:
lein ring server
this is process I have to do.
1)) I had to git clone but git clone have not worked. they want to let me type id, password. like this:
Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation. All rights reserved.
C:\Users\jiji>git clone https://gitlab.com/clojure-code-examples/picture-gallery
.git
Cloning into 'picture-gallery'...
Username for 'https://gitlab.com': ji
Password for 'https://ji#gitlab.com':
fatal: Authentication failed for 'https://gitlab.com/clojure-code-examples/pictu
re-gallery.git/'
C:\Users\jiji>
anyway I downloaded source from web and unzip this file
2) I have problem when I write psql -c 'CREATE DATABASE gallery TEMPLATE template0'. I use Windows 7. Though I installed postgresql, 'psql' instruction have not worked in cmd window. I don't know how I can use 'psql' instruction in window. anyway I make gallery database like this
3) and I write lein ring server in cmd window
but I got error like this:
C:\Users\jiji\clojureproject\clojure-picture-gallery-master>lein ring server
picture-gallery is starting
Exception in thread "main" org.postgresql.util.PSQLException: The server request
ed password-based authentication, but no password was provided., compiling:(C:\U
sers\jiji\AppData\Local\Temp\form-init366034846235691962.clj:1:105)
at clojure.lang.Compiler.load(Compiler.java:7142)
at clojure.lang.Compiler.loadFile(Compiler.java:7086)
at clojure.main$load_script.invoke(main.clj:274)
at clojure.main$init_opt.invoke(main.clj:279)
at clojure.main$initialize.invoke(main.clj:307)
at clojure.main$null_opt.invoke(main.clj:342)
at clojure.main$main.doInvoke(main.clj:420)
at clojure.lang.RestFn.invoke(RestFn.java:421)
at clojure.lang.Var.invoke(Var.java:383)
at clojure.lang.AFn.applyToHelper(AFn.java:156)
at clojure.lang.Var.applyTo(Var.java:700)
at clojure.main.main(main.java:37)
Caused by: org.postgresql.util.PSQLException: The server requested password-base
d authentication, but no password was provided.
at org.postgresql.core.v3.ConnectionFactoryImpl.doAuthentication(Connect
ionFactoryImpl.java:473)
at org.postgresql.core.v3.ConnectionFactoryImpl.openConnectionImpl(Conne
ctionFactoryImpl.java:203)
at org.postgresql.core.ConnectionFactory.openConnection(ConnectionFactor
y.java:65)
at org.postgresql.jdbc2.AbstractJdbc2Connection.<init>(AbstractJdbc2Conn
ection.java:146)
at org.postgresql.jdbc3.AbstractJdbc3Connection.<init>(AbstractJdbc3Conn
ection.java:35)
at org.postgresql.jdbc3g.AbstractJdbc3gConnection.<init>(AbstractJdbc3gC
onnection.java:22)
at org.postgresql.jdbc4.AbstractJdbc4Connection.<init>(AbstractJdbc4Conn
ection.java:47)
at org.postgresql.jdbc4.Jdbc4Connection.<init>(Jdbc4Connection.java:30)
at org.postgresql.Driver.makeConnection(Driver.java:414)
at org.postgresql.Driver.connect(Driver.java:282)
at java.sql.DriverManager.getConnection(DriverManager.java:664)
at java.sql.DriverManager.getConnection(DriverManager.java:208)
at clojure.java.jdbc$get_connection.invoke(jdbc.clj:177)
at clojure.java.jdbc$get_connection.invoke(jdbc.clj:161)
at clojure.java.jdbc$get_connection.invoke(jdbc.clj:164)
at clojure.java.jdbc$with_connection_STAR_.invoke(jdbc.clj:300)
at picture_gallery.models.schema$table_exists_QMARK_.invoke(schema.clj:2
8)
at picture_gallery.models.schema$migrate.invoke(schema.clj:35)
at picture_gallery.handler$init.invoke(handler.clj:18)
at clojure.lang.Var.invoke(Var.java:375)
at ring.server.standalone$serve.doInvoke(standalone.clj:93)
at clojure.lang.RestFn.invoke(RestFn.java:423)
at ring.server.leiningen$serve.invoke(leiningen.clj:20)
at user$eval6633.invoke(form-init366034846235691962.clj:1)
at clojure.lang.Compiler.eval(Compiler.java:6703)
at clojure.lang.Compiler.eval(Compiler.java:6693)
at clojure.lang.Compiler.load(Compiler.java:7130)
... 11 more
Subprocess failed
C:\Users\jiji\clojureproject\clojure-picture-gallery-master>
I guess it is password problem. but I don't know what it means
in short I have three question about 1)),2)),3)) why they are not worked?
answerto question 3)
take a look at /src/picture_gallery/models/db.clj here https://gitlab.com/dzaporozhets/clojure-picture-gallery/blob/master/src/picture_gallery/models/db.clj#L4
either set you DATABASE_URL environment variable to contain valid postgres connection url or just use
(def db (or (System/getenv "DATABASE_URL")
"postgresql://user:password#localhost:5432/gallery"))
replace user and password before #localhost with your postgres's user and password
I am using WSO2 Governance Registry v 4.6.0 and am trying to migrate the structure I have in an H2 backed test instance to a Postgres backed production instance (separate VMs for the Web server and database) using client-checkin.
I have successfully checked out the registry from the H2 instance but I am struggling to check it in to the Postgress system.
On the test instance I ran
./checkin-client.sh co https://localhost:9443/registry -u admin -p admin -f /../../../registry_checkout/registry.dump
to create the dump.
On the production system I executed
./checkin-client.sh ci https://arc-gov:9443/registry -u admin -p admin -f /../registry.dump
and get the following error below. (And yes I know the password is the same, it will change when I get it to work!). The url here is that of the wso2 web server not the Postgres database.
Any help would be much appreciated.
[2014-10-09 10:34:05,672] ERROR - Error in restoring the path. Make sure the registry is up and running Or the username, password is correct! and check the user have the WRITE permission to the path.
path: /
registry url: https://arc-gov:9443/registry
username: admin {org.wso2.registry.checkin.Client}
org.wso2.carbon.registry.synchronization.SynchronizationException: message code: ERROR_IN_RESTORING, parameters: {path: /, registry url: https://arc-gov:9443/registry, username: admin
at org.wso2.carbon.registry.synchronization.operation.CheckInCommand.restoreFromFile(CheckInCommand.java:207)
at org.wso2.carbon.registry.synchronization.operation.CheckInCommand.execute(CheckInCommand.java:164)
at org.wso2.registry.checkin.Checkin.execute(Checkin.java:70)
at org.wso2.registry.checkin.Checkin.execute(Checkin.java:56)
at org.wso2.registry.checkin.Client.execute(Client.java:272)
at org.wso2.registry.checkin.Client.start(Client.java:67)
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:606)
at org.wso2.carbon.bootstrap.Bootstrap.loadClass(Bootstrap.java:63)
at org.wso2.carbon.bootstrap.CheckinClientBootstrap.main(CheckinClientBootstrap.java:36)
Caused by: org.wso2.carbon.registry.core.exceptions.RegistryException: Restoring to / failed.
at org.wso2.carbon.registry.app.RemoteRegistry.restore(RemoteRegistry.java:1725)
at org.wso2.carbon.registry.app.RemoteRegistry.restore(RemoteRegistry.java:1665)
at org.wso2.carbon.registry.synchronization.operation.CheckInCommand.restoreFromFile(CheckInCommand.java:198)
... 11 more
WSO2 Governance Registry does not support check-out , check-in from top level collection paths.[1] (i.e. /_system/governance/ and /_system/config/)
Instead we recommend that you check-out check-in from child collection paths.
There seems to be an issue with dumping remote registry path collections on Greg 4.6.0. [2]
You can also find the fix attached to [2]
[1] https://docs.wso2.com/display/Governance460/Check-in+Client+Examples
[2] https://wso2.org/jira/browse/REGISTRY-2044