java.lang.NoSuchMethodError old DC version?

[Former Member]

Hi folks,

we are facing a strange problem with a web dynpro java project. we are using DCs, there are two DCs involved, rested in two different SCs.

There is a "common" DC which contains basic classes, and a "ui" DC of type WebDynpro. ui uses common, has used DC reference on API and LIB.

at the beginning we defined some classes in common, and it all went fine. After a while I wanted to add a private field to a Class and public getter and setter. When I use the class in the ui DC (calling getter method) it results in a NoSuchMethodError during runtime:

java.lang.NoSuchMethodError: com.minol.mares.common.to.KeyValueTO.isShowPar14PopUp()Z

showPar14PopUp is the field name

when accessing the field directly (changed it to public) I am given a java.lang.NoSuchFieldError: showPar14PopUp

A strange Detail is the "Z" which is there probably accidentally maybe theres a bug, never saw it. its always coming with a "Z"

The local eclipse build and the DC build run without complications. I undeployed the web dynpro Application, deleted and added the used DCS, I checked and decompiled the deployed archive (ear and containing jar). I restarted the WebAS, let it run on two different machines...

It behaves just as if the DC is locally built but not used at runtime

probably it still uses the "old" DC version but how can i be sure of that, and how to make it use the new one?

using WebAS 2004 SP19

thanks for suggestions

Stefan

PS: this is a decent prob don't try sending me help.sap links

[Former Member]

Hi Stefan,

the final Z is not an error but a standard java name-mangling rule that stand for a boolean return value (name mangling is a way for Java to encode the name of the method, it's parameters and return value in the same place).

About your problem, how did you delcarethe dependencies? did you use an 'assembly' or a 'compile' public part? I think you have to use both.

BR

[Former Member]

thanks for the info, didn't see that in the javadoc.

Well honestly I forgot to update this thread. I solved the issue.

It was a class loading problem as expected. The Web Dynpro component itself used another web dynpro component. The other WDJ also used the common lib. so the classloader loaded the "common.jar" which was packed in the used WDJ component and did not use the other (correct) common.jar.

The only thing Ihad to do was rebuild and deploy the used WDJ component

regards

stefan