Black Friday = Pricewatch Bekijk onze selectie van de beste Black Friday-deals en voorkom een miskoop.

[java] ClassFormatError: Repetitive method name/signature

Pagina: 1
Acties:

  • Standeman
  • Registratie: November 2000
  • Laatst online: 20:23

Standeman

Prutser 1e klasse

Topicstarter
Ik heb een heel vaag probleem waar ik helaas met google ook bijzonder weinig informatie kan vinden.

Ik ben bezig om met Spring, JSF en OpenJPA een webapplicatie te bouwen en tot nu toe ging dat aardig goed. Echter, krijg ik de volgende error wanneer OpenJPA de objecten gaat aanmaken.

code:
1
2
3
4
5
java.lang.ClassFormatError: Repetitive method name/signature in class file model/SecretKey
    at java.lang.ClassLoader.defineClass1(Native Method)
    at java.lang.ClassLoader.defineClass(ClassLoader.java:620)
    at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124)
etc..


Mijn object heb ik inmiddels helemaal gestript tot het onderstaande, maar de error blijft komen.
Java:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
/**
 * 
 */
package model;

import model.TMDataObject;

public class SecretKey extends TMDataObject {
    public Long secretKeyId;

    public SecretKey() {
    }

    public Long getSecretKeyId() {
        return secretKeyId;
    }

    public void setSecretKeyId(Long secretKeyId) {
        this.secretKeyId = secretKeyId;
    }
}


Ik heb de class file bekeken met een bytecode viewer, maar daar zie ik geen gekke dingen zoals dubbele method namen met dezelfde signature. Andere objecten die in de objectgraph voorkomen (en ook TMDataObject extenden) werken prima. Ik weet nu niet waar ik verder moet zoeken, dus als iemand een idee heeft?

[ Voor 4% gewijzigd door Standeman op 11-09-2008 10:42 ]

The ships hung in the sky in much the same way that bricks don’t.


  • Kwistnix
  • Registratie: Juni 2001
  • Laatst online: 22:56
Kan je het resultaat van javap hier posten, of kan die er ook geen kaas van maken?

  • den 150
  • Registratie: Oktober 2002
  • Niet online
Kan je de signatures van TMDataObject ook posten?
En mag die secretKeyId niet private, aangezien je getter/setter hebt?

  • Standeman
  • Registratie: November 2000
  • Laatst online: 20:23

Standeman

Prutser 1e klasse

Topicstarter
Ik heb net even TMDataObject ook er even uit gegooid, maar het probleem blijft.

javap roept:
Java:
1
2
3
4
5
6
7
Compiled from "SecretKey.java"
public class model.SecretKey extends java.lang.Object{
    private java.lang.Long secretKeyId;
    public model.SecretKey();
    public java.lang.Long getSecretKeyId();
    public void setSecretKeyId(java.lang.Long);
}
den 150 schreef op donderdag 11 september 2008 @ 12:24:
Kan je de signatures van TMDataObject ook posten?
En mag die secretKeyId niet private, aangezien je getter/setter hebt?
Ja, die mag private zijn, ik denk alleen niet dat het mijn probleem oplost ;)


Overigens, bedenk ik net dat de classes run-time enhanced worden met spring-agent load time weaver. Misschien dat daar ergens het probleem zit?

The ships hung in the sky in much the same way that bricks don’t.


  • Kwistnix
  • Registratie: Juni 2001
  • Laatst online: 22:56
Oh, ik bedoelde eigenlijk met de -c optie, zodat ie de byte code disassambled.
Daar moet het toch haast wel misgaan? Gebruik je toevallig een of andere obfuscator of een tool die byte code instrumentatie toepast voor code coverage ofzo?

Edit: Ja dus. Ik denk dat je het inderdaad daar moet zoeken, alleen gaan je met load time weaving dus niets vreemds zien aan de byte code, zoals je zelf ook al geverifieerd hebt.
Kan je niet een andere weaving aanpak (compile-time of post-compile) gebruiken die de byte code wel aanpast?

[ Voor 38% gewijzigd door Kwistnix op 11-09-2008 13:02 ]


  • Janoz
  • Registratie: Oktober 2000
  • Laatst online: 15-11 11:40

Janoz

Moderator Devschuur®

!litemod

Standeman schreef op donderdag 11 september 2008 @ 12:43:
Ja, die mag private zijn, ik denk alleen niet dat het mijn probleem oplost ;)
Assumptions are the mother of all fuckups :). Maak hem eens private?

De foutmelding gaat over dubbele method signatures en de enige methods zijn de getter en de setter. Ik zou me voor kunnen stellen dat bepaalde tooling bij een public field zelf getters en setters toe voegt zodat er een proxy object gebruikt kan worden.

Ken Thompson's famous line from V6 UNIX is equaly applicable to this post:
'You are not expected to understand this'


  • Standeman
  • Registratie: November 2000
  • Laatst online: 20:23

Standeman

Prutser 1e klasse

Topicstarter
Ik heb inmiddels die member private gemaakt en het blijft fout gaan.

Ik ga even kijken of de classes compile-time kan enhancen. Dat zou het 1 en ander wat meer duidelijk moeten moeten maken.

The ships hung in the sky in much the same way that bricks don’t.


  • Standeman
  • Registratie: November 2000
  • Laatst online: 20:23

Standeman

Prutser 1e klasse

Topicstarter
Aaaaargggghhhhhh |:( :X :(

Ik ben achter de oorzaal gekomen! Het blijkt dat ik klein foutje heb gemaakt in de ORM mapping file. De naam van de primary key begon met een uppercase S i.p.v. een lowercase s }:|

dus:
XML:
1
2
3
4
5
6
7
8
9
10
    <entity class="SecretKey">
        <table name="SECRET_KEY" />
        <attributes>
                      v
            <id name="SecretKeyId">
                      ^
                <column name="SECRET_KEY_ID" />
            </id>
        </attributes>
    </entity>

moet zijn:

XML:
1
2
3
...
            <id name="secretKeyId">
...


Heeft me slechts een uur of zes gekost om te vinden ;(

Ik denk dat ik 'm op JIRA ga zetten. Ik had toch een andere foutmelding verwacht in dit geval.

* Standeman kan gelukkig wel weer door *O*

[ Voor 3% gewijzigd door Standeman op 11-09-2008 16:44 ]

The ships hung in the sky in much the same way that bricks don’t.

Pagina: 1