I've been experiencing a strange error while working on my Play Framework project. While my project is running, I will sometimes receive a ClassCastException, but the error is this:
ClassCastException occured : models.Person cannot be cast to models.Person
This occurs usually when I'm calling a find method such as:
Person p = Person.find("name=?","Joe").first();
If I restart the project, the problem goes away, but only temporarily. It makes testing my project a major pain. How do I fix this?
I've experienced this error while in Dev mode in Play, in two scenarios (as far as I can remember):
Modify an entity and try to recover values from cache that are objects of that entity class.
A compilation error while reloading the code of the page/application
In both scenarios fixing compilation errors or cleaning the cache solved the issue.
Not saying that those are the only possibilities, it may be that you are having some other issue.
This most likely occurs because you've somehow loaded the Person class under two different class loaders. When a class is loaded twice in two different class loaders it's effectively two distinct classes.
(Unfortunately, I can't tell you where/how you might have done this.)
(And it is a bit curious to have the problem pop up on the statement you list. Are you certain that's where it's occurring? Perhaps you should show the exception traceback.)
In my case, this is related to applying evolutions from the web interface. Someone raised a bug for this, but so far it hasn't received any attention from the dev team. There is a patch attached to the ticket, but I haven't tried it, so YMMV.
Related
We're using Ninject 3.0 to resolve a class.
Fairly boring standard stuff:
IKernel kernel = GetKernel();
var foo = kernel.Get<IFoo>();
However on one particular machine, we're getting an exception when constructing... something. We know what's blowing up, but it's in the logging framework (Common.Logging), and that code is used throughout our codebase, in all/most of the constructors.
Other than putting every single constructor in a try/catch and wrapping the exceptions with type info, I get no useful information from Ninject as to what it's having trouble with.
Is there some way I can get Ninject to tell us which class that it's failing to create?
Another person asks a similar question, but their solution doesn't help - we are getting the exceptions from the logging framework, not Ninject.
This isn't really a solution but when I've had problems I've manually deleted constructor dependencies one at a time until I've found the problem dependency. When I verify all works without that one dependency, I then go into that concrete implementation. I essentially recursively, from the entry point go down through each dependency, removing each dependency until the unbound dependency is identified. Tiring, but brute force hasn't failed me yet. Even when I encountered a private constructor being the cause of a problem, I'd never of gotten that without brute force. More commonly though, it's an unbound type somewhere or a conditional injection.
I have undoubtedly set something up wrong but frequently I get exceptions thrown by my Razor templates even though there is no problem with the templates. These are usually fixed by my doing a build.
If I do actually have an error in the template I get a popup asking me to debug in VS, but of course this does not actually allow me to debug the template.
Errors in my log are not all that helpful (see below).
Is it possible to both avoid spurious errors and get better information when there is actually a problem?
ServiceStack.Razor.Templating.TemplateCompilationException: Unable to compile template. Check the Errors list for details.
at ServiceStack.Razor.Templating.TemplateService.CreateTemplate(String template, Type modelType)
at ServiceStack.Razor.Templating.TemplateService.Compile(ViewPageRef viewPageRef, String template, Type modelType, String name)
at ServiceStack.Razor.Templating.TemplateService.Compile(ViewPageRef viewPageRef, String template, String name)
at ServiceStack.Razor.ViewPageRef.Compile(Boolean force)
I was having similar problems. I found the "easiest" way to find out what the error was, was to download all of service stack, build a debug version of the razor libary and link it into my project. I then set a break point in the ServiceStack.Razor.Templating.TemplateService.CreateTemplate method and was able to see the full exception details. From there I learnt that I had included an import in my razor page that was not referenced in my project.
Since I solved this it's been very reliable.
I had trouble with this myself, because ServiceStack swallowed the exceptions, and the logs, as you said, don't show the Errors collection. There are two ways to get that information:
Uncheck Enable Just My Code in the debugging options in Visual Studio (Debug -> Options and Settings). If you have checked Thrown for Common Language Runtime Exceptions in Debug -> Exceptions, you will get the exceptions, and be able to view the Errors collection.
A merge was committed some days ago to the ServiceStack repository, which makes it log the Errors collection. Demis Bellot apparently pushes new versions to NuGet fairly often, so it'll probably be there in a week or two.
I had the same problem. And my case, I have removed some libraries referenced in the project but the reference to them remained (eventhought I think removed it, but anyway) and this has been the problem.
After I deleted the references to libraries which don't exsits anymore in the project, it worked immediatelly.
I had this strange problem with stack underflow errors happen only in the release build of Flex Builder project. I looked around the web to find a solution, but while I found some related posts, nothing really helped my out. So here is this question and my solution in the answers so that it may hopefully help other people.
The Problem: I ported a java program (a game) to flex and it works fine in debug mode on Android, the web and Playbook. However, when I build a release version of the game, it crashes. The error reported is 1024, i.e. stack underflow, according to Adobe's documentation.
At first, I thought the problem was limited only to the Playbook, but no, the exact same problem happens at the exact same place on the web browser and Android. From the debugging information I inserted, I discovered that the exception appears to be thrown during the call to another function.
To solve the problem, I broke down the offending function in many individual functions and so narrowed down which precise part of the code what causing problem. This lead me to a few lines of code that had the following call (in a try-catch):
trace(e.getStackTrace())()
Hummm, this apparently was produced by the regex I used to refactor from Java to Actionscript. Removing the extra () solve the problem.
This is the kind of things I wished the compiler would catch instead of letting it fail only at release, when the function containing the offending code is pushed on the stack.
I am following example by José F. Romaniello on session management with NHibernate. It's a very good article, however I'm struggling with it having very little experience with NHibernate, Windsor and MVC.
I am trying to re-create NHibernateInstaller, however encountering the following error: Component Castle.TypedFactory.DefaultInterfaceFactoryComponentSelector could not be resolved. Make sure you didn't misspell the name, and that component is registered.
In the sample project provided this error does not crop up, even though the installer is identical and Google does not come up with any results (which is very unusual). What causes this and how can it be avoided?
it seems a problem with the TypedFactoryFacility... are you doing this?
kernel.AddFacility<TypedFactoryFacility>();
before running all the installers?
uncomment the following code in Bootstrapper.cs file.
container.AddFacility();
This happened to me when I created my own implementation of ITypedFactoryComponentSelector, but forgot to register the selector itself.
There was no indication this was the actual problem (and the kernel debug information assured me the components can be resolved) - but registering it fixed the issue.
Hope this helps someone :-)
I have an application that uses Remote SharedObjects and I am seeing some strange behaviour. I am writing an ActionScript application in AS3 using Flash Builder and connecting to Wowza Media Server 2.
My application is working just fine but I am now trying to write unit tests for it using FlexUnit. My unit tests involve creating multiple connections to the same remote SharedObject and making sure that I am getting updates correctly. Everything seems to be working well except that I am not getting any of the SyncEvent.SYNC events with an info.code of "delete". When I run my applications independently in separate tabs or even separate swfs embedded in the same page it works fine. For some reason though it does not work when inside a unit test. I have also found that if I load the swfs using a Loader inside the same SWF then I get the same behaviour. It seems to me to be something strange about the way multiples of the same SharedObject behave within the same SWF. I have had to work around other strange behaviour in the unit tests such as oldValues not being set properly in the onSync events too.
Anyone have any ideas how I can work around this? Is this a known issue? Am I crazy? :)
Would appreciate any help!
I also faced this problem before when I was working on some Flex application using some coding frameworks like Cairngorm, and connecting to AMFPHP with multi remote objects.
At that time what I come up with to resolve the issue is to make sure that those remote objects won't be fired at the same time. That is trying to make some so called "sequential chain" to fire those remote objects one after another.
In order to achieve this it may be difficult if you do it from scratch, you may consider making use of those modern ActionScript framework 2.0 to help you (e.g. SWIZ or Robotlegs). This may be too complex to handle in the very beginning. I suggest you can just place the remote object parts to be handled by the framework while keeping other things intact.
To get your sharedObject instance, you are using the static method SharedObject.getRemote(). I believe this method will always return the same instance for a given name (and if the persistence parameter has the same value).
You can have the same kind of issue when you remove a SharedObject from your app (mySO = null) and you reinstantiate it before the garbage collector did its job).
This kind of behavior makes sense to me, but it can sometimes be a problem I must admit. Anyway it should be easy to test in a debug session (Have a look at your objects instance number).
Now talking about unit tests, what are you testing? The SharedObjects behavior? If so, I believe there is some misconception here. It you really want to test this kind of behavior (and I would be interested in the reason behind), then I guess you will need some more complex tests that run two separate applications.
Hope it helps!
We had similar behavior with deletes in our project.
When we call so.close(). Then delete some key in shared object. Then connect SO again - it still see deleted key alive.
Workarounds: do not close SO or update deleted keys with some constants values (-2 for example) to mark them deleted.
Wowza 3 was used.