I am using SDR 2.4.1
When I exec
http -v --auth admin:admin --json PATCH http://localhost:8080/api/messages/61?projection=withAccount readTimestamp="2015-12-15T11:32:06.380+0000"
I get the following exception:
java.lang.IllegalArgumentException: Target bean is not of type of the persistent entity!
at org.springframework.util.Assert.isTrue(Assert.java:68) ~[spring-core-4.2.3.RELEASE.jar:4.2.3.RELEASE]
at org.springframework.data.mapping.model.BasicPersistentEntity.getPropertyAccessor(BasicPersistentEntity.java:394) ~[spring-data-commons-1.11.1.RELEASE.jar:na]
at org.springframework.data.rest.webmvc.support.ETag.getVersionInformation(ETag.java:191) ~[spring-data-rest-webmvc-2.4.1.RELEASE.jar:na]
at org.springframework.data.rest.webmvc.support.ETag.from(ETag.java:76) ~[spring-data-rest-webmvc-2.4.1.RELEASE.jar:na]
at org.springframework.data.rest.webmvc.AbstractRepositoryRestController.prepareHeaders(AbstractRepositoryRestController.java:171) ~[spring-data-rest-webmvc-2.4.1.RELEASE.jar:na]
at org.springframework.data.rest.webmvc.AbstractRepositoryRestController.prepareHeaders(AbstractRepositoryRestController.java:157) ~[spring-data-rest-webmvc-2.4.1.RELEASE.jar:na]
at org.springframework.data.rest.webmvc.RepositoryEntityController.saveAndReturn(RepositoryEntityController.java:495) ~[spring-data-rest-webmvc-2.4.1.RELEASE.jar:na]
at org.springframework.data.rest.webmvc.RepositoryEntityController.patchItemResource(RepositoryEntityController.java:442) ~[spring-data-rest-webmvc-2.4.1.RELEASE.jar:na]
But when I exec:
http -v --auth admin:admin --json PATCH http://localhost:8080/api/messages/61?foo=bar readTimestamp="2015-12-15T11:32:06.380+0000"
everything is fine.
So it seem to be the projection parameter which causes the exception.
Is this a bug?
THank you
I do not think it is a bug - projections are not meant to be used in write request - they are just a way to provide different views on your data. When creating of updating a resource you are tied to your entity structure in spring data rest. The only way I know to customize it is to use Jackson Mixins.
Hm, I think the patch request should simply ignore the projection param as it ignores the foo paarm too... Not? ;)
Related
I have set up kong in dbless mode on RHEL by following the below documentation
https://docs.konghq.com/gateway/latest/install-and-run/rhel/
Kong gateway is successfully started. Below are the configurations I added in kong.conf file where database is turned to off and path to declarative kong.yaml is specified
declarative_config = /temp/kong/kong.yml
database = off
Also, below is current .yaml file where I created a service using below link
https://docs.konghq.com/gateway/2.8.x/get-started/comprehensive/expose-services/
_format_version: "1.1"
services:
- host: mockbin.org
name: example_service
port: 80
protocol: http
routes:
- name: mocking
paths:
- /mock
strip_path: true
I have also installed deck to sync this the declarative configuration.
However, when I use the deck sync command to add this service to kong, I get below error
creating service example_service
Summary:
Created: 0
Updated: 0
Deleted: 0
Error: 1 errors occurred:
while processing event: {Create} service example_service failed: HTTP status 405 (message: "cannot create or update 'services' entities when not using a database")
Kindly need ideas on what could be wrong as I believe we can create a service in dbless mode, and I also think that this is the declarative format which should work. Looking forward to hear. Thanks
Kindly need ideas on what could be wrong as I believe we can create a service in dbless mode, and I also think that this is the declarative format which should work. Looking forward to hear. Thanks
You are correct that we can create a service in dbless mode, however the approach will be different.
If you already have the new config file in yaml format. you can load it to Kong using /config endpoint
I also think that decK should be process-agnostic and can be used with both db and dbless mode, But as it stands, loading yaml config file with /config endpoint looks like the best option.
How can I completely disable the cache in Symfony 5.2?
I use PHP config file (services.php) and not the yaml ones.
In the docs, I cannot find anything matching.
Try configuring the two pools that are always enabled by default to use the Symfony\Component\Cache\Adapter\NullAdapter
framework:
cache:
app: cache.adapter.null
system: cache.adapter.null
services:
cache.adapter.null:
class: Symfony\Component\Cache\Adapter\NullAdapter
arguments: [~] # small trick to avoid arguments errors on compile-time.
https://symfony.com/doc/current/cache.html#configuring-cache-with-frameworkbundle
https://stackoverflow.com/a/46898727/6127393
So I am running the sample code provided by Google:
package com.neat.backend;
/**
* An endpoint class we are exposing
*/
#Api(
name = "myApi",
version = "v1",
namespace = #ApiNamespace(
ownerDomain = "backend.neat.com",
ownerName = "backend.neat.com",
packagePath = ""
),
issuers = {
#ApiIssuer(
name = "firebase",
issuer = "https://securetoken.google.com/" + PROJECT_ID,
jwksUri = "https://www.googleapis.com/robot/v1/metadata/x509/securetoken#system.gserviceaccount.com")
})
public class MyEndpoint {
#ApiMethod(
path = "firebase_user",
httpMethod = ApiMethod.HttpMethod.GET,
authenticators = {EspAuthenticator.class},
issuerAudiences = {#ApiIssuerAudience(name = "firebase", audiences = {PROJECT_ID})}
)
public Email getUserEmailFirebase(User user) throws UnauthorizedException {
if (user == null) {
throw new UnauthorizedException("Invalid credentials");
}
Email response = new Email(user.getEmail());
return response;
}
}
I am getting a Firebase token from my Android client and try to send it to the backend by:
curl -H "Authorization: Bearer FIREBASE_JWT_TOKEN" \
-X GET \
http://localhost:8080/_ah/api/echo/v1/firebase_user
The error I see in the logs is the following:
[INFO] java.lang.IllegalStateException: method_info is not set in the request
[INFO] at com.google.api.server.spi.auth.EspAuthenticator.authenticate(EspAuthenticator.java:67)
[INFO] at com.google.api.server.spi.request.Auth.authenticate(Auth.java:100)
[INFO] at com.google.api.server.spi.request.ServletRequestParamReader.getUser(ServletRequestParamReader.java:191)
[INFO] at com.google.api.server.spi.request.ServletRequestParamReader.deserializeParams(ServletRequestParamReader.java:136)
[INFO] at com.google.api.server.spi.request.RestServletRequestParamReader.read(RestServletRequestParamReader.java:123)
[INFO] at com.google.api.server.spi.SystemService.invokeServiceMethod(SystemService.java:350)
[INFO] at com.google.api.server.spi.handlers.EndpointsMethodHandler$RestHandler.handle(EndpointsMethodHandler.java:114)
[INFO] at com.google.api.server.spi.handlers.EndpointsMethodHandler$RestHandler.handle(EndpointsMethodHandler.java:102)
[INFO] at com.google.api.server.spi.dispatcher.PathDispatcher.dispatch(PathDispatcher.java:49)
[INFO] at com.google.api.server.spi.EndpointsServlet.service(EndpointsServlet.java:71)
[INFO] at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
I have tried deploying the exact same code to App Engine and it works perfectly. I have tried debugging EspAuthenticator and it seems that it is expecting the Servlet filters to inject some attributes in the request.
It took me a while and a bit of debugging to realize that the filter that is supposed to inject method_info was not being fired.
I could fix it by modifying the mapping in web.xml adding the following dispatcher tags:
<filter-mapping>
<filter-name>endpoints-api-configuration</filter-name>
<servlet-name>EndpointsServlet</servlet-name>
<dispatcher>REQUEST</dispatcher>
<dispatcher>INCLUDE</dispatcher>
<dispatcher>FORWARD</dispatcher>
</filter-mapping>
generat and deploy the OpenAPI configuration file
$ mvn clean package endpoints-framework:openApiDocs -DskipTests
$ gcloud endpoints services deploy target/openapi-docs/openapi.json
$ mvn appengine:run
I got the same error message, and eventually tracked it down to making a request with a trailing / in the URL where my API did not specify one. The trailing slash only causes an error for calls that provide an authorization token.
Apparently ControlFilter (and therefore also GoogleAppEngineControlFilter) did not recognize it as a valid endpoint and therefore did not bother attaching method_info to the request. But then EndpointsServlet thought it was valid and tried to authenticate without all the needed info!
The fix was easy: remove the trailing slash from the URL in my request. Tracking down the problem, however, was not! I see this was not your problem, but maybe this answer will help someone else.
#Kevendra's answer highlights that this issue can be caused if an openapi.json file is missing a reference to the endpoint API method. Firebase may be using this to reference and discover the API method.
From the Google OpenAPI Overview:
Basic structure of an OpenAPI document:
An OpenAPI document describes
the surface of your REST API, and defines information such as:
The name and description of the API. The individual endpoints (paths)
in the API. How the callers are authenticated.
Follow these steps to regenerate and deploy the openapi.json file:
generate:
$ mvn clean package endpoints-framework:openApiDocs -DskipTests
mvn clean - run a Maven goal to clean your project. package - compile and package it
endpoints-framework:openApiDocs generate OpenAPI documents. This will generate the openapi.json file at the location: target/openapi-docs/openapi.json- see generating and deploying an api configuration.
-DskipTests skips running any tests, to avoid any test failure due
to the openapi.json not yet being generated
deploy:
(As a precaution you can first validate the project ID returned from the following command to make sure that the service isn't created in the wrong project - gcloud config list project)
$ gcloud endpoints services deploy target/openapi-docs/openapi.json
Deploys the openapi.json file from its generated location (in the 'generate' step above). See the Google docs on Deploying the OpenAPI document
In my SBT build I have a dependency on an ivy artifact that makes use of a custom module status. This causes the following error in SBT:
[error] (*:update) sbt.ResolveException: unresolved dependency: my-org#myapp-core_2.11;1.0: java.text.ParseException: inconsistent module descriptor file found in 'http://artifacts.myorg.com/libs-snapshots-local/myapp-core_2.11/1.0/myapp-ivy.xml': bad status: 'snapshot';
I can work around this by telling SBT to use an external ivy settings, like so:
externalIvySettings(baseDirectory(_ / "ivySettings.xml"))
And then create an ivySettings.xml containing the following:
<statuses default="release">
<status name="release" integration="false"/>
<status name="snapshot" integration="false"/>
</statuses>
But surely there must be a better way? The problem with this work around is that now all my settings (such as resolvers) have to be in the ivy file too, because (IFAIK) it's all or nothing when you use externalIvySettings.
Is there a way to specify a set of custom statuses within my build.sbt? Or alternatively is there a way to tell sbt to combine external ivy settings with the ones it generates from the build.sbt.
Since specifying custom module statuses is a valid thing to do in ivy, this should really be supported in sbt too.
This is because for some repositories, they use non-standard status which fails the consistency check. We addressed this by constructing the customized resolver which doesn't do consistency check. You can also construct resolver with the custom status using the same approach. The following is the working snippet.
resolvers += {
val resolver = new org.apache.ivy.plugins.resolver.IBiblioResolver
resolver.setName("Custom Ivy Snapshots")
resolver.setRoot("http://Custom/snapshots/")
val settings = new org.apache.ivy.core.settings.IvySettings()
settings.setVariable("ivy.local.default.ivy.pattern", Pattern)
settings.setVariable("ivy.local.default.artifact.pattern", Pattern)
resolver.setSettings(settings)
resolver.setM2compatible(true)
resolver.setCheckconsistency(false)
new RawRepository(resolver)
}
After executing the following command for CRUD generation:
php app/console generate:doctrine:crud --entity=AcmeDemoBundle:Users --format=yml
i get error for automatic routing update by CRUD for each entity.
Confirm automatic update of the Routing [yes]? yes
Importing the CRUD routes: FAILED
The command was not able to configure everything automatically.
You must do the following changes manually.
- Import the bundle's routing resource in the bundle routing file
(C:\wamp\www\symfony\src\Acme\DemoBundle/Resources/config/routing.yml).
AcmeDemoBundle_categories:
resource: "#AcmeDemoBundle/Resources/config/routing/categories.yml"
prefix: /categories
I also tried creating a new bundle but still gets same error. So everytime i add the above code in routing file /src/Acme/DemoBundle/Resources/config/routing.yml
Can someone please suggest what i am missing?
I get the same thing, not sure how to get the generation to work right but it wants you to add that code to your main routing.yml file so it can link the generated routes:
AcmeDemoBundle_categories:
resource: "#AcmeDemoBundle/Resources/config/routing/categories.yml"
prefix: /categories