You are viewing a plain text version of this content. The canonical link for it is here.
Posted to batik-users@xmlgraphics.apache.org by Maik Schürer <Ma...@proveo.de> on 2005/03/16 10:40:28 UTC
irregular DOMException
Hi there,
since I have added update my canvas via getUpdateManager/invokeLater, I
get irregular DOMExceptions like that:
org.w3c.dom.DOMException: file:...test.svg:
The attribute "style" represents an invalid CSS declaration
("fill:rgb(0,0,255);stroke:rgb(0,0,0);stroke-width:1").
Original message:
at org.apache.batik.css.engine.CSSEngine.getCascadedStyleMap(Unknown Source)
...
The line/style, which is criticized, is always different and I think my
test.svg is ok.
When I remove getUpdateManager/invokeLater, no error panel appears.
(But also my changes doesn't appears immediately ;-) )
Any ideas ? What did I wrong ?
Maik
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: irregular DOMException
Posted by Maik Schürer <Ma...@proveo.de>.
Thanks Thomas,
is it possible to check, if UpdateManager has something in his queue ?
Then I can suppress unnecessary invokeLater() calls.
I will do some test with RunnableQueue.iterator()... or is
UpdateManager.isRunning() suitable for me ?
Maik
Thomas DeWeese schrieb:
> Maik Schürer wrote:
>
>>> a e.printStackTrace() to line 773 in CSSEngine.java.
>>
>>
>> Maybe your source code is different
>
>
> Yes, I'm working off CVS, but I took a look at the 1.5.1
> code I am now essentially 100% convinced that you have multiple
> threads touching the DOM.
>
>
>> java.lang.NullPointerException
>> at [...]CSSEngine.putAuthorProperty(CSSEngine.java:1222)
>
>
> For this to happen 'dest' must be null. In the
> 'StyleDeclarationDocumentHandler.property' function:
>
>> at
>> [...]CSSEngine$StyleDeclarationDocumentHandler.property(CSSEngine.java:1408)
>
>
>
> The styleMap data member is passed in. Note that the
> CSSEngine uses one StyleDeclarationDocumentHandler instance
> to parse all 'style' attributes.
>
> Skipping a few stack frames we come to:
>
>> [...].getCascadedStyleMap(CSSEngine.java:782)
>
>
> The code around this exception is:
>
> 779: styleDeclarationDocumentHandler.styleMap = result;
> 780: parser.setDocumentHandler
> 781: (styleDeclarationDocumentHandler);
> 782: parser.parseStyleDeclaration(style);
> 783: styleDeclarationDocumentHandler.styleMap = null;
>
> I'm fairly certain that what you are seeing is that
> some time after thread 1 passes line 779 it get's interrupted
> (probably during parsing) and thread 2 takes over and also
> goes through 779 setting styleMap to it's result, finishes
> parsing and reset's styleMap to 'null' at line 783.
>
> This is really the only way I can see this could happen.
>
>> > Is the top of the stack trace always the updateManager
>> > runnableQueue?
>> Yes, it seems so.
>>
>> Did I use the UpdateManager wrong ?
>
>
> The real question is how to track down who/how this is happening.
> The approach I would use would be to add:
>
> new Error("Setting 'styleMap'").printStackTrace();
>
> Whenever the styleMap is set on the style declaration handler.
> This will spew lots and lots of output but with it you can
> tell exactly what the sequence is and if any other threads are
> getting into the CSSEngine.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: irregular DOMException
Posted by Thomas DeWeese <Th...@Kodak.com>.
Hi Maik,
Maik Schürer wrote:
> where should I add
> new Error("Setting 'styleMap'").printStackTrace();
> ?
> at begin of method getCascadedStyleMap() ?
Anywhere you think is useful, but I would start with
every place the style handler's styleMap is set and
cleared (use "Clearing 'styleMap'" for the clear case
of course).
This will let you see the actual interplay of set/clear
and the threads involved (if it is too much info you
could also just print the thread instance but you will need
to have a way to map those thread instances back to
your code).
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: irregular DOMException
Posted by Maik Schürer <Ma...@proveo.de>.
where should I add
new Error("Setting 'styleMap'").printStackTrace();
?
at begin of method getCascadedStyleMap() ?
Maik
Thomas DeWeese schrieb:
> Maik Schürer wrote:
>
>>> a e.printStackTrace() to line 773 in CSSEngine.java.
>>
>>
>> Maybe your source code is different
>
>
> Yes, I'm working off CVS, but I took a look at the 1.5.1
> code I am now essentially 100% convinced that you have multiple
> threads touching the DOM.
>
>
>> java.lang.NullPointerException
>> at [...]CSSEngine.putAuthorProperty(CSSEngine.java:1222)
>
>
> For this to happen 'dest' must be null. In the
> 'StyleDeclarationDocumentHandler.property' function:
>
>> at
>> [...]CSSEngine$StyleDeclarationDocumentHandler.property(CSSEngine.java:1408)
>
>
>
> The styleMap data member is passed in. Note that the
> CSSEngine uses one StyleDeclarationDocumentHandler instance
> to parse all 'style' attributes.
>
> Skipping a few stack frames we come to:
>
>> [...].getCascadedStyleMap(CSSEngine.java:782)
>
>
> The code around this exception is:
>
> 779: styleDeclarationDocumentHandler.styleMap = result;
> 780: parser.setDocumentHandler
> 781: (styleDeclarationDocumentHandler);
> 782: parser.parseStyleDeclaration(style);
> 783: styleDeclarationDocumentHandler.styleMap = null;
>
> I'm fairly certain that what you are seeing is that
> some time after thread 1 passes line 779 it get's interrupted
> (probably during parsing) and thread 2 takes over and also
> goes through 779 setting styleMap to it's result, finishes
> parsing and reset's styleMap to 'null' at line 783.
>
> This is really the only way I can see this could happen.
>
>> > Is the top of the stack trace always the updateManager
>> > runnableQueue?
>> Yes, it seems so.
>>
>> Did I use the UpdateManager wrong ?
>
>
> The real question is how to track down who/how this is happening.
> The approach I would use would be to add:
>
> new Error("Setting 'styleMap'").printStackTrace();
>
> Whenever the styleMap is set on the style declaration handler.
> This will spew lots and lots of output but with it you can
> tell exactly what the sequence is and if any other threads are
> getting into the CSSEngine.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: irregular DOMException
Posted by Thomas DeWeese <Th...@Kodak.com>.
Maik Schürer wrote:
>> a e.printStackTrace() to line 773 in CSSEngine.java.
>
> Maybe your source code is different
Yes, I'm working off CVS, but I took a look at the 1.5.1
code I am now essentially 100% convinced that you have multiple
threads touching the DOM.
> java.lang.NullPointerException
> at [...]CSSEngine.putAuthorProperty(CSSEngine.java:1222)
For this to happen 'dest' must be null. In the
'StyleDeclarationDocumentHandler.property' function:
> at [...]CSSEngine$StyleDeclarationDocumentHandler.property(CSSEngine.java:1408)
The styleMap data member is passed in. Note that the
CSSEngine uses one StyleDeclarationDocumentHandler instance
to parse all 'style' attributes.
Skipping a few stack frames we come to:
> [...].getCascadedStyleMap(CSSEngine.java:782)
The code around this exception is:
779: styleDeclarationDocumentHandler.styleMap = result;
780: parser.setDocumentHandler
781: (styleDeclarationDocumentHandler);
782: parser.parseStyleDeclaration(style);
783: styleDeclarationDocumentHandler.styleMap = null;
I'm fairly certain that what you are seeing is that
some time after thread 1 passes line 779 it get's interrupted
(probably during parsing) and thread 2 takes over and also
goes through 779 setting styleMap to it's result, finishes
parsing and reset's styleMap to 'null' at line 783.
This is really the only way I can see this could happen.
> > Is the top of the stack trace always the updateManager
> > runnableQueue?
> Yes, it seems so.
>
> Did I use the UpdateManager wrong ?
The real question is how to track down who/how this is happening.
The approach I would use would be to add:
new Error("Setting 'styleMap'").printStackTrace();
Whenever the styleMap is set on the style declaration handler.
This will spew lots and lots of output but with it you can
tell exactly what the sequence is and if any other threads are
getting into the CSSEngine.
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: irregular DOMException
Posted by Maik Schürer <Ma...@proveo.de>.
Hi Thomas,
> I don't really know what your problem is...
My problem is the appearing batik error panel ;-)
> a e.printStackTrace() to line 773 in CSSEngine.java.
Maybe your source code is different, my line 773 in CSSEngine.java from
http://apache.engram.de/apache.org/xml/batik/batik-src-1.5.1.zip
is
String style = elt.getAttributeNS(styleNamespaceURI, ...
there does not appear the exception, but a little bit later
My appearing exception is the DOMException catched in line 784.
The full stack trace is:
java.lang.NullPointerException
at
org.apache.batik.css.engine.CSSEngine.putAuthorProperty(CSSEngine.java:1222)
at
org.apache.batik.css.engine.CSSEngine$StyleDeclarationDocumentHandler.property(CSSEngine.java:1408)
at
org.apache.batik.css.parser.Parser.parseStyleDeclaration(Parser.java:910)
at
org.apache.batik.css.parser.Parser.parseStyleDeclarationInternal(Parser.java:301)
at
org.apache.batik.css.parser.Parser.parseStyleDeclaration(Parser.java:1711)
at
org.apache.batik.css.engine.CSSEngine.getCascadedStyleMap(CSSEngine.java:782)
at
org.apache.batik.css.engine.CSSEngine.invalidateProperties(CSSEngine.java:1941)
at
org.apache.batik.css.engine.CSSEngine.propagateChanges(CSSEngine.java:2086)
at
org.apache.batik.css.engine.CSSEngine.invalidateProperties(CSSEngine.java:1981)
at
org.apache.batik.css.engine.CSSEngine.propagateChanges(CSSEngine.java:2086)
at
org.apache.batik.css.engine.CSSEngine.invalidateProperties(CSSEngine.java:1981)
at
org.apache.batik.css.engine.CSSEngine.inlineStyleAttributeUpdated(CSSEngine.java:1880)
at
org.apache.batik.css.engine.CSSEngine$DOMAttrModifiedListener.handleEvent(CSSEngine.java:2349)
at
org.apache.batik.dom.events.EventSupport.fireEventListeners(EventSupport.java:268)
at
org.apache.batik.dom.events.EventSupport.dispatchEvent(EventSupport.java:240)
at org.apache.batik.dom.AbstractNode.dispatchEvent(AbstractNode.java:455)
at
org.apache.batik.dom.AbstractElement.fireDOMAttrModifiedEvent(AbstractElement.java:547)
at org.apache.batik.dom.AbstractAttr.setNodeValue(AbstractAttr.java:175)
at org.apache.batik.dom.AbstractAttr.setValue(AbstractAttr.java:218)
at
org.apache.batik.dom.AbstractElement.setAttributeNS(AbstractElement.java:276)
at
org.apache.batik.dom.svg.SVGStylableElement$StyleDeclaration.propertyChanged(SVGStylableElement.java:707)
at
org.apache.batik.css.dom.CSSOMStyleDeclaration.setProperty(CSSOMStyleDeclaration.java:189)
at de.proveo.wwt.gui.svgmap.unit.SVGUnit.show(SVGUnit.java:299)
at de.proveo.wwt.gui.svgmap.panels.SVGMapPanel$1.run(SVGMapPanel.java:336)
at org.apache.batik.util.RunnableQueue.run(RunnableQueue.java:207)
at java.lang.Thread.run(Thread.java:536)
> Is the top of the stack trace always the updateManager
> runnableQueue?
Yes, it seems so.
Did I use the UpdateManager wrong ?
Maik
Thomas DeWeese schrieb:
> Hi Maik,
>
> I don't really know what your problem is, I haven't encountered
> anything like this in my experience. My first guess is that some of
> your old code is still not using the update manager/invoke later
> to make changes to the DOM.
>
> You might get a clearer picture of what is going wrong by adding
> a e.printStackTrace() to line 773 in CSSEngine.java.
>
> Is the top of the stack trace always the updateManager
> runnableQueue?
>
> Maik Schürer wrote:
>
>> since I have added update my canvas via getUpdateManager/invokeLater,
>> I get irregular DOMExceptions like that:
>> org.w3c.dom.DOMException: file:...test.svg:
>> The attribute "style" represents an invalid CSS declaration
>> ("fill:rgb(0,0,255);stroke:rgb(0,0,0);stroke-width:1").
>> Original message:
>> at org.apache.batik.css.engine.CSSEngine.getCascadedStyleMap(Unknown
>> Source)
>> ...
>>
>> The line/style, which is criticized, is always different and I think
>> my test.svg is ok.
>>
>> When I remove getUpdateManager/invokeLater, no error panel appears.
>> (But also my changes doesn't appears immediately ;-) )
>> Any ideas ? What did I wrong ?
>> Maik
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
>> For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: irregular DOMException
Posted by Thomas DeWeese <Th...@Kodak.com>.
Hi Maik,
I don't really know what your problem is, I haven't encountered
anything like this in my experience. My first guess is that some of
your old code is still not using the update manager/invoke later
to make changes to the DOM.
You might get a clearer picture of what is going wrong by adding
a e.printStackTrace() to line 773 in CSSEngine.java.
Is the top of the stack trace always the updateManager
runnableQueue?
Maik Schürer wrote:
> since I have added update my canvas via getUpdateManager/invokeLater, I
> get irregular DOMExceptions like that:
> org.w3c.dom.DOMException: file:...test.svg:
> The attribute "style" represents an invalid CSS declaration
> ("fill:rgb(0,0,255);stroke:rgb(0,0,0);stroke-width:1").
> Original message:
> at org.apache.batik.css.engine.CSSEngine.getCascadedStyleMap(Unknown
> Source)
> ...
>
> The line/style, which is criticized, is always different and I think my
> test.svg is ok.
>
> When I remove getUpdateManager/invokeLater, no error panel appears.
> (But also my changes doesn't appears immediately ;-) )
> Any ideas ? What did I wrong ?
> Maik
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org