I'm using spymemcached version 2.8.1 to read a cookie object but I keep running into the following exception:
app[web.1]: WARN net.spy.memcached.transcoders.SerializingTranscoder:
Caught CNFE decoding 513 bytes of data
app[web.1]: java.lang.ClassNotFoundException
org.apache.http.impl.cookie.BasicClientCookie
I am using httpclient version 4.1.1: https://dl.dropbox.com/u/6207935/Screen%20Shot%202013-02-05%20at%202.47.19%20PM.png
which has BasicClientCookie class inside of it so I'm not quite sure why it "cannot be found"
Also based on hear-say I think that BasicClientCookie is already marked as Serializable in 4.1.1 but the exact javadocs have been a bit difficult to dig up, honestly ... so its an assumption on my part. Anyway, the exception doesn't seem to be related to serialization but I thought I'd throw this out there for question completeness.
What would be some ideas to resolve this issue?
UPDATE # 1 (Feb 5, 2013)
These may shed some light on the problem:
http://code.google.com/p/spymemcached/issues/detail?id=146 - But when using Heroku I don't know how to obtain the same level of control over my app server's file system ... the way its described here.
http://code.google.com/p/spymemcached/issues/detail?id=155 - Not sure how to get spymemcached to use the custom SerializingTranscoder.
The advice given here worked: http://code.google.com/p/spymemcached/issues/detail?id=155#c2
The only additional bit was testing it out after applying the custom SerializingTranscoder to spymemcached
MemcachedClient mc =
new MemcachedClient(
new ConnectionFactoryBuilder()
.setTranscoder(new CustomSerializingTranscoder()) // makes it take effect
.setProtocol(ConnectionFactoryBuilder.Protocol.BINARY)
...
Related
I'm using Processing 3 for generating a Treemap.I installed gicentreUtils and placed TreeMappa file in the library folder of Processing. I'm getting nullPointerException in line:
pTreeMappa = new PTreeMappa(this).
The full code can be found in this
link
Can someone please let me know how to resolve this error.
Thanks
It seems the TreeMapa library hasn't been updated in a few years and internally it may use some Processing code that changed from version 2.x to 3.x (like windows/frames/etc.) which is why the error might occur.
I advise using TreeMapa with Processing 2.2.1 available on the Processing Downloads page
History:
Laravel 4.2 recently updated from 4.1 running on HHVM-stable
This exact code worked before whatever broke broke
Downgrading back to 4.1 didn't resolve
Whenever (apparently) an uncaught exception is thrown, the app crashes with:
exception 'ErrorException' with message 'Attempted to serialize unserializable builtin class Closure$;1617701371#2$9f9bb1ee4ac7330c21e327d2b7294b9c$'
in /home/forge/.../vendor/jeremeamia/SuperClosure/src/Jeremeamia/SuperClosure/SerializableClosure.php:78
It's a dickens to troubleshoot because it seems to crash during error handling, so the feedback it gives me is less than helpful.
Any idea what this is about? Am I alone with this error? Googling turns up nada and this has pretty much shut us down until I can resolve it.
Turns out that happens if you try to serialize an Exception. (In this case, outputting it via Log::error("...", [$e]). Just stringify it and all is good.
If I build my application with spring 3.0.4, the stylesheet is downloaded no problem.
If I build it with 3.2.2.release, however, I get a 405 error saying GET is not supported when it tries to get the stylesheet.
No other changes have been made.
I am deploying to Glassfish
Does anyone have any ideas what could cause this?
Does anyone have any ideas what could cause this?
Potentially many things. (My guess would be that some request is being redirected to the wrong place by SpringSecurity.)
But rather than guessing, you would be better off gathering some concrete evidence of what is happening:
In the web browser, figure out exactly what the pattern of requests and responses is. For instance, if there is a redirect happening, find out what it is redirecting too.
On the server side, enable debug logging for your application, the Spring stack, and if necessary Glassfish. This should provide you with more clues as to what is happening.
So I has a small problem as I outlined here.
I have made a new question because this is more general and will perhaps help others.
So essentially, I integrated the Facebook SDK Into Codeigniter as a library.
The SDK requires Json and Curl.
In the base_facebook.php file there is the following code:
if (!function_exists('curl_init')) {
throw new Exception('Facebook needs the CURL PHP extension.');
}
if (!function_exists('json_decode')) {
throw new Exception('Facebook needs the JSON PHP extension.');
}
If these functions are not available I expect an error to be fired to tell me such. Then I can install the correct packages and continue.
What actually happened is that even when I had error reporting set to E_ALL a blank page was returned.
This made it impossible to debug and after lots of playing I worked out it was because CURL was not installed on my server.
My question is why does codeigniter show blank pages rather than library based exceptions?
Furthermore even if there is an exception in a library why does the rest of the page not continue executing.
Essentially CI is seemingly making the use of exceptions worthless..
COuld anyone advise?
THanks
My question is why does codeigniter show blank pages rather than library based exceptions?
Most likely because display_errors is set to “off”.
While this is recommended for a production environment (web site users are not supposed to see internal error messages – it might give them info about internals, that they are not supposed to have) – it’s not very helpful while developing, where you as the developer want to be informed about what went wrong.
So check if CI has a “debug” setting for this, or if it’s maybe already set to off in your PHP configuration.
(Maybe CI or your config are set up in a way that errors are logged to a file instead. Also recommended for production; while developing, you’d have to keep an eye on this file then.)
Furthermore even if there is an exception in a library why does the rest of the page not continue executing.
Because that’s how exceptions are supposed to work – if they are not being caught when they reach the “top level” of your app, they cause a fatal error, and scripts die when those occur.
Familiarize yourself with the concept of try { … } catch(…) { … } to handle exceptions that might occur in script flow.
(Actually, it’s kinda surprising you don’t know all this already, if you’re working with an advanced PHP framework …)
First of all let me state, that the following code example worked just fine in GF 3.0.1. The troubles started when we switched to GF 3.1.
I'm using a method
#Asynchronous
public void executeFlowStep(
#Observes(during=TransactionPhase.AFTER_COMPLETION)
ExecuteFlowStepEvent executeFlowStepEvent) {
Since the switch, whenever this should receive an ExecuteFlowStepEvent I get the following error message:
WELD-000401 Failure while notifying an observer of event [package].ExecuteFlowStepEvent
No further information or stacktrace is given.
It works if I remove the #Asynchronous annotation and the AFTER_COMPLETION attribute, of course this breaks the program as I depend on the AFTER_COMPLETION timing.
I tried to ask for help on the Weld Forums, so far to no avail, although there seem to be other people with the same problem: http://seamframework.org/Community/WeldUsers
I at least would like to know:
Is this a bug, or is this wanted. Does this imply that Weld does NOT work with Asynchronous methods/AFTER_COMPLETION attributes? Why did this work in GF 3.0.1?
Has anyone managed to make this work on GF 3.1?
According to the link you posted as a comment to your own question, this is a bug that was fixed in Wield 1.1.2 and GlassFish 3.1.2 (build 14+).
disclamer: I posted this answer to an age old question to help SO (StackOverflow) get rid of unanswered questions.