-----Original Message-----
From: Thomas DeWeese [mailto:[EMAIL PROTECTED]
Sent: Monday, November 15, 2004 9:30 PM
To: Batik Users
Subject: Re: ConcurrentModificationException in RunnableQueue
Andy Lowther wrote:
> I am receiving a ConcurrentModificationException occasionally in the
> UpdateManager's RunnableQueue and was hoping someone else may have a
> solution to my situation.
>
> I have a Thread which has access to a SVGDocument instance, and
modifies
> it.
As you are aware this is a really bad idea. All updates must be
made in the UpdateManager's RunnableQueue if one is associated with
the document.
> This Thread does not have access to the JSVGCanvas, and therefore
> does not have access to the UpdateManager , which is why I am changing
> the Document on a different thread.
Why can't you provide the Thread with access to the RunnableQueue?
> I also have a GUI, which has access to the same SVGDocument. It adds
an
> EventListener for attribute changes within the Document so it can
> repaint. To repaint, I simply place an empty Runnable on the
> UpdateManager thread.
> 1. Gain access the UpdateManager's RunnableQueue instance without
access
> to the JSVGCanvas.
I don't understand the problem with getting the RunnableQueue from
the Canvas and giving it to your other thread.
> 2. Repaint the JSVGCanvas without doing an invokeLater on the
> RunnableQueue
Any repaint will cause problems.
> 3. Be able to recover from this Exception. I know when it occurs, but
> am unable to get the JSVGCanvas to start up a new RunnableQueue
You are likely to lose important updates.
> If anyone can offer some guidance on how to do any of those 3 (or any
> other suggestions), that would be fantastic
>
> I have received this Exception using Batik 1.5.1 and the latest from
> CVS. I am using java sdk 1.4.2_04 on Windows 2000
>
> Thank you,
> -Andy
>
Thanks for getting back to me Thomas. The way our architecture is setup
can be thought of as fitting the model view controller paradigm. Our
Model has access to the data (in this case the SVGDocument) and the View
has access to the GUI and Model (therefore the JSVGCanvas and the
Model's SVGDocument). The real application is a bit more involved, but
this is the way I'm stuck using it.
The solution I've come up with for my problem is for the Model to create
its own RunnableQueue , on which all Document changes are made. When
the View starts up, it sets the Model's RunnableQueue to the one it gets
from its UpdateManager , much like your suggestion to 1. Previously,
the Model synchronized changes, so it didn't care about what Thread they
occurred on
This seems to be working well, thanks for the advice :)
-Andy
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
