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@xmlg...
For additional commands, e-mail: batik-users-help@xmlg...