I have a couple of places set up, and they work correctly, except with a delay caused by this issue. They're using nested presenters.
For one place, it appears that any repeat attempt to load it causes an infinite loop of reveal error / unauthorized place (no idea why, no gatekeeper set), but then loads the page correctly. The issue I have with it is the delay and unnecessary log spam it causes - it loads the page correctly, why can't it do it without going through the loop first? Anyone have any ideas?
-- UPDATE --
I am using GWTP 1.4 with GWT 2.7.0, but the project was first created using GWTP 0.6 or maybe earlier. We've updated deprecation etc as we've upgraded, but I know there are anachronisms left.
I tried switching out our ClientPlaceManager with the default, bound the ErrorPlace and UnauthorizedPlace to our home page, and removed its gatekeeper, but it still tries to go to the error place (overrode the revealErrorPlace method and noticed it's throwing the error for a valid token that had been loaded at least once already that session. One page in particular, none of the presenter lifecycle phases are firing, though the presenter is visible (only breaking in firefox I think). I really don't understand it.
-- UPDATE 2 --
I've removed gatekeepers (even specifying #NoGatekeeper), have ensured that the error / unauthorized place have #NoGatekeeper and exists, and overrode revealPlace(request, updateUrl) to output results, and added a try/catch - and it does the exact same thing. An infinite loop, but everything is accessible. my debug output even shows it attempting to reveal the error place, but it never does, just errors out.
This is frustrating to no end.
Stacktrace:
SEVERE: Exception caught: Encountered repeated errors resulting in an infinite
loop. Make sure all users have access to the pages revealed by revealErrorPlace
and revealUnauthorizedPlace. (Note that the default implementations call
revealDefaultPlace)
com.google.gwt.event.shared.UmbrellaException: Exception caught:
Encountered repeated errors resulting in an infinite loop. Make sure all users
have access to the pages revealed by revealErrorPlace and
revealUnauthorizedPlace. (Note that the default implementations call
revealDefaultPlace)
at Unknown.fillInStackTrace_0_g$(student-0.js#36:10580)
at Unknown.Throwable_3_g$(student-0.js#8:10535)
at Unknown.Exception_3_g$(student-0.js#18:10678)
at Unknown.RuntimeException_3_g$(student-0.js#18:61481)
at Unknown.UmbrellaException_3_g$(student-0.js#25:133542)
at Unknown.UmbrellaException_5_g$(student-0.js#26:133603)
at Unknown.fireEvent_7_g$(student-0.js#13:133134)
at Unknown.fireEvent_12_g$(student-0.js#22:154354)
at Unknown.fire_8_g$(student-0.js#17:132936)
at Unknown.fireValueChangedEvent_0_g$(student-0.js#3:154358)
at Unknown.onHashChanged_0_g$(student-0.js#29:154297)
at Unknown.apply_0_g$(student-0.js#28:109006)
at Unknown.entry0_0_g$(student-0.js#16:109062)
at Unknown.anonymous(student-0.js#14:109042)
Caused by: java.lang.RuntimeException: Encountered repeated errors resulting in
an infinite loop. Make sure all users have access to the pages revealed by
revealErrorPlace and revealUnauthorizedPlace. (Note that the default
implementations call revealDefaultPlace)
at Unknown.fillInStackTrace_0_g$(student-0.js#36:10580)
at Unknown.Throwable_2_g$(student-0.js#8:10526)
at Unknown.Exception_2_g$(student-0.js#18:10672)
at Unknown.RuntimeException_2_g$(student-0.js#18:61475)
at Unknown.startError_0_g$(student-0.js#11:92009)
at Unknown.error_2_g$(student-0.js#8:91772)
at Unknown.doRevealPlace_0_g$(student-0.js#10:91762)
at Unknown.revealPlace_1_g$(student-0.js#8:91921)
at Unknown.revealPlace_0_g$(student-0.js#8:91908)
at Unknown.revealErrorPlace_1_g$(student-0.js#8:92109)
at Unknown.error_2_g$(student-0.js#8:91773)
at Unknown.doRevealPlace_0_g$(student-0.js#10:91762)
at Unknown.handleTokenChange_0_g$(student-0.js#12:91848)
at Unknown.onValueChange_4_g$(student-0.js#8:91888)
at Unknown.dispatch_87_g$(student-0.js#16:132968)
at Unknown.dispatch_88_g$(student-0.js#8:132972)
at Unknown.dispatch_0_g$(student-0.js#8:49973)
at Unknown.dispatchEvent_2_g$(student-0.js#14:133006)
at Unknown.doFire_0_g$(student-0.js#9:133250)
at Unknown.fireEvent_8_g$(student-0.js#8:133323)
at Unknown.fireEvent_7_g$(student-0.js#25:133128)
at Unknown.fireEvent_12_g$(student-0.js#22:154354)
at Unknown.fire_8_g$(student-0.js#17:132936)
at Unknown.fireValueChangedEvent_0_g$(student-0.js#3:154358)
at Unknown.onHashChanged_0_g$(student-0.js#29:154297)
at Unknown.apply_0_g$(student-0.js#28:109006)
at Unknown.entry0_0_g$(student-0.js#16:109062)
at Unknown.anonymous(student-0.js#14:109042)
If you're using the DefaultPlaceManager, make sure you have bound DefaultPlace, ErrorPlace and UnauthorizedPlace to Presenter name tokens in your Gin module.
From DefaultPlaceManager's javadoc (http://arcbees.github.io/GWTP/javadoc/apidocs/com/gwtplatform/mvp/client/proxy/DefaultPlaceManager.html):
Important! If you use this class, don't forget to bind DefaultPlace,
ErrorPlace and UnauthorizedPlace to Presenter name tokens in your Gin
module.
Note: The default, error and unauthorized places are revealed without
updating the browser's URL (hence the false value passed in
revealPlace). This will avoid stepping into an infinite navigation
loop if the user navigates back (using the browser's back button).
Here's an example of infinite navigation loop that we want to avoid:
An unauthenticated hits #admin (a place reserved to authenticated
admins) The #unauthorized place is revealed, and the browser's URL is
updated to #unauthorized The user clicks the back button in his
browser, lands in #admin, then #unauthorized, then #admin, and so on.
Also, from https://github.com/ArcBees/GWTP/issues/296:
Verify that the Interface of the Proxy in your Presenter inherit from
ProxyPlace.
Related
I'm some tests to trigger and validate a JS alert like this:
it 'triggers a modal' do
accept_alert('Hello world') do
visit '/'
click_button 'Button'
end
end
Which is failing on:
Capybara::ModalNotFound:
Unable to find modal dialog with Hello world
When running headlessly, I thought that the dialog wasn't triggered at all and it was an issue with my JS code but I noticed the test log listed:
* Listening on tcp://127.0.0.1:3001
Modal window has been opened, but you didn't wrap your code into (`accept_prompt` | `dismiss_prompt` | `accept_confirm` | `dismiss_confirm` | `accept_alert`), accepting by default
F
Running in full Chrome I noticed that the modal is being triggered and with the expected message. So now I'm not sure:
why my accept_alert isn't failing the test if the message is actually wrong (e.g. there are hidden characters included and the message is actually Hello world\t. or something)
how is an unwrapped modal since my accept block wraps the whole test body?
I might have a silly syntax error, but I think the above is right & is working on another test. To try and get to the bottom of it, I wanted to disable Capybara's "accepting by default".
Is there any way to:
Make any unexpected modal fail the test (instead of accept/dismiss)?
Log out the text of modals as they occur?
The accepting by default isn't being done by Capybara it's being done be the driver you're using (Cuprite I'm assuming based on the message being produced). If you wrap the action that causes the modal to appear (based on behavior exhibited I'm assuming the visit) rather than the whole test then it will raise an error if the error message isn't correct
since the accept_alert method is only expecting the modal once the block has finished expecting
accept_alert('Hello world') do
visit '/'
end
click_button 'Button'
The behavior of auto-accepting (with warning) unexpected alerts is due to its original design being based on the Poltergeist and I don't believe is configurable currently.
I want to perform click and scroll down action on a element .
* Already i tried with Action class
* javascript executor.
* Robot class
First I am trying to click on element and hold it for a while and then scroll till expected element finds but I am getting error as method has not yet been implemented.
WebDriverException: Method has not yet been implemented (WARNING: The server did not provide any stacktrace information)
1.The above error comes when your app is not matching with the current context
2.According to your code there is a need of context change of app environment you can change context using driver.context("YOUR APP CONTEXT NAME")
3.Some times there must be error in your code like it is not locating correct element or may be you are using unwanted method
Try above 2 points it might help you
if it is not working sorry for wasting your Testing time
Happy Testing
The error popup with the following error message comes on the screen repeatedly when application is in idle state (no user activity is performed).
Error occurred on client: (TypeError): Unable to get property 'iterator_0' of undefined or null reference.
number: -2146823281
at handleEvent_206....EF34544...cache.html
at dispatchEvent_0..EF34544...cache.html
at sucess_184 ..
..
Can anyone give some pointers to navigate to the problamatic area in the code?
The fact that you're getting it repeatedly is probably due to the fact that you're performing an action on a timer (i.e. perform repeatedly an action).
From the small snippet you've shown, I don't think there's anything we can deduce. Do you have a larger stacktrace? It is still possible the error is in your own code (trying to invoke iterator() on a null object).
I am getting following exception in a single box cq5 author environment.
javax.jcr.InvalidItemStateException: Item cannot be saved
because node property has been modified externally
more exception details:
Caused by: javax.jcr.InvalidItemStateException: Unable to update a stale item: item.save()
at org.apache.jackrabbit.core.ItemSaveOperation.perform(ItemSaveOperation.java:262)
at org.apache.jackrabbit.core.session.SessionState.perform(SessionState.java:216)
at org.apache.jackrabbit.core.ItemImpl.perform(ItemImpl.java:91)
at org.apache.jackrabbit.core.ItemImpl.save(ItemImpl.java:329)
at org.apache.jackrabbit.core.session.SessionSaveOperation.perform(SessionSaveOperation.java:65)
at org.apache.jackrabbit.core.session.SessionState.perform(SessionState.java:216)
at org.apache.jackrabbit.core.SessionImpl.perform(SessionImpl.java:361)
at org.apache.jackrabbit.core.SessionImpl.save(SessionImpl.java:812)
at com.day.crx.core.CRXSessionImpl.save(CRXSessionImpl.java:142)
at org.apache.sling.jcr.resource.internal.helper.jcr.JcrResourceProvider.commit(JcrResourceProvider.java:511)
... 215 more
Caused by: org.apache.jackrabbit.core.state.StaleItemStateException: 3bec1cb7-9276-4bed-a24e-0f41bb3cf5b7/{}ssn has been modified externally
at org.apache.jackrabbit.core.state.SharedItemStateManager$Update.begin(SharedItemStateManager.java:679)
at org.apache.jackrabbit.core.state.SharedItemStateManager.beginUpdate(SharedItemStateManager.java:1507)
at org.apache.jackrabbit.core.state.SharedItemStateManager.update(SharedItemStateManager.java:1537)
at org.apache.jackrabbit.core.state.LocalItemStateManager.update(LocalItemStateManager.java:400)
at org.apache.jackrabbit.core.state.XAItemStateManager.update(XAItemStateManager.java:354)
at org.apache.jackrabbit.core.state.LocalItemStateManager.update(LocalItemStateManager.java:375)
at org.apache.jackrabbit.core.state.SessionItemStateManager.update(SessionItemStateManager.java:275)
at org.apache.jackrabbit.core.ItemSaveOperation.perform(ItemSaveOperation.java:258)
Here is the code sample:
adminResourceResolver = resourceResolverFactory
.getAdministrativeResourceResolver(null);
Resource fundPageResource = adminResourceResolver.getResource(page
.getPath() + "/jcr:content");
ModifiableValueMap homePageResourceProperties = fundPageResource
.adaptTo(ModifiableValueMap.class);
homePageResourceProperties.put("ssn",(person.getSsn());
adminResourceResolver.commit();
Any ideas ? It could be possible multiple threads accessing this code, as multiple authors on multiple pages calling this code from a authored component.
Thank you,
Sri
This is an error your see often in CQ5.5 (and lessens with each version upwards). The root cause of this issue is that multiple processes/services are modifying the same resource in roughly the same timespan (usually using different sessions, sometimes even with different users).
A small example to demonstrate perhaps. Session A and B both have a reference to Resource X. Session A modifies some properties on X, saves and commits, and is destroyed. This all goes smoothly. Session B still has a snapshot of the situation before A made modifications, session B makes modifications and all seems well UNTIL it tries to save. At this point, session B detects that it can't commit its changes because it doesn't have the latest node state. It has detected some other sessions made changes to the same node. In essence the current node state conflicts with modifications that session A has done and throws an ItemStale exception. The reason for this exception is the notion that the API doesn't know wether you want to keep the changes made by A, keep the changes made by the current session and discard the changes made by A, or merge them.
This error happens often with long running sessions and with workflow/listener combinations. Therefore the recommendation is to keep sessions as short as possible to prevent this kind of conflicts as much as possible.
One way to deal with this is to call session.refresh(keepChangesBoolean) before calling .save(). This instructs the current session to check for updates made by other sessions and deal with it according to the boolean flag you submit. This however is not a guarantee as it's still possible that between your refresh and your save call, yet another session has done the same. It only lowers the odds of this exception occurring.
Another way to deal with this is to retry again from scratch.
This is a weird one. :)
I have a script running under Apache 1.3, with Apache::PerlRun option of mod_perl. It uses the standard CGI.pm module. It's a regularly accessed script on a busy server, accessed over https.
The URL is typically something like...
/script.pl?action=edit&id=47049
Which is then brought into Perl the usual way...
my $action = $cgi->param("action");
my $id = $cgi->param("id");
This has been working successfully for a couple of years. However we started getting support requests this week from our customers who were accessing this script and getting blank pages. We already had a line like the following that put the current URL into a form we use for customers to report an issue about a page...
$cgi->url(-query => 1);
And when we view source of the page, the result of that command is the same URL, but with an entirely different query string.
/script.pl?action=login&user=foo&password=bar
A query string that we recognise as being from a totally different script elsewhere on our system.
However crazy it sounds, it seems that when users are accessing a URL with a query string, the query string that the script is seeing is one from a previous request on another script. Of course the script can't handle that action and outputs nothing.
We have some automated test scripts running to see how often this happens, and it's not every time. To throw some extra confusion into the mix, after an Apache restart, the problem seems to initially disappear completely only to come back later. So whatever is causing it is somehow relieved by a restart, but we can't see how Apache can possibly take the request from one user and mix it up with another.
This, it appears, is an interesting combination of Apache 1.3, mod_perl 1.31, CGI.pm and Apache::GTopLimit.
A bug was logged against CGI.pm in May last year: RT #57184
Which also references CGI.pm params not being cleared?
CGI.pm registers a cleanup handler in order to cleanup all of it's cache.... (line 360)
$r->register_cleanup(\&CGI::_reset_globals);
Apache::GTopLimit (like Apache::SizeLimit mentioned in the bug report) also has a handler like this:
$r->post_connection(\&exit_if_too_big) if $r->is_main;
In pre mod_perl 1.31, post_connection and register_cleanup appears to push onto the stack, while in 1.31 it appears as if the GTopLimit one clobbers the CGI.pm entry. So if your GTopLimit function fires because the Apache process has got to large, then CGI.pm won't be cleaned up, leaving it open to returning the same parameters the next time you use it.
The solution seems to be to change line 360 of CGI.pm to;
$r->push_handlers( 'PerlCleanupHandler', \&CGI::_reset_globals);
Which explicitly pushes the handler onto the list.
Our restart of Apache temporarily resolved the problem because it reduced the size of all the processes and gave GTopLimit no reason to fire.
And we assume it has appeared over the past few weeks because we have increased the size of the Apache process either through new developments which included something that wasn't before.
All tests so far point to this being the issue, so fingers crossed it is!