I have two routes as follows:
from("rest:get:hello/{user}")
.transform().simple("Hello ${header.user}");
from("rest:get:bye")
.to("http://localhost:8080/hello/quitter?bridgeEndpoint=true");
The first route works great. And returns "Hello friend" when invoked with /hello/friend.
I want the second call to basically call the first API with "quitter" as path param.
However, when i make the second call nothing is returned. There is no error and there is no error message returned.
What is the best way to make the second invocation? In fact, my generation question is how do I get the a rest route to call another rest endpoint and return results.
Related
I am using the latest #stomp/stompjs package in react and it appears to be not working as described so I was wondering if anyone know what was going on.
When I do stompClient.subscribe() I expect only 1 message from the backend. But I normally get an empty object first "{}" and then then the callback goes off again I then get the expect json string. Sometimes I get a 3rd callback with the same json string. I know the page is being redrawn with the new data by react, but I would not think this would cause the callback to go off a second time. Also, this behavior seems to be only for large json string responses. Small response status json objects never returned multiple times in the callback (just the {} object the first time). My workaround was to have a flag that I sett when I do the send command and then is set to false when I get a valid response back. Any extract responses are skipped not saved in the useState hook so react doesn't redraw again.
The second thing I see is sometimes the wrong response is received by the callback. The bookmark paths would be like /location/read and /location/readBL but the response for /location/read would be read by the readBL subscription callback sometimes. This happens 1 out of 10, but I don't understand why it would doing that. The workaround I did is to have the main object key have different words like {camera: {}) and {cameraBL: {}} and see if the object key matches in the expected key in the callback, otherwise skip it.
I assume react is somehow responsible for all this. So, has anyone seen this in their stomp code and know what's going on?
I have inserted flags or filtering to workaround the problem. I have not seen any description of these problems on the web and the stomp home page doesn't talk about any of this.
I am trying to do backend less development in Angular while working disconnected from the backend resources.
Most functionality works fine, but if I try to use any resource a second time I get an error:
Error: Unexpected request: GET /localPTicket?ticket=123
No more request expected
The scenario I am mocking is one where, for every request to a backend service, I have to first make a Get call to get a valid Proxy Ticket, the response from this is then passed to the next API call.
I have set up a plunker that demonstrates the issue:
https://plnkr.co/edit/KKa6MXcnbK1gcMiBB7MI?p=preview
I think that the issue is related to flushing the mock requests, but my understanding of the documentation is that using ngMockE2E this should not be an issue.
Thanks for any pointers!
Les
It's because your are using global regexes.
Global regexes in JavaScript can be very confusing since they have a state. The first time you call it it returns the first match in the string, the second time you call it it returns the next match in the string. If there are no more matches it will return that there were no matches and reset its state.
Simply remove the g from the end of your regexes and it should behave as you expect.
In my web application, the Sign Out link is only shown once the user has logged in - it's not present on the login page.
In my Protractor tests, I want to make sure the user is logged in - which means that in my first test, I have to log in. To check whether the user is logged in or needs to log in, I want to check for the presence of the Sign Out link.
I don't want to do this using expect, since not having the Sign Out link present on the page is perfectly acceptable, it just means that I have to log in.
What I'm looking for is a way to implement an if scenario in my test (in a beforeEach function) - pseudo code:
if (!signOut.isPresent()) {
login();
}
So far, I haven't found an easy way to do this - all of the checks for presence of an item in the page's DOM seem to rely on expect, which throws an exception when the item is not present on the page.
Is there an easy way to do that?
You may just catch the exception.
Or use findElements and check if the returned list of elements is empty, which means the element is not present.
(Not sure about the second solution cause I don't know Protractor, but findElements is what you would use in Java)
The answer by #alb-i986 got me on the right track. After looking at the findElement API, I found two references on how to do the error handling for a this function:
https://github.com/angular/protractor/blob/master/docs/api.md#webdriverwebelement
https://github.com/angular/protractor/issues/485#issuecomment-33951648
Protractor is returning a promise from the findElement function, and the promise's then function (which is called once the promise is resolved) takes two callback arguments:
The first one is called when the promise is resolved successfully, i.e. the element was found on the page.
The second one is optional. When it's not provided, the standard error handling takes place in case the element was not found. This means that the No Such Element exception is thrown. When providing the callback, it's your own responsibility to handle the error there. The error object is provided as a parameter to that callback.
Making use of the second (optional) callback, you can decide to handle or ignore the error:
protractor.getInstance().findElement(by.css(".signout-button"))
.then(function(element) {
// The element was found on the page - click it.
element.click();
}, function(error) {
// Sign out button is not present - handle the error or ignore it
});
What is the difference between these two? Both seems to make a GET to /users and retrieve them.
Restangular.one('users').getList().then(function(users) {
// do something with users
});
Restangular.all('users').getList().then(function(users) {
// do something with users
});
I understand that you can do one('users', 123) and it will retrieve /users/123 but without the second argument it seems to be the same thing. Why not just have one method in that case?
The one() function has a second argument that accepts an id e.g. .one('users', 1).
one('users', 1).get() translates to /users/1
all('users').getList() translates to /users
Unlike all(), one() is not generally used with .getList() without argument. However, if you were to call .one('users', 1).getList('emails') or .one('users', 1).all('emails').getList(), then you would make a GET request to /users/1/emails.
My guess is that they are there for expressing an intention of what you are going to do. I would understand those as a way to build the url, expressing if you are accessing to the whole resource or to a specific one.
In the end, they are gonna build and do a GET request but because you do a GET and retrieve some data it does not mean that it should be used in that way.
Example extracted from https://github.com/mgonto/restangular/issues/450
getList can be called both ways. If it's called in an element one,
then it needs a subelement to get to a Collection. Otherwise, it
fetches the collection. So the following is the same:
Restangular.one('places', 123).getList('venues') // GET /places/123/venues
Restangular.one('places', 123).all('venues').getList() // GET /places/123/venues
As you can see, it is more expressive to call one('places', 123).all('venues') to understand that you just want the venues located in the area/place 123.
Maybe the following url will help you:
https://github.com/mgonto/restangular/issues/450
I've recently discovered a difference between these methods. Yes, both of them make the same get requests, but the results you get might surprise you (as they surprised me).
Let's assume we have an API method /users which returns not strictly an array, but something like this:
{
"result": [{...}]
}
So an array is returned as a value of some prop of the response object. In this case get() and getList() work differently. This code works well:
Restangular.get('users').then(function (response) {...});
Your response handler gets invoked after response has been received. But this code doesn't seem to work:
Restangular.all('users').getList().then(function (response) {...});
Response handler is not invoked, despite that request completed with status code 200 and non-empty response. Browser console doesn't show any errors and network monitor shows successful request.
I've tested this with Restangular 1.5.2 so probably this is already fixed in newer versions.
I'm calling save() on a backbone model to do a POST operation on the back-end. The operation completes successfully server-side (I can see the record added and the response status comes back as 200). Currently the RESTful api call is returning the ID of the inserted record in the response body. I have success and error callbacks defined that I pass to the save call, but success is never called. Instead, the Backbone code is choking on that ID that gets returned from the REST call. Is there a better way for me to handle this from the client end or should the REST api implementation be returning something else?
By default I believe it expects the changed properties of the object as JSON. See: http://documentcloud.github.com/backbone/#Sync