I have an illegal repository name, which starts with a number.
It's an old repo, created with API request (in Artifactory 6.5.1 version)
Artifactory accepts illegal name with API requests but if you restart artifactory, it's down
So my problem is the same like here:
https://www.jfrog.com/jira/browse/RTFACT-16669
Except the solution doesn't work for me.
Because my instance/server is new, so i have not this file $ARTIFACTORY_HOME/etc/artifactory.config.latest.xml with the local repository.
I have repositories on AWS S3 and a AWS RDS database
And my new AWS EC2 instance have to get repos on S3
My question is:
Can i start artifactory ignoring the bad repo ?
Or
Can i delete the repo without starting artifactory ? (without API request or GUI)
The logs are here:
2019-05-13 14:37:11,581 [art-init] [ERROR] (o.a.c.CentralConfigServiceImpl:744) - Could not load configuration due to: Failed to read object from stream
java.lang.RuntimeException: Failed to read object from stream
at org.artifactory.jaxb.JaxbHelper.read(JaxbHelper.java:131)
at org.artifactory.jaxb.JaxbHelper.readConfig(JaxbHelper.java:66)
at org.artifactory.descriptor.reader.CentralConfigReader.readAndConvert(CentralConfigReader.java:76)
etc ...
Caused by: javax.xml.bind.UnmarshalException: null
at javax.xml.bind.helpers.AbstractUnmarshallerImpl.createUnmarshalException(AbstractUnmarshallerImpl.java:335)
at com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl.createUnmarshalException(UnmarshallerImpl.java:578)
at com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl.unmarshal0(UnmarshallerImpl.java:264)
at com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl.unmarshal(UnmarshallerImpl.java:229)
at javax.xml.bind.helpers.AbstractUnmarshallerImpl.unmarshal(AbstractUnmarshallerImpl.java:157)
at javax.xml.bind.helpers.AbstractUnmarshallerImpl.unmarshal(AbstractUnmarshallerImpl.java:125)
at org.artifactory.jaxb.JaxbHelper.read(JaxbHelper.java:129)
... 56 common frames omitted
Caused by: org.xml.sax.SAXParseException: cvc-datatype-valid.1.2.1: '0ta' is not a valid value for 'NCName'.
etc ...
[art-init] [ERROR] (o.a.w.s.ArtifactoryContextConfigListener:96) - Application could not be initialized: null
java.lang.reflect.InvocationTargetException: null
etc ...
Caused by: org.springframework.beans.factory.BeanInitializationException: Failed to initialize bean 'org.artifactory.security.access.AccessService'.; nested exception is com.google.common.util.concurrent.UncheckedExecutionException: java.lang.NullPointerException
etc ...
[http-nio-8081-exec-2] [ERROR] (o.a.w.s.ArtifactoryFilter:194) - Artifactory failed to initialize: Context is null
Thanks
Cyril
The Artifactory config descriptor is stored in the Artifactory DB schema under a table named configs.
In order to overcome this, you can do the following:
Extract the artifactory.config.xml config from the configs table
Store the extracted configuration as a file in: $ARTIFACTORY_HOME/etc/artifactory.config.import.xml
Edit the artifactory.config.import.xml file and manually fix/delete the '0ta' repository reference from the configuration file
After modifying the descriptor, restart the Artifactory service.
Note, if you already have artifacts assigned to the illegal repo name, you will not be able to see them after modifying the repository name, however, since it is a new installation, I'm not sure that that this is relevant for you.
Related
I am facing an odd situation where the initial npm publication went fine. But when moving/promoting the artifact to another local npm repository, which does not contain an artifact yet for this artifact; artifactory succesfully moves the artifact. But fails with creating the corresponding package.json.
In the artifactory-service.log we see the following message:
2023-01-12T09:11:52.521Z [jfrt ] [INFO ] [c8198335dc788640] [.NpmPackageMetadataIndexer:402] [art-exec-24 ] - Preparing to write npm package metadata for repo 'npm_releases' on path '.npm/#<group>/<artifactid>/package.json' 2023-01-12T09:11:52.540Z [jfrt ] [ERROR] [494934d19384b919] [j.r.n.PackageMetadataStream:68] [art-fixed-$s ] - Failed write java.lang.RuntimeException: Failed precondition. List argument metadata must not be empty at org.jfrog.repomd.npm.util.NpmUtils.updateAndGetLatest(NpmUtils.java:107) at org.jfrog.repomd.npm.util.NpmUtils.updateAndGetLatest(NpmUtils.java:100) at org.jfrog.repomd.npm.PackageMetadataStream.calculateLatest(PackageMetadataStream.java:128) at org.jfrog.repomd.npm.PackageMetadataStream.buildGroupMetadata(PackageMetadataStream.java:99) at org.jfrog.repomd.npm.PackageMetadataStream.writeInternal(PackageMetadataStream.java:77) at org.jfrog.repomd.npm.PackageMetadataStream.write(PackageMetadataStream.java:66) at org.iostreams.streams.in.OutputToInputStream$1.call(OutputToInputStream.java:140) at org.iostreams.streams.in.OutputToInputStream$1.call(OutputToInputStream.java:136) at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) at org.artifactory.opentracing.TraceableRunnableDecorator.run(TraceableRunnableDecorator.java:40) at org.artifactory.concurrent.ArtifactoryRunnable.run(ArtifactoryRunnable.java:53) at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) at java.base/java.lang.Thread.run(Thread.java:829) 2023-01-12T09:11:52.565Z [jfrt ] [INFO ] [c8198335dc788640] [.NpmPackageMetadataIndexer:412] [art-exec-24 ] - Finished writing npm package metadata for repo 'npm_releases' on path '.npm/#<group>/<artifactid>/package.json
I do not see how this relates to the uploaded artifact. As the generation of the package.json for the initial publication went fine. Next to this stacktrace I could not find anything in the log which relates to this.
I am able to reproduce this problem with artifactory version: 7.46.11 and 7.49.5
Could someone help explaining in what Failed precondition. List argument metadata must not be empty at means? And how to mitigate this situation?
I tried moving this artifact to other local npm repositories with same result. For unclear reasons in a populated repository as in a local npm repository(lets say the original repository which worked) which contains 3 artifacts with a different version number, but same group and artifactid a valid package.json was generated. This should work for this single artifact as well, but it doesn't.
I have upgraded a few test instances of our Artifactory 6.0.2 Installation to version 6.9.1 using the provided instructions found at:
https://www.jfrog.com/confluence/display/RTF/Upgrading+Artifactory
I have tried both the yum upgrade and rpm installation pathways, and would like to end the installation with no error messages in the log files to minimize any potential issues from such errors.
After installation and many manual remediation steps I have reached an error "Unable to request the Metadata Service Service-Id" that I cannot find Google results for:
2019-04-09 16:22:13,409 [art-init] [ERROR] (o.a.m.s.s.ArtifactoryMetadataClientConfigStore:111) - Unable to request the Metadata Service Service-Id
2019-04-09 16:22:13,409 [art-init] [ERROR] (o.a.m.s.MetadataEventServiceImpl:188) - Unable to init the Metadata client. The Metadata Event pipeline will be disabled.
I have tried both the yum upgrade and rpm installation pathways.
After the upgrades, I noticed errors in the Catalina and Artifactory log files and followed the google search results regarding those error messages (added below my question for posterity):
(1) Created:
/var/opt/jfrog/artifactory/access/etc/bootstrap.creds
Containing:
access-admin#127.0.0.1=NEW_PASSWORD
(2) Removed access folder:
rm -rf /opt/jfrog/artifactory/tomcat/webapps/access
(3) Changed permissions of Artifactory directories:
cd /var/opt/jfrog/artifactory/
chown -R artifactory:artifactory .
(4) EDITED the artifactory.system.properties file adding:
artifactory.pathChecksum.migration.job.enabled=true
(5) Enabled sha 256 migration by adding this content to this same file:
##SHA2 Migration block
artifactory.sha2.migration.job.enabled=true
artifactory.sha2.migration.job.queue.workers=5
(5) Finally, Rebooted instance.
Yet the errors including The Metadata Event pipeline will be disabled persist.
I expect that the final state of the Artifactory server will be such that there are no error messages in the Artifactory nor Catalina log files.
Any assistance on remediating this error so that i can deploy the latest Artifactory build will be highly appreciated.
Thank you in advance.
======================
Here are some of the ERROR LOGS WHICH INITIATED CHANGES SHOWN ABOVE:
(1) 2019-03-27 05:03:22,872 [art-init] [WARN ] (o.j.a.c.AccessClientHttpException:41) - Unrecognized ErrorsModel by Access. Original message: Failed on executing /api/v1/system/ping, with response: Not Found
2019-03-27 05:03:22,872 [art-init] [ERROR] (o.a.s.a.AccessServiceImpl:364) - Could not ping access server: {}
org.jfrog.access.client.AccessClientHttpException: HTTP response status 404:Failed on executing /api/v1/system/ping, with response: Not Found.
(2)2019-03-27 05:06:53,235 [art-exec-3] [INFO ]
(o.a.s.j.m.s.Sha256MigrationJobDelegate:216) - SHA256 migration job (for existing artifacts) is disabled and will not run, there are 52496 artifacts without SHA256 values in the database. Future versions of Artifactory may enforce this migration as a prerequisite for upgrades.
(3) 2019-04-04 16:20:10,951 [localhost-startStop-1] [JFrog-Access] [WARN ] (o.s.b.c.e.AnnotationConfigEmbeddedWebApplicationContext:550) - Exception encountered during context initialization - cancelling refresh attempt: org.springframework.context.ApplicationContextException: Unable to start embedded container; nested exception is org.springframework.beans.factory.UnsatisfiedDependencyException: Error creating bean with name 'org.springframework.boot.autoconfigure.jersey.JerseyAutoConfiguration': Unsatisfied dependency expressed through constructor parameter 1; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'jerseyConfig' defined in URL [jar:file:/opt/jfrog/artifactory/tomcat/webapps/access/WEB-INF/lib/access-application-4.2.0.jar!/org/jfrog/access/rest/config/JerseyConfig.class]: Bean instantiation via constructor failed; nested exception is org.springframework.beans.BeanInstantiationException: Failed to instantiate [org.jfrog.access.rest.config.JerseyConfig]: Constructor threw exception; nested exception is org.springframework.beans.factory.UnsatisfiedDependencyException: Error creating bean with name 'systemResource' defined in URL [jar:file:/opt/jfrog/artifactory/tomcat/webapps/access/WEB-INF/lib/access-server-rest-4.2.0.jar!/org/jfrog/access/server/rest/resource/system/SystemResource.class]: Unsatisfied dependency expressed through constructor parameter 0; nested exception is org.springframework.beans.factory.UnsatisfiedDependencyException: Error creating bean with name 'backupSubResource' defined in URL [jar:file:/opt/jfrog/artifactory/tomcat/webapps/access/WEB-INF/lib/access-server-rest-4.2.0.jar!/org/jfrog/access/server/rest/resource/system/backup/BackupSubResource.class]: Unsatisfied dependency expressed through constructor parameter 0; nested exception is org.springframework.beans.factory.UnsatisfiedDependencyException: Error creating bean with name 'backupServiceImpl': Unsatisfied dependency expressed through field 'importerExporter'; nested exception is org.springframework.beans.factory.UnsatisfiedDependencyException: Error creating bean with name 'accessImporterExporterImpl': Unsatisfied dependency expressed through method 'setServerBootstrap' parameter 0; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'accessServerBootstrapImpl': Invocation of init method failed; nested exception is java.lang.IllegalStateException: Failed to bootstrap initial access credentials.
Thank you for the feedback #error404.
We ended up opening a ticket with Jfrog support (https://www.jfrog.com/jira/browse/RTFACT-18939) who was able to replicate the issue and subsequently marked the ticket as "Fix Version/s: 6.10.0"
Although not strictly stated, I assume this Fix Version update implies that the described issue will be remediated in the next release.
we are using Artifactory server and I encountered a problem today.
I tried deleting a distribution repo but I was unable.
I got an error message:
Deleting repo 'BASELINES-BINTRAY' failed: Could not merge and save new descriptor [org.jfrog.common.ExecutionFailed: Last retry failed: code exception. Not trying again (Failed to reload configuration:
org.artifactory.descriptor.repo.distribution.rule.DistributionRule cannot be cast
to org.artifactory.descriptor.repo.RepoDescriptor)]
I looked at the logs of Artifactory and this is what I saw:
2018-02-13 22:25:16,525 [http-nio-8080-exec-2637] [ERROR] (o.a.u.r.s.a.c.r.DeleteRepositoryConfigService:66) - Deleting repo 'BASELINES-BINTRAY' failed: Could not merge and save new descriptor
[org.jfrog.common.ExecutionFailed: Last retry failed: code exception. Not trying again (Failed to reload configuration:
org.artifactory.descriptor.repo.distribution.rule.DistributionRule cannot be cast to org.artifactory.descriptor.repo.RepoDescriptor)]
java.lang.IllegalStateException: Could not merge and save new descriptor [org.jfrog.common.ExecutionFailed: Last retry failed: code exception. Not trying again (Failed to reload configuration:
org.artifactory.descriptor.repo.distribution.rule.DistributionRule cannot be cast to org.artifactory.descriptor.repo.RepoDescriptor)]
any ideas what it means ?
On windows I have installed Artifactory 4.11.0 and jenkins 1.643.
Both are running separately fine. I have also installed artifactory plugin 2.10.4 and tried to configure by providing default credentials and when used test connection check it is throwing the following error.
What can I do. Do I have to configure something special in Artifactory ?
Please see the following error
Stack trace
javax.servlet.ServletException: java.lang.LinkageError: loader constraint violation: when resolving method
"org.apache.http.impl.client.HttpClientBuilder.setDefaultCredentialsProvider
(Lorg/apache/http/client/CredentialsProvider;)Lorg/apache/http/impl/client/HttpClientBuilder;"
the class loader (instance of hudson/ClassicPluginStrategy$AntClassLoader2) of the current class,
org/jfrog/build/client/PreemptiveHttpClient, and the class loader
(instance of hudson/ClassicPluginStrategy$AntClassLoader2) for resolved class,
org/apache/http/impl/client/HttpClientBuilder, have different Class objects for the type
he.http.impl.client.HttpClientBuilder.setDefaultCredentialsProvider
(Lorg/apache/http/client/CredentialsProvider;)Lorg/apache/http/impl/client/HttpClientBuilder;
used in the signature
at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:796)
at org.kohsuke.stapler.Stapler.invoke(Stapler.java:876)
at org.kohsuke.stapler.MetaClass$6.doDispatch(MetaClass.java:249)
at org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:53)
at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:746)
at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:240)
at org.eclipse.jetty.server.AsyncHttpConnection.handle(AsyncHttpConnection.java:82)
at org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:668)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.kohsuke.stapler.Function$InstanceFunction.invoke(Function.java:298)
at org.kohsuke.stapler.Function.bindAndInvoke(Function.java:161)
at org.kohsuke.stapler.Function.bindAndInvokeAndServeResponse(Function.java:96)
at org.kohsuke.stapler.MetaClass$1.doDispatch(MetaClass.java:121)
at org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:53)
at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:746)
... 59 more
We are doing the alfresco 5.1 installation in multiple servers in clone env.Except in one server ,we are seeing below error other 3 servers.To resolve this error we have done below steps but no luck.please note that below path was there in all servers.
1)Stop all shared servers
2)Drop database schema and create new schema.
3)Delete contents(contentstore & contentstore.deleted) inside /var/lib/alfresco/alf_data_dev
4)Start all shared servers.
07-28 07:01:30,864 ERROR [repo.admin.ConfigurationChecker] [localhost-startStop-1] CONTENT INTEGRITY ERROR: System content not found in content store.
2016-07-28 07:01:30,864 ERROR [repo.admin.ConfigurationChecker] [localhost-startStop-1] Ensure that the 'dir.root' property '/var/lib/alfresco/alf_data_dev_new' is pointing to the correct data location.
2016-07-28 07:01:30,867 ERROR [web.context.ContextLoader] [localhost-startStop-1] Context initialization failed
org.alfresco.error.AlfrescoRuntimeException: 06280002 Ensure that the 'dir.root' property '/var/lib/alfresco/alf_data_dev' is pointing to the correct data location.
at org.alfresco.repo.admin.ConfigurationChecker.check(ConfigurationChecker.java:263)
at org.alfresco.repo.admin.ConfigurationChecker.access$0(ConfigurationChecker.java:198)
at org.alfresco.repo.admin.ConfigurationChecker$1$1.doWork(ConfigurationChecker.java:186)
at org.alfresco.repo.security.authentication.AuthenticationUtil.runAs(AuthenticationUtil.java:555)
at org.alfresco.repo.admin.ConfigurationChecker$1.execute(ConfigurationChecker.java:182)
at org.alfresco.repo.transaction.RetryingTransactionHelper.doInTransaction(RetryingTransactionHelper.java:464)
at org.alfresco.repo.transaction.RetryingTransactionHelper.doInTransaction(RetryingTransactionHelper.java:352)