ObjectWeb Consortium
Search ObjectWeb Mail Archive: 

Advanced Search - Powered by Google

Mail Archive Home | xmlc List | September 2006 Index

<--  Date Index  --> <--  Thread Index  -->

Re: [xmlc] Re: [enhydra] java.lang.StackOverflowError (on too many 'else if' statements) [SOLVED?]

Ok, Here's pretty much the final code (though I have to take care of a couple other code paths related to these changes before I check in). I decided to leave it in the generated class because the substring code is obtained from the ElementInfo class, which is part of the org.enhydra.xmlc.compiler package and it just doesn't seem right to add a dependency like that to the XMLObjectImpl class. It probably wouldn't do much harm since it's all in the same jar, but I just feel the compiler really should be separated from the runtime stuff. Anyway, here's the code...

     * Called Recursively to set access method fields from the DOM.
     * Missing Ids have fields set to null.
    protected void syncWithDocument(Node node) {
        if (node.getNodeType() != Node.ELEMENT_NODE) return;
        if (!((Element)node).hasAttribute("id")) return;
        String id = ((Element)node).getAttribute("id");
        if (id.trim().length() == 0) return;
String fName = "$element_" + id.substring(0, 1).toUpperCase() + id.substring(1);
        try {
java.lang.reflect.Field f = this.getClass().getDeclaredField(fName);
            f.set(this, node);
        } catch (NoSuchFieldException nsfe) {
        } catch (Exception e) {
throw new org.enhydra.xml.xmlc.XMLCRuntimeException("Error reflecting on element access fields", e);

Anyone see a problem here?  Any optimizations?

BTW, Petr, It turns out that the substring code works just fine for single character Id's and I just added a test for empty string Id's the line before I attempt the substring stuff. I simply return if the Id value is empty. It all works quite nicely.


At 11:57 AM 9/7/2006, you wrote:
>Quoting Petr Stehlik <pstehlik@xxxxxxxxxx>:
>> Jacob Kjome wrote:
>> >         String id = ((Element)node).getAttribute("id");
>> >         String fName = "$element_" + id.substring(0, 1).toUpperCase() +
>> > id.substring(1);
>> >         try {
>> >                 Field f = this.getClass().getDeclaredField(fName);
>> >                 f.setAccessible(true);
>> >                 f.set(this, node);
>> >         } catch (Exception e) {}
>> > }
>> > This is the simplest, most succinct, solution I can come up with and it
>> > doesn't require modifying interfaces.  Anyway, comments welcome.
>> I'd just say that simplest solutions tend to be the best ones and if
>> this fixes the StackOverflowError then go for it.
>> Petr
>> P.S. final code should handle id.length < 2 :-)
>I'll have to test when I get home with Id values of "" and "a".  The old code
>specifically checked for an empty string, and I have to assume (will verify)
>that the code generator wouldn't generate methods for an Id with an empty
>string anyway.  I'm not sure about the single character Id, though?  The
>substring code I'm using was pulled directly from the existing method that
>creates the field names, so it seems to me that specifying an Id with a single >character would cause a failure in XMLC code generation. That might very well
>be a bug that needs addressing.  We'll see when I get home.
>Do you have an opinion on the exception handling?  I'm thinking this...
>} catch (NoSuchFieldException nsfe) {
>  //Squash, since if the field was not generated there
>  //was probably a reason, or at least the bug is in
>  //code generation. No use in exploding here.
>} catch (Exception e) {
>  //Let the rest fly since there's nothing we can do
>  //recover.  Need to wrap exception since at least
>  //IllegalAccessException is a checked exception.
>  throw new XMLCRuntimeException(e);
>As far as SecurityException - which can come from either the call to
>class.getDeclaredField(String) or the call to field.setAccessible(boolean) - it
>could be entirely avoided (I believe) if we continue to generate code in the
>generated XMLC class itself.  Because then the field will certainly pass both
>"checkMemberAccess" and "checkPackageAccess", given that the reflection would
>be happening in the same class where the member field exists.  This also
>removes the necessity for calling field.setAccessible(boolean), removing the
>possibility for failing on the SecurityManager's "suppressAccessChecks".
>The alternative, and maybe more clean way to do this, is to hide this
>logic as a
>private method inside XMLObject.  The downside is that we chance a
>SecurityException because, even if we use field.setAccessible(true), the
>Security manager could disallow access on either getting the declared field or
>setting accessibility.
>Given the amount of reflection that web frameworks like Struts use without
>apparent issue, I'm not sure if worrying about avoiding possible
>SecurityExceptions is much of a high priority?  Do the benefits of
>encapsulating this code in XMLObject outweigh the negative of possible
>SecurityExceptions when run with the SecurityManager enabled?  Thoughts?
>You receive this message as a subscriber of the xmlc@xxxxxxxxxxxxx
>mailing list.
>To unsubscribe: mailto:xmlc-unsubscribe@xxxxxxxxxxxxx
>For general help: mailto:sympa@xxxxxxxxxxxxx?subject=help
>ObjectWeb mailing lists service home page: http://www.objectweb.org/wws

<--  Date Index  --> <--  Thread Index  -->

Reply via email to:

Powered by MHonArc.

Copyright © 1999-2005, ObjectWeb Consortium | contact | webmaster.