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?]


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?


Jake

>






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

Reply via email to:

Powered by MHonArc.

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