> First off Batik 1.0 is getting pretty old now. I strongly suggest
> using one of 1.1 rc releases.
Ok, perhaps that will help. I was sticking with 1.0 thinking it would
be less feature-rich but more stable. Can anyone tell me about any
known problems with
Batik-1.1 RC2?
> You appear to have trimmed the stack traces...
>
> GA> org.apache.batik.svggen.SVGGraphics2D.getTopLevelGroup(SVGGraphics2D.java:373)
>
> Who is calling this???
Sorry, here's a more complete stack trace.
2001-09-13 01:04:51 - Ctx( /annotate ): Exception in: R( /annotate +
/servlet/Submit + null) - java.lang.ArrayIndexOutOfBoundsException: 7 >=
7
at java.util.Vector.elementAt(Vector.java:417)
at
org.apache.batik.svggen.DOMTreeManager.appendGroup(DOMTreeManager.java:160)
at
org.apache.batik.svggen.DOMGroupManager.addElement(DOMGroupManager.java:151)
at
org.apache.batik.svggen.SVGGraphics2D.fill(SVGGraphics2D.java:1019)
at
edu.rutgers.bioinf.annotate.SequenceRenderer.drawObject(SequenceRenderer.java:140)
at
edu.rutgers.bioinf.annotate.SequenceRenderer.render(SequenceRenderer.java:73)
at
edu.rutgers.bioinf.annotate.Submit.processSequences(Submit.java:184)
at edu.rutgers.bioinf.annotate.Submit.submitJob(Submit.java:143)
at edu.rutgers.bioinf.annotate.Submit.doPost(Submit.java:48)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:760)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at
org.apache.tomcat.core.ServletWrapper.doService(ServletWrapper.java:404)
at org.apache.tomcat.core.Handler.service(Handler.java:286)
at
org.apache.tomcat.core.ServletWrapper.service(ServletWrapper.java:372)
at
org.apache.tomcat.core.ContextManager.internalService(ContextManager.java:797)
at
org.apache.tomcat.core.ContextManager.service(ContextManager.java:743)
at
org.apache.tomcat.service.connector.Ajp12ConnectionHandler.processConnection(Ajp12ConnectionHandler.java:166)
at
org.apache.tomcat.service.TcpWorkerThread.runIt(PoolTcpEndpoint.java:416)
at
org.apache.tomcat.util.ThreadPool$ControlRunnable.run(ThreadPool.java:498)
at java.lang.Thread.run(Thread.java:484)
Some more context: I'm trying to get access to the DOM nodes that are
created by SVGGraphics2D. I'm doing this in the fashion of
SwingSVGPrettyPrint, as was suggested on the batik-users list. Here's
what I'm doing, boiled down to essentials:
// my pre-existing SVGGraphics2D, that I wish to paint on
SVGGraphics2D g = ...;
// create a copy of this SVG
SVGGraphics2D g2 = (SVGGraphics2D) g.create();
// prune existing top level group
Element origTopLevelGroup = g2.getTopLevelGroup();
// do my drawing
g2.fill(shape);
// prune this top level group with our drawing off
Element drawGroup = g2.getTopLevelGroup();
// set an id, so we can refer back to it later if desired
String id =
g.getGeneratorContext().getIDGenerator().generateID(name);
drawGroup.setAttributeNS(null, "id", id);
// splice our node back in
origTopLevelGroup.appendChild(drawGroup);
g.setTopLevelGroup(origTopLevelGroup);
I don't entirely comprehend what's going on in SwingSVGPrettyPrint,
but my understanding is that you essentially create a clean slate (a
new <g> tag) with the first call to getTopLevelGroup. Then you do
your drawing. Then you call getTopLevelGroup again, and you now have
access to the <g> that contains your recent drawing. Then you can
set attributes on this <g>, and splice it back into the DOM tree. Is
this accurate? (Suggestions on cleaner ways to get access to the nodes
are welcome...)
> 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
Actually it's being called from a Servlet so there are certainly
multiple threads in play, but a new SVGGraphics2D is created for each
doPost/doGet, and I do all my painting serially from that thread. I'm
not doing any painting in response to GUI/Swing events.
> It appears that this patch is attempting to make the SVGGen
> classes at least partially thread safe. This is essentially a
> hopeless cause (as the entire DOM tree implementation would have to
> be made thread safe to really solve the problem).
Ok, I agree that the patch is not the best solution. But to the best
of my knowledge my code is manipulating the DOM serially, so I'm not
sure where to look for the real problem. Perhaps someone can comment
on whether my manipulations with getTopLevelGroup are really ok or
not.
> I don't think this is the answer you are looking for but I hope it
> helps anyway.
Yes, any enlightenment is always helpful. :-) Thank you.
--
George Armhold
Rutgers University
Bioinformatics Initiative
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
