>>>>> "GA" == George Armhold <[EMAIL PROTECTED]> writes:
>> First off Batik 1.0 is getting pretty old now. I strongly suggest
>> using one of 1.1 rc releases.
GA> Ok, perhaps that will help. I was sticking with 1.0 thinking it
GA> would be less feature-rich but more stable. Can anyone tell me
GA> about any known problems with Batik-1.1 RC2?
Well I can name a few that have been discovered in the past day or
two, but in most cases they were also in 1.0. Until we start serious
work on the Dynamic stuff, before which we will fork the code base,
with a stable and development branch, and do a formal 1.1 release. You
can probably assume that every 1.1 RC canidate is better than the
previous one (in fact this is essentially our criteria for doing an RC
release).
>> Who is calling this???
GA> Sorry, here's a more complete stack trace.
GA> org.apache.tomcat.service.TcpWorkerThread.runIt(PoolTcpEndpoint.java:416)
GA> at
GA> org.apache.tomcat.util.ThreadPool$ControlRunnable.run(ThreadPool.java:498)
GA> at java.lang.Thread.run(Thread.java:484)
Ok as I thought you are definitely beeing called from multiple
threads (as you admit later :).
GA> Some more context: I'm trying to get access to the DOM nodes that
GA> are created by SVGGraphics2D. I'm doing this in the fashion of
GA> SwingSVGPrettyPrint, as was suggested on the batik-users list.
GA> Here's what I'm doing, boiled down to essentials:
GA> // my pre-existing SVGGraphics2D, that I wish to paint on
GA> SVGGraphics2D g = ...;
I assume by this you mean it is some sort of singleton or shared
instance (from a static or some such)?
GA> // create a copy of this SVG SVGGraphics2D g2 =
GA> (SVGGraphics2D) g.create();
Be aware that this does not appear to do a deep copy , and this
method is not thread safe (so if two threads call g.create() at the
same time you will be in trouble).
GA> // prune existing top level group Element origTopLevelGroup
GA> = g2.getTopLevelGroup();
GA> // do my drawing g2.fill(shape);
GA> // prune this top level group with our drawing off Element
GA> drawGroup = g2.getTopLevelGroup();
GA> // set an id, so we can refer back to it later if desired
GA> String id =
GA> g.getGeneratorContext().getIDGenerator().generateID(name);
GA> drawGroup.setAttributeNS(null, "id", id);
GA> // splice our node back in
GA> origTopLevelGroup.appendChild(drawGroup);
GA> g.setTopLevelGroup(origTopLevelGroup);
Have you tried putting the above code in a synchronize block on g?
GA> I don't entirely comprehend what's going on in
GA> SwingSVGPrettyPrint, but my understanding is that you essentially
GA> create a clean slate (a new <g> tag) with the first call to
GA> getTopLevelGroup. Then you do your drawing. Then you call
GA> getTopLevelGroup again, and you now have access to the <g> that
GA> contains your recent drawing. Then you can set attributes on this
GA> <g>, and splice it back into the DOM tree. Is this accurate?
GA> (Suggestions on cleaner ways to get access to the nodes are
GA> welcome...)
I dunno, Vincent?
>> Is the code calling your code single-threaded? Just because _you_
>> don't create threads doesn't mean you aren't be invoked from
>> multiple threads (such as the event thread, and the application
>> main thread for a swing application, as a servelet you may be
>> invoked
GA> Actually it's being called from a Servlet so there are certainly
GA> multiple threads in play, but a new SVGGraphics2D is created for
GA> each doPost/doGet, and I do all my painting serially from that
GA> thread. I'm not doing any painting in response to GUI/Swing
GA> events.
When you say a new SVGGraphics2D is created for each one are you
counting 'create' as creating a new one? If so this is the problem.
GA> Ok, I agree that the patch is not the best solution. But to the
GA> best of my knowledge my code is manipulating the DOM serially, so
GA> I'm not sure where to look for the real problem. Perhaps someone
GA> can comment on whether my manipulations with getTopLevelGroup are
GA> really ok or not.
Before I ever do anything with an SVGGraphics2D I would print my
current thread and the Graphics2D, if you ever see the same Graphics2D
used with two threads you know you have a problem.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
