I am using the docker image version of Fiware Orion. When I try to delete entities using a service path ending # I received a 204 but the entity is not erased.
I tried with the next service paths for a \test\testa entity:
/#
/test/#
/test/testa/#
Hierarchical search (using # suffix) or multipath search (using several service path separated by comma) is only allowed in query requests. For update requests only single and not hierarchical service paths are allowed.
Delete entity is a kind of update request, so you cannot use the # suffix.
Related
When MicroProfile LRA coordinator and participants run on different Docker containers, it is needed to define a custom URI for each participant.
Otherwise the LRA coordinator tries to call participant compensate/complete APIs by referring them with "localhost" based URI.
Is it possible, on WildFly environment, to define a custom URI for a participant?
And ingeneral is it possible to define a how participants can register with any LRA?
By default, the participant endpoints are derived from the caller information provided in the JAX-RS UriInfo class. This class contains the base URI of the caller of the participant. The idea is that coordinator should be able to call the participant on the same URI as the original request to the participant came in.
I've created a simple docker image https://hub.docker.com/repository/docker/xstefank/uriinfo-wildfly which will on path /uriinfo/ping return the the base URI that will be used for participant URLs.
Calling this locally gives you - Base URI is http://localhost:8080/uriinfo/ which is expected called from the local machine. Deploying this image to OpenShift/Kubernetes and exposing a route for this application gives you Base URI is http://uriinfo-wildfly-testing.6923.rh-us-east-1.openshiftapps.com/uriinfo/. And finally, calling it from a different pod deployed in the same project gives you Base URI is http://uriinfo-wildfly:8080/uriinfo/ which corresponds to the actual calls:
$ curl localhost:8080/uriinfo/ping
Base URI is http://localhost:8080/uriinfo/
$ curl http://uriinfo-wildfly-testing.6923.rh-us-east-1.openshiftapps.com/uriinfo/ping
Base URI is http://uriinfo-wildfly-testing.6923.rh-us-east-1.openshiftapps.com/uriinfo/
# called from different pod in the same openshift project
$ curl http://uriinfo-wildfly:8080/uriinfo/ping
Base URI is http://uriinfo-wildfly:8080/uriinfo/
Another option is to manually register the URLs you require through NarayanaLRAClient#joinLRA methods which either take individual URLs for different LRA endpoints or a base URI that will derive the URLs as mentioned above.
I'm experiencing some strange behaviour with a ColdFusion 11 server, which (among other things) publishes some web services accessed via both SOAP and HTTP. The server itself is Windows 2012, running IIS. Actual folder config is as follows:
IIS has two websites configured, 'BOB' and 'BOB_Services'. Both have been configured with the CF Server Config tool so that CF handles .cfc, .cfm files. They share a common CFIDE config.
BOB's root is I:/inetpub/BOB
BOB_Services's root is I:/inetpub/BOB_Services
There is a folder mapping configured in CF Admin from '/' to 'I:/inetpub/BOB'. Don't ask me why, no one seems to know.
Normally there is a services.cfc file in BOB_Services ONLY. Yesterday we accidentally copied that same file into the BOB root folder, and all of our SOAP services using BOB_Services\services.cfc started throwing errors. Yet I can query the same webservice via HTTP (eg. using http://bob/services.cfc?method=function1¶m1=0 ....etc) and get a valid result.
This is a reference answer in case anyone else comes across this strange behaviour.
It appears that when BOB_Services/services.cfc is called using HTTP GET, the folder mapping
'/' -> 'I:/inetpub/BOB'
is ignored and the actual file used to process the request is I:/inetpub/BOB_Services/services.cfc.
When a function in BOB_Services/services.cfc is called using a SOAP client, the folder mapping is invoked and the file used to process the request is I:/inetpub/BOB/services.cfc, IF IT EXISTS. If it does not exist, the file I:/inetpub/BOB_Services/services.cfc is used as expected.
This behaviour appears to be entirely repeatable - I can make a SOAP request, get one result, change the mapping, make another request and get the other result.
We have the following website structure:
content
mysite
en
home
testlevel1page
testlevel2page
Now the requirement is to map:
http://www.mysite.com/ --> /content/mysite/en/home.html
http://www.mysite.com/testlevel1page/ --> /content/mysite/en/home/testlevel1page.html
http://www.mysite.com/testlevel1page/testlevel2page/ --> /content/mysite/en/home/testlevel1page/testlevel2page.html
How can we achieve this through resource resolver?
Under the /etc/map/http directory, add a node "www.mysite.com" and give this a sling:internalRedirect property of /content/mysite/en/home.
As per the Sling documentation, this will "prefix the URI paths of the requests sent to this domain with the string" — i.e. in this case, appending "/content/my/en/home" after the domain name for any incoming requests to "www.mysite.com".
Optionally, if you place this under /etc/map.publish/http, this will only be applied to instances with a Sling run mode set to publish.
(As the rule is under a node called 'http', this won't be applied to secure requests. If you need to cater for 'https' too, you could copy the http node, or preferrably create a regex — this isn't as common a use case, but more info on the docs linked above.)
In order to portion off my part of the Google Cloud Storage namespace, I've verified my domain, paul.kishimoto.name, as described here. However, I am still unable to create buckets containing that name. Using the gsutil command-line tool, I am given an error message:
$ gsutil mb -p khaeru-private gs://paul.kishimoto.name-documents
Creating gs://paul.kishimoto.name-documents/...
GSResponseError: status=400, code=DotfulBucketNameNotUnderTld, reason=Bad Request.
A search for the error code DotfulBucketNameNotUnderTld turns up this discussion from the old support group, in which a Google employee said a list from publicsuffix.org was used to check for valid TLDs. The list does not appear to contain the .name TLD.
After verifying that you own the domain paul.kishimoto.name you can create buckets with that name or subdomains of that name, such as paul.kishimoto.name, docs.paul.kishimoto.name, images.paul.kishimoto.name, etc. You can't create a bucket named paul.kishimoto.name-documents because .name-documents is not a currently valid TLD.
Mike Schwartz, Google Cloud Storage team
I'm performing REST API operation Start Role (http://msdn.microsoft.com/en-us/library/jj157189.aspx)
In the link https://management.core.windows.net/{subscription-id}/services/hostedservices/{service-name}/deployments/{deployment-name}/roles/{role-name}/Operations we have replaced {service-name}, {deployment-name} and {role-name} with name of VM.
In result we have next message:
"ResourceNotFoundThe resource service name hostedservices is not supported."
List Hosted Services operation (http://msdn.microsoft.com/en-us/library/windowsazure/ee460781.aspx) shows us that we have 2 WMs as hosted services.
Get Role operaion (http://msdn.microsoft.com/en-us/library/jj157193.aspx) also gives info about each of VMs.
Thanks in advance.
You are using:
{subscription-id}/services/hostedservices/{service-name}/deployments/{deployment-name}/roles/{role-name}/Operations
But the correct Uri is:
{subscriptionID}/services/hostedservices/{serviceName}/deployments/{deploymentName}/roleInstances/{roleInstanceName}/Operations
See the difference?
I haven't worked with this particular operation, however a few things:
service-name: It should be the name of the hosted service (the one with .cloudapp.net) and what you see when you list your hosted service.
deployment-name: Generally speaking it's a GUID returned by Get Deployment operation (http://msdn.microsoft.com/en-us/library/windowsazure/ee460804.aspx).
role-name: Role name is also returned when you do a Get Deployment operation. You should use that. I'm not sure if it is same as the name of your VM.
Can you retry your operation after changing these values?
In my case, deployment name is the name of the first VM I created in this cloud service. So, if I added 3 machines to the same cloud service, all of them have the same deployment name - the name of the first machine.