xmlgraphics-batik-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From jonathan wood <jonathanshaww...@gmail.com>
Subject Re: Batik and JUnit
Date Wed, 15 Dec 2010 18:35:50 GMT
Without some context (code snippet, svg sample, etc), I'm a bit limited in
the help I can offer.

I've seen odd behavior like this in 2 cases...Yours may not fall into either
since it works outside the unit test, but it's worth a shot.

1) The document is tampered with before SVG/GVT are fully initialized.
Using the following eliminates the need for sleep/check routines for a
loaded doc.  Note the comments indicating proper/improper places to begin
document modification.

     Example:

        svgCanvas.setDocumentState(JSVGCanvas.ALWAYS_DYNAMIC);
        svgCanvas.addGVTTreeBuilderListener(new GVTTreeBuilderAdapter() {
            @Override
            public void gvtBuildCompleted(GVTTreeBuilderEvent e) {
                 //MODIFY DOCUMENT HERE
            }
        });

        InputStream templateStream =
Canvas.class.getResourceAsStream("mydoc.svg");
        String parser = XMLResourceDescriptor.getXMLParserClassName();
        SAXSVGDocumentFactory f = new SAXSVGDocumentFactory(parser);
        SVGDocument doc = null;

        try {
            doc = f.createSVGDocument(null, templateStream);
        } catch (IOException ex) {
            Logger.getLogger(Canvas.class.getName()).log(Level.SEVERE, null,
ex);
        } finally {
            if(templateStream != null) {
                try {
                    templateStream.close();
                } catch (IOException ex) {
                    logger.log(Level.WARNING, null, ex);
                }
            }
        }
        doc.setDocumentURI("myuri");
        // DON'T MODIFY DOCUMENT HERE


2) Modification of the document (add/remove/update any svg node) outside of
the UpdateRunnableQueue.  All modifications should be wrapped..

getUpdateManager().getUpdateRunnableQueue().invokeLater(new Runnable() {
    @Override
     public void run() {
       // MODIFY DOCUMENT HERE
     }
});


feel free to share more info if your issue persists.


On Wed, Dec 15, 2010 at 11:01 AM, Martin Gainty <mgainty@hotmail.com> wrote:

>  Hello Jonathan
>
> from what i've seen the invocation of the JFCUnit tests are producing the
> abending lll attribute causing the offense
> It looks as if you'll need some session-management to determine who the
> culprit is here is an example:
>
> execute JFCUnit-Test-Session1:
> bash>grep --files-with-matches --recursive attribute
>   JFCUnit produces attributes fu
>
> execute JFCUnit-Test-Session2:
> bash>grep --files-with-matches --recursive attribute
>    JFCUnit produces attributes fubar
>
> execute JFCUnit-Test-Session3:
> bash>grep --files-with-matches --recursive attribute
>    JFCUnit produces attributes lll
>
> Martin Gainty
> ______________________________________________
> Jogi és Bizalmassági kinyilatkoztatás/Verzicht und
> Vertraulichkeitanmerkung/Note de déni et de confidentialité
>
> Ez az üzenet bizalmas.  Ha nem ön az akinek szánva volt, akkor kérjük, hogy
> jelentse azt nekünk vissza. Semmiféle továbbítása vagy másolatának készítése
> nem megengedett.  Ez az üzenet csak ismeret cserét szolgál és semmiféle jogi
> alkalmazhatósága sincs.  Mivel az electronikus üzenetek könnyen
> megváltoztathatóak, ezért minket semmi felelöség nem terhelhet ezen üzenet
> tartalma miatt.
>
> Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene
> Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte
> Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht
> dient lediglich dem Austausch von Informationen und entfaltet keine
> rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von
> E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen.
>
> Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le destinataire
prévu, nous te demandons avec bonté que pour satisfaire informez l'expéditeur. N'importe
quelle diffusion non autorisée ou la copie de ceci est interdite. Ce message sert à l'information
seulement et n'aura pas n'importe quel effet légalement obligatoire. Étant donné que les
email peuvent facilement être sujets à la manipulation, nous ne pouvons accepter aucune
responsabilité pour le contenu fourni.
>
>
>
>
>
>
> ------------------------------
> From: jonathanshawwood@gmail.com
> Date: Wed, 15 Dec 2010 10:35:49 -0500
> Subject: Re: Batik and JUnit
> To: batik-users@xmlgraphics.apache.org
>
>
> Can you share your initialization/document load routine and the handoff to
> junit?
>
> On Tue, Dec 14, 2010 at 1:50 PM, shootist <kwilson4813@gmail.com> wrote:
>
>
> I am attempting to run some unit tests under JFCUnit and JUnit.  I also
> have
> a recorder that uses java robot to perform some tests.
>
> Anytime I modify anything, or even sometimes just starting the code without
> running any actual tests I get svg errors.  Sometimes It's just a null,
> sometimes it tells me there is an invalid attribute (for example, I get an
> error message saying "lll" is not a valid attribute for "pointer-events"),
> and sometimes I get CSS exceptions.
>
> I don't see anyplace in the code where I set any attribute to lll, and I
> don't have any problems running the code.  This only happens within the
> unit
> tests.
>
> I suspect something strange is happening with threading, and the unit tests
> are not waiting for the UpdateManager to complete, but no amount of sleep
> calls seem to help.  Has anyone experienced these problems?
> --
> View this message in context:
> http://batik.2283329.n4.nabble.com/Batik-and-JUnit-tp3087741p3087741.html
> Sent from the Batik - Users mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
>
>
>

Mime
View raw message