[
http://jira.codehaus.org/browse/JIBX-239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dennis Sosnoski updated JIBX-239:
---------------------------------
Component/s: (was: Generator Tools)
core
> JiBX-instrumented classes can cause problems when adding other instrumentation
> ------------------------------------------------------------------------------
>
> Key: JIBX-239
> URL: http://jira.codehaus.org/browse/JIBX-239
> Project: JiBX
> Issue Type: Improvement
> Components: core
> Affects Versions: JiBX 1.1.6
> Reporter: Aaron Gaalswyk
> Assignee: Dennis Sosnoski
>
> When you instrument a class using a JiBX binding file and the JiBX binding
> compiler, the bytecode magic--presumably done mostly with bcel--includes
> adding a new method like JiBX_jibx_binding_unmarshal_1_0 (or for a named
> binding, "JiBX_[something]_unmarshal_1_0"). We ran into a problem wherein if
> that bytecode is further massaged by some other application, the resultant
> class throws a VerifyError when loaded, like this:
> Caused by: java.lang.VerifyError: (class: com/foo/jibx/SomethingRequest,
> method: JiBX_jibx_binding_unmarshal_1_0 signature:
> (Lorg/jibx/runtime/impl/UnmarshallingContext;)Lcom/foo/jibx/SomethingRequest;)
> Inconsistent stack height
> at java.lang.Class.getDeclaredFields0(Native Method)
> at java.lang.Class.privateGetDeclaredFields(Class.java(Compiled Code))
> at java.lang.Class.getDeclaredField(Class.java:1328)
> at
> org.jibx.runtime.BindingDirectory.getBindingList(BindingDirectory.java:77)
> at
> org.jibx.runtime.BindingDirectory.getFactory(BindingDirectory.java:211)
> at
> org.springframework.oxm.jibx.JibxMarshaller.afterPropertiesSet(JibxMarshaller.java:139)
> In our case, the second program to come along to update
> already-Jibx-instrumented bytecode was a Compuware Vantage Analyzer. The
> response from Compuware's engineers was:
> "These methods leave a non empty stack when returning to the caller. The JVM
> normally tolerates this condition and simply clears the current stack and
> reinstates the caller's stack frame. However, when this code is wrapped with
> try/catch/finally, it would result in a non empty stack at return time in
> normal execution and an empty stack at return time when an exception occurs.
> This is a violation of specification, hence the VerifyError."
> So, can something be done about these methods returning with a non-empty
> stack?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
jibx-devs mailing list
jibx-devs@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jibx-devs
