v4 provides an API: ST.add(String, Object). I couldn't find the v3 API setAttributes(Object) in v4.
I used ST.add("root", JSONObject). An exception occures:
java.lang.IllegalArgumentException: no such attribute: root
at org.stringtemplate.v4.ST.add(ST.java:223)
at jjs.stst.STStandaloneTool.invokeTemplate(STStandaloneTool.java:479)
at jjs.stst.STStandaloneTool.generate(STStandaloneTool.java:420)
at jjs.stst.STStandaloneTool.main(STStandaloneTool.java:722)
I had the same problem. This error occures when template is not anonymouse and doesn't expect any formal arguments. You could add this arguments yourself but its not comfortable.
Problem can be bypassed by setting ST.impl.HasFormalArgs to false and using ST.add
Related
While working with HERE-SDK for flutter, HerePositioningClient fails to initialize with the error:
onInitializationFailed. API token that failed: com.here.services.location.LocationServices$1#2bdef2b
Additionally, the ActivityThread throws this error:
E/ActivityThread(12002): Service com.here.services.internal.LocationService has leaked IntentReceiver com.here.odnp.util.AlarmTimer$Scheduler#163882d that was originally registered here. Are you missing a call to unregisterReceiver()?
E/ActivityThread(12002): android.app.IntentReceiverLeaked: Service com.here.services.internal.LocationService has leaked IntentReceiver com.here.odnp.util.AlarmTimer$Scheduler#163882d that was originally registered here. Are you missing a call to unregisterReceiver()?
Update:
Fixed this issue by adding all the possible permissions required as in the example files provided. Just adding Location and Activity permission was not enough.
I have a script created to automate the process of generating Let's Encrypt certificates for my websites.
The Script always worked fine, but starting yesterday I am receiving the issue below when I try to run:
New-ACMERegistration -Contacts mailto:user#email.com -AcceptTos
Error:
System.UriFormatException: Invalid URI: The URI scheme is not valid.
at System.Uri.CreateThis(String uri, Boolean dontEscape, UriKind uriKind)
at ACMESharp.AcmeClient.GetDirectory(Boolean saveRelative) in
C:\projects\acmesharp\ACMESharp\ACMESharp\AcmeClient.cs:line 145
at ACMESharp.POSH.NewRegistration.ProcessRecord() in
C:\projects\acmesharp\ACMESharp\ACMESharp.POSH\NewRegistration.cs:line 63
at System.Management.Automation.CommandProcessor.ProcessRecord()
I have the latest version of th PowerShell module installed (https://www.powershellgallery.com/packages/ACMESharp/0.9.1.326).
Has anybody stumbled on a similar issue?
An error is thrown because the BaseUri: https://acme-v01.api.letsencrypt.org/directory returns a JSON Error. ACME Protocol Version 1 has been deprecated. You will need to use a client that uses ACME Protocol Version 2.
Consider replacing ACMESharp with ACME-PS.
I am trying to add CORS support to my Jenkins server so I could access the REST API from the browser. From looking around, the recommended approach is to use the CORS Filter plugin.
I have installed it, enable it, and add http://localhost to the Access-Control-Allow-Origins field, as well as GET to Access-Control-Allow-Methods field. However, these headers are not showing up in my requests.
This plugin has not been updated in a few years, so I'm not sure if it's compatible with the latest version of Jenkins. I'm running version 2.172.
In the Jenkins system log, I see these errors, not sure if it's related/ relevant
Caught exception evaluating: descriptor.getPropertyType(instance,field).itemTypeDescriptorOrDie in /configure. Reason: java.lang.reflect.InvocationTargetException
java.lang.AssertionError: class hudson.ivy.IvyBuildTrigger$IvyConfiguration is missing its descriptor in public hudson.ivy.IvyBuildTrigger$IvyConfiguration[] hudson.ivy.IvyBuildTrigger$DescriptorImpl.getConfigurations(). See https://jenkins.io/redirect/developer/class-is-missing-descriptor
Caught exception evaluating: h.filterDescriptors(it,attrs.descriptors) in /configure. Reason: java.lang.NullPointerException: Descriptor list is null for context 'class hudson.model.Hudson' in thread 'Handling GET /configure from 100.71.26.18 : qtp589873731-14 Jenkins/configure.jelly GlobalLibraries/config.jelly LibraryConfiguration/config.jelly SCMRetriever/DescriptorImpl/config.jelly MultiSCM/DescriptorImpl/config.jelly'
java.lang.NullPointerException: Descriptor list is null for context 'class hudson.model.Hudson' in thread 'Handling GET /configure from 100.71.26.18 : qtp589873731-14 Jenkins/configure.jelly GlobalLibraries/config.jelly LibraryConfiguration/config.jelly SCMRetriever/DescriptorImpl/config.jelly MultiSCM/DescriptorImpl/config.jelly'
These errors have at org.jenkinsci.plugins.corsfilter.AccessControlsFilter.doFilter(AccessControlsFilter.java:79) in their stack trace.
Does anyone know of a good way to enable CORS support for Jenkins REST API?
Jenkins version 2.303 and I struggle with the same issue. I would recommend to add the port number on the localhost URI you defined in the plugin settings, even though I'm pretty sure that won't change anything.
It actually seems the plugin is having no effect at all.
Probably the best solution is to set up your own proxy which would take care of CORS. Here is a good and well document example Build a Node.js Proxy Server in Under 10 minutes!
We are using some community custom resource types (https://github.com/ljfranklin/terraform-resource and https://github.com/cloudfoundry/bosh-deployment-resource). After upgrading to concourse 3.3.0, we've begun consistently seeing the following error on a few of our jobs at the same step: json: unsupported type: map[interface {}]interface {}.
This is fairly hard to debug as there is no other log output other than that. We are unsure what is incompatible between those resources and Concourse.
Notes about our pipeline:
We originally had substituted all of our usages of {{}} to (()), but reverting that did not lead to the error going away.
We upgraded concourse from v3.0.1.
The failing step can be found here: https://github.com/cloudfoundry/capi-ci/blob/6a73764d09f544820ce39f16dca166d6d6861996/ci/pipeline.yml#L731-L739
We are using a resource called elsa-aws-storage-terraform, found here: https://github.com/cloudfoundry/capi-ci/blob/6a73764d09f544820ce39f16dca166d6d6861996/ci/pipeline.yml#L731-L739
That resource is of a custom resource-type terraform found here: https://github.com/cloudfoundry/capi-ci/blob/6a73764d09f544820ce39f16dca166d6d6861996/ci/pipeline.yml#L45-L48
A similar failing step can be found here: https://github.com/cloudfoundry/capi-ci/blob/6a73764d09f544820ce39f16dca166d6d6861996/ci/pipeline.yml#L871-L886
This is related to issue of not being able to define nested maps in resource configuration https://github.com/concourse/concourse/issues/1345
Our application provides a SOAP API. Our wsdl starting lines are something like
<wsdl:definitions name='ControlDServices' ... xmlns:soap='http://schemas.xmlsoap.org/wsdl/soap/' ...
This usually works OK, but a customer complained that when they try to use our SOAP API in NetBeans with the wsdl we provide they got this error:
Web Service can not be created by JAXWS:wsimport utility.
Reason: invalid extension element: "soap:body" (in namespace "http://schemas.xmlsoap.org/wsdl/soap/")
This can be easily recreated by running:
wsimport -d . -extension -Xnocompile -keep -s . -verbose <our wsdl file>
wihch yield the error:
[ERROR] invalid extension element: "soap:body" (in namespace "http://schemas.xmlsoap.org/wsdl/soap/")
unknown location
Our support discovered that changing the xmlns:soap definition to use http://www.w3.org/2001/12/soap-envelope/ solves the problem, but this requires a change in our product, and also contradict most of the places I see on the web where a wsdl:definitions file is defined. Besides, that URI seems to belong to soap-envelop and not to wsdl, and is also for a specific date, and not a general URI.
Is there a way to solve the NetBeans / wsimport problem without changing our wsdl, e.g. by changing parameters? If no, and a change is needed, is it wise to change it to http://www.w3.org/2001/12/soap-envelope/, or should we use something else?
Thanks
splintor
It looks like they don't support SOAP 1.1, only SOAP 1.2.