After I installed and referenced the JSNLog package into my MVC project, I'm experiencing an error when ever I click a link.
For example,
Link
usually produce
Link
but after I start using the JSNLog, it now produce
Link
which will direct to a link
http://localhost:51745/jsnlog.logger?action=Bar&controller=Foo
which shows
Exception Details: System.NullReferenceException: Object reference not
set to an instance of an object.
I believe JSNLog is trying to send back a exception or log event back to the server whenever it has a chance to access the server.
Am I missing something to make this functional?
This bug existed when the original post was created, but it has been fixed a few version ago now (I am the author of JSNLog).
This is actually caused by the Ignore route they inject in App_Start, moving it into your routes collection manually fixes the issue. It happens because you don't manually define routes for the rest of the controllers, so .net tries to resolve to the first one it finds defined.
In App_Start\JSNLogConfig.cs take out
RouteTable.Routes.Insert(0, new Route("jsnlog.logger/{*pathInfo}", new StopRoutingHandler()));
In RouteConfig.cs add
routes.IgnoreRoute("jsnlog.logger/{*pathInfo}");
And all your other routes should start working fine.
Related
I have an existing ExtJS application I'm upgrading from 4.x to 6.2.0. I had a simple storage provider setter that I pass into my Ext.onReady() block that looks like the following:
Ext.state.Manager.setProvider(Ext.create('Ext.state.LocalStorageProvider',{}));
When I swapped to 6.2.0, I'd get the error:
ext-all-rtl-debug.js:9389 [E] Ext.util.LocalStorage.constructor(): Cannot create duplicate instance of local store "ext". Use Ext.util.LocalStorage.get() to share instances.
So what I had to do to, what I think is a fix, was the following:
Ext.state.Manager.setProvider(Ext.util.LocalStorage.get('id'));
My concern here though is that I'm just applying a bandaid to the problem and not really going through with a real fix. I don't explicitly set the provider anywhere else, all I did was swap out the ExtJS lib from 4.x to 6.2.0 to get that error. It's as-if it's being created somewhere else first in the 6.2.0 initialization process and now I'm getting a duplicate error as aforementioned.
What has changed in 6.2.0 to cause this behavior? Is there now two providers set, one by ExtJS and one with my client code? Is there a cleaner way of handling this?
The preconditions for this error are the same in both, ExtJS 4 and ExtJS 6. The corresponding file does not have changed: compare ExtJS 4.2.4 version and ExtJS 6.2.0 version.
Because of this your application must be responsible for this. Somewhere in your (upgraded) code an instance of Ext.util.LocalStorage must be created. Since this error is thrown in case the ID is already registered and the registration is done only in the constructor of the Ext.util.LocalStorage class, I'd suggest to set a breakpoint right there to check in the stacktrace which function does call the constructor method.
Some background...
We have an ASP.NET app we're slowly converting over to EmberJS. We have a single Ember application we instantiate for certain portions of the site. As we migration pages they get routes in the Ember app. The goal is to have everything in Ember over time. In the interim, the user can click on links that take them back to ASP.NET portions.
Our issue is with resetting the state of the Ember app if the user either clicks back to go back into Ember or clicks on a new link that takes them back into the Ember portion.
We've tried calling .reset on the application, but doing so gives us an error saying the following. Our application is called ConsoleCli and not the standard App.
Library "ConsoleCli" is already registered with Ember
Moreover, we get the following error saying one of our modules has already been registered.
Cannot re-register: `location:history-js`, as it has already been resolved.
I tried wrapping my registration of the history module with a check, but that creates a whole other slew of errors
if(!application.__container__.lookup('location:history-js')){
application.register('location:history-js', HistoryJsLocation, { singleton: true });
}
I read https://github.com/emberjs/ember.js/issues/10310 and I think it means reset() is supposed to clear all registries once this has all been merged into the main branches.
Shouldn't called App.reset() right in the middle of using an EmberJS application just reset it with no issue?
Excuse my lack of understanding, we're just learning all of this as we go.
We're running the following versions
Ember 1.11.0-beta.2
Ember Data 1.0.0-beta.15
jQuery 2.0.3
TIA!
I think you might have run into this bug: https://github.com/emberjs/ember.js/issues/10310
Try the fix mutewinter suggests in that thread, it has worked for most people (involving myself).
I am trying to add touch support to my meteor application. I added the package hammer:hammer. It stuffs a hammer_hammer.js file into the document, and creates a variable named Hammer. The problem is, the value of this variable is undefined.
The docs for Hammer.js claim I should just include the library, which Meteor does for me, and start using it like this:
var hammertime = new Hammer(element, options);
Obviously, this fails when Hammer is undefined. Is there something else I have to do to use it? Is it a bug in Hammer? Or in the hammer:hammer package?
Note that the variable Hammer exists, but has the value undefined.
Edit: I tried copying the entire contents of hammer_hammer.js into the console, and it actually made it work. Of course, I can't keep doing this every time, nor tell the users to do it.
The Hammer package may not have been published to atmosphere properly.
I investigated the package through source and it looks like the file package.js contains an unnecessary api.export("Hammer"); (since this is already exported by the window). Meteor seems to override the definition with null
Looking at it this can be either a bug in Meteor (since its overriding the variable) or an incorrectly published package (for declaring the export). You may want to get in touch with the guys over at Hammerjs who publish it to ask them to remove the api.export("Hammer");
Updated: Tracked down the issue to https://github.com/hammerjs/hammer.js/issues/741
Why does a TransitionAborted error get thrown when performing a full route transition when changing query params?
I am working off of the "Opt-in to full transition via refresh()" example provided at the bottom of the query parameters Ember guide (http://emberjs.com/guides/routing/query-params/).
The only change I made was to log errors:
Ember.RSVP.configure('onerror', function(error) {
Ember.Logger.assert(false, error);
});
Here is an updated JS Bin: http://jsbin.com/rerido/1/edit?console,output
If you click the "Change it" button, you'll see a TransitionAborted error thrown in the console.
I've been trying to upgrade Ember in my app from 1.7.0-beta.1+canary for some time now, but many of my QUnit tests fail when I run them all together. Most of my tests are fine if I run them in isolation. I suspect the TransitionAborted errors may be causing the test failures. However, I'm not sure if TransitionAborted exceptions are normal when performing full transitions. If anyone can confirm one way or the other, that would be very helpful in getting to the root cause of my problems, whatever they might be.
I was running into this problem too today. I'm using Ember 1.11.1 and Ember-data 1.1.1-beta.16.1.
In my case the change in the query parameter doesn't affect the model's data but another query. So what I ended up doing was removing the refreshModel: true from my parameter in the route code, and I added an observer on the controller for that URL parameter. So when the controller detected a change in that queryParam variable, the controller called the function I needed to re-query my secondary model.
I'm not sure if this would fix the issue if the query parameter is tied to the route's model, as I haven't tried that yet in my code. It looks like from the github link in the comment above that there's a confirmed bug with this somewhere, so I am curious how that will end up.
Bryan
I have run into an issue that I believe is rooted in the implementation of anchor tags in Rhino. Although I am utilizing env.js, I suspect perhaps I am not configuring something correctly.
In particular, my issue occurs while I am attempting to write unit tests against code written for an angularjs application. When I include angular.js (versions 1.2.1 to present), I get the following error:
TypeError: Cannot call method "charAt" of undefined
I am convinced the error is the result of this call to urlParsingNode.pathname since a console.log call reveals that the pathname object is undefined.
I traced the instantiation of the urlParsingNode to this line where we see that it is the result of a call to document.createElement("a"); Further down, we see that they set the href attribute in this line in hopes that the created anchor tag will utilize the browser to correctly parse the URL.
I have to believe I'm not the first to attempt JS unit testing for angular via Rhino, but thus far I've not successfully Googled myself to a solution. Any tips will be greatly appreciated.
Found it and fixed it. The pathname getter/setter simply was undefined for HTMLAnchorElement in env.js.
I submitted a pull request, but unfortunately the project looks all but abandoned. I also couldn't figure out how to build it out to a single file. It appears perhaps someone has taken it upon themselves to break it apart into require.js modules. Not a battle worth fighting for my use case.
So for anyone else who hits this issue, I have the code you need below. It belongs in the HTMLAnchorElement.prototype. In my copy of env.js 1.2, this prototype begins on line 8075. I added the following at line 8118.
get pathname() {
var uri = Envjs.urlsplit(this.href);
return uri.path;
},
set pathname(val) {
var uri = Envjs.urlsplit(this.href);
uri.path = val
this.href(uri.urlunsplit(uri));
},
FYI, my particular issue is resolved with this pull request.