Furry stuff, oekaki stuff, and other stuff.
You are not logged in.
Ah, good. What I was interested in was whether the server is using the ErrorDocument property, or if you had some kind of rewrite rule. The ErrorDocument property is the way to do it.
I read somewhere that you can't use full paths with custom 404 pages -- only relative paths. I don't know if that's just an Apache rule, or if it causes some strange, unreliable redirect behavior.
Java is really, really fussy with paths, though. There are some people who cannot run ShiPainter unless they unarchive the JAR's class files and upload them directly. I hate it when servers do strange things like that, because it takes forever to figure out what's wrong.
Well, funny you should ask that. I hadn't given a whole lot of thought to the actual content of the htaccess file, as it always seemed to work ok.
It looked like this:
ErrorDocument 404 http://acwitness.org/oekaki/404.shtml
I guess having the full path is a problem???
I changed it to
ErrorDocument 404 /404.shtml
and now it is working ok. Jeesh, I feel dumb!!
Ah, this is good to know. I had the problem, too, but re-installing JTablet is what fixed it.
Out of curiosity, what did your htaccess file look like? Custom 404 messages are still supposed to send a 404 HTTP response, so the client knows it is a 404 page, regardless of the contents of the page.
Hi Waccoon - thanks for the response. Actually it turns out that this issue wasn't about Java at all. I posted at the ChibiPaint forum and got this response:
This problem has been reported to me before and I've now figured out the cause.
The reason the problem happens on your server and not on this site for example, is the way it handles 404 errors (what happens when pages are not found).
Here's what happens:
* ChibiPaint tries to load the JTablet class to handle the tablet pressure
* For applets, Java always tries to find the class on the server first, so it will try to get http://www.yourserver/chibipaint/cello/ … blet.class for example, which is where it expects to find JTablet.
* Normally most servers generate a 404 error for unknown urls, when that happens Java tries to find JTablet locally, and ChibiPaint is happy whether or not it finds it. But in your case, the server returns a normal page without the 404 error code and Java thinks it's the JTablet class. But it's not really the class file, it's a html page, so there is an unexpected error when that happens.
Then ChibiPaint keeps trying to load JTablet again and again so it becomes very slow.
To solve this problem and allow your users to have the tablet pressure if they have JTablet installed, you need to make sure that your server returns a 404 error when Java tries that url above. You can probably configure your server so that you can keep the 404 special page for the rest of the site.
I'll make modifications to ChibiPaint so that it's more robust and just reverts to normal functioning without tablet pressure if that error happens but I'm not sure I can modify it in such a way that JTablet will work on servers without 404 errors. So I definitely recommend that you modify that on your side.
It was my .htaccess/custom 404 page that was messing it up - happy to report that all is working well now!!
There's some kind of conflict between JTablet and Chibi Paint that causes this exception. All I know is that if you update Java, re-installing JTablet seems to fix the problem.
Thanks - applied the patch. Unfortunately I can't test it now because I'm back to getting java errors when trying to use the applet. I had changed servers and it was working ok for a couple of weeks for everyone, but then a few days ago a couple people mentioned that it stopped working for them again - and this morning it is no longer working for me. So frustrating - this is the error message:
Java Plug-in 1.6.0_07
Using JRE version 1.6.0_07 Java HotSpot(TM) Client VM
User home directory = C:\Documents and Settings\DEBRA
----------------------------------------------------
c: clear console window
f: finalize objects on finalization queue
g: garbage collect
h: display this help message
l: dump classloader list
m: print memory usage
o: trigger logging
p: reload proxy configuration
q: hide console
r: reload policy configuration
s: dump system and deployment properties
t: dump thread list
v: dump thread stack
x: clear classloader cache
0-5: set trace level to <n>
----------------------------------------------------
Exception in thread "AWT-EventQueue-6" java.lang.ClassFormatError: Incompatible magic value 1011373133 in class file cello/tablet/JTablet
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(Unknown Source)
at java.security.SecureClassLoader.defineClass(Unknown Source)
at sun.applet.AppletClassLoader.findClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at sun.applet.AppletClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClassInternal(Unknown Source)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Unknown Source)
at chibipaint.util.d.<init>(Unknown Source)
at chibipaint.util.d.a(Unknown Source)
at chibipaint.gui.J.mouseMoved(Unknown Source)
at java.awt.Component.processMouseMotionEvent(Unknown Source)
at javax.swing.JComponent.processMouseMotionEvent(Unknown Source)
at java.awt.Component.processEvent(Unknown Source)
at java.awt.Container.processEvent(Unknown Source)
at java.awt.Component.dispatchEventImpl(Unknown Source)
at java.awt.Container.dispatchEventImpl(Unknown Source)
at java.awt.Component.dispatchEvent(Unknown Source)
at java.awt.LightweightDispatcher.retargetMouseEvent(Unknown Source)
at java.awt.LightweightDispatcher.processMouseEvent(Unknown Source)
at java.awt.LightweightDispatcher.dispatchEvent(Unknown Source)
at java.awt.Container.dispatchEventImpl(Unknown Source)
at java.awt.Component.dispatchEvent(Unknown Source)
at java.awt.EventQueue.dispatchEvent(Unknown Source)
at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.awt.EventDispatchThread.run(Unknown Source)
Well, I feel dumb. I fixed a side effect, not the actual problem. Since Chibi Paint doesn't use the animation flag like all the other applets do, everything was getting out of sync. So, now the database is updated every time a new layers file is sent, and old layers files are properly deleted when the applet doesn't send a new one.
Re-download the small 1.4.1 patch and apply it again.
Well, this is what happens now. You can go in and re-touch, but when you send it again, and choose yes for saving .chi file, it puts the newly re-touched image into "recover pics" and gives it a new number. The first image still appears on the board, without the retouches. If you send with the "no" option for saving .chi file, retouches appear, but then layers are merged.
I found a problem with how Wacintaki is handling the layers file. 1.4.1 has been released to fix both the layers file import and delete issues, and also has an updated profile viewer.
If you want to fix the CHI files that are already saved on the sever, this file will fix them. All it does is restore the animation flag on CHI files, so the applet knows that a layers file is present.
You don't really need to worry about the leftover CHI files, but you can delete them via FTP if you want to.
I mean saying yes when the applet asks to save layers file. Don't know if it's happening to everyone on my board. It doesn't work for me, and one other person mentioned it so far.