verschiedene Beans, verschiedene Felder "koppeln"

[faetzminator]

Hi zusammen,

der Threadtitel ist wohl nicht so aussagekräftig, ist mir aber nichts gescheiteres eingefallen.
Ich habe folgende Situation: Ich hab ein Projekt mit generierten Beans und Actions - nennen wir diese GenBeans. Diese leiten alle von einer Klasse ab, nennen wir sie CommonBean. Die GenBeans können für bestimmte Use Cases wiederum von mehreren Klassen reused werden (auch über mehr als ein Vererbungslevel), nennen wir diese ImplBeans.
Ich hab bei 90% der Services, welche ich mit diesen Beans befülle, zwei Felder, welche in all diesen Services gleichnamig sind. Als Beispiel nennen wir ein Feld "ABC". Nun habe ich dank langjähriger Programmierung div. Entwickler folgendes Problem. Der alte Generator generierte die Fields, wie sie im Service definiert wurden, also z.B. Feld "ABC" mit "getABC()" und "setABC()". Die neue Version spuckt aber alles Lower Case (wer kam auf diesen Schwachsinn?) aus, also "abc", "getAbc()", "setAbc()". Damit der Wert im gesamten Projekt rumgereicht werden kann, haben einige Entwickler je nach dem noch 2 ähnliche Methoden hinzugefügt (zu den ImplBeans). Je nach dem zeigen diese wieder auf den Getter/Setter von Feld x, y, oder verwenden ihr eigenes Feld.
Lange Rede, kurzer Sinn: ich will, egal welche von CommonBean vererbten Klassen welche Setter und Getter überschreiben (oder selbst erstellen) - welche diesem Muster ensprechen, also 4 Stück - immer auf das gleiche Feld zugegriffen wird. Somit soll ein "setABC()" vor einem "getabc()" den dem Setter übergebenen Wert zurückgeben.

- in CommonBean alle Methoden implementieren und das gleiche Feld verwenden - funktioniert natürlich nicht
- in allen ImplBeans alle diese Methoden implementieren - macht weder Sinn noch kann man davon ausgehen, dass immer ein ImplBean unter dem GenBean hängt
- im CommonBean Konstruktor die Methoden per Reflection überschreiben, das geht aber IMHO nicht
- im CommonBean alle Methoden implemenentieren, da drin per Reflection in allen Subklassen nach den Feldern suchen, bei den Settern alle Felder füllen, bei den Gettern ein Feld mit Inhalt zurückgeben. Als Fallback - wenn kein Feld gefunden wurde - das eigene verwenden. Dies könnte IMHO aber vom SecurityManager gesperrt sein, denn ich müsste ein [c]setAccessible(true)[/c] machen.
- CommonBean is irgendwann mal eine Ableitung von org.apache.struts.validator.ValidatorForm (Struts 1.1...) - kann man da was machen?
- im Framework schauen (wie erwähnt, basiert auf Struts 1.1), ob ich irgendwie die Instanzierungsmethode der Beans überschreiben kann, welche dann die Methoden ohne Reflection implementiert/überschreibt - das hab ich aber bis anhin noch nicht geschafft.

Einige fragen sich vielleicht, warum ich das so machen will. 1. Natürlich will ich zumindest die von Hand eingefügten Getter und Setter raus aus dem Projekt haben, aber das benötigt seine Zeit. Damit alles immer sauber funktioniert, sollen diese bis zum Abschluss meiner Änderungen verfügbar sein. 2. Diese verfi***en Generatoren, welche plötzlich alles Lower Case generieren. Ich kann leider nicht das ganze Projekt neu generieren...

Ich hab mir die Überlegungen schon ein paar Mal gemacht, bin allerdings nie zu einer Lösung gekommen. Kann sein, dass es wirklich keine Lösung gibt. Vielleicht gibts aber eine schöne Lösung, welche mir nicht einfällt? Oder eine fancy Lösung 🙂 Bin offen für alles 😀

Gruess, faetzminator

 

[maki]

Mal meine Gedanken ohne wirklich tief eingestiegen zu sein:
- struts 1.1 ist mittlerweile fast 10 Jahre alt, es handelt sich wohl um eine Uralt Legacy App, kein Vernünftiger Mensch würde das heute noch für Neuentwicklungen nutzen
- Project Lombok erstellt JavaBeans konforme Getter & Setter per Annotation automatisch zur Laufzeit (vorausgesetzt die Properties sind schon JavaBean konform), keine Generatoren mehr, keine handgeschriebenen Getter & Setter mehr

Manchmal bleibt einem nur die Wahl zwischen:
1. Mutig sein und große Teile neu implementieren, dazu braucht man aber mehr als Mut, u.a. auch Budget
2. Weitermachen und nicht Ärgern, marginale Verbesserungen einführen, oft nicht mehr als ein altes, rostiges Auto zu polieren, und vor allem: nicht ärger/aufregen

 

[faetzminator]

- struts 1.1 ist mittlerweile fast 10 Jahre alt, es handelt sich wohl um eine Uralt Legacy App, kein Vernünftiger Mensch würde das heute noch für Neuentwicklungen nutzen

Ich weiss. Ich hab nie gesagt, dass ich damit Freude hab. Genau so wenig, dass es ein neues Projekt ist. Unsere neue Projekte implementieren wir in Spring. Das interne Framework ist nicht grundlos seit 5 Jahren (?) deprecated 😉

- Project Lombok erstellt JavaBeans konforme Getter & Setter per Annotation [...]

Solch eine grosse Änderung sollte es dann auch wieder nicht sein.

Manchmal bleibt einem nur die Wahl zwischen:

1. Mutig sein und große Teile neu implementieren, dazu braucht man aber mehr als Mut, u.a. auch Budget

Ich bin seit 2 Jahren dran, Teil für Teil zu "verschönern". Dies ist in meinen Augen einer der letzten Teile, welche ich unbedingt schöner implementieren will. Ich hab allerdings nicht Tage, Wochen Zeit dazu - schön wie du das am Schluss des Satzes gesagt hast.

2. Weitermachen und nicht Ärgern, marginale Verbesserungen einführen, oft nicht mehr als ein altes, rostiges Auto zu polieren, und vor allem: nicht ärger/aufregen

Schlussendlich ist der Aufwand kleiner, wenn ich es gleich so implementiere, wie es mir vorschwebt. Die Alternative dazu ist, bei jeder Anpassung/Änderung von Services alle Felder wieder und wieder zu checken - denn die immensen Abhängigkeiten sind ein Problem.

 

[faetzminator]

Ich versuche nun, bei der Erstellung der Beans (von Struts) diese Methoden zu überladen. Leider hab ich es noch nicht geschafft, da die Klassen über einen CL geladen werden. Hab bis jetzt keine sinnvolle Möglichkeit gefunden.
Vielleicht bietet BCEL eine Lösung für mich? Es müsste einfach zur Compiletime die von mir benötigten Klassen erstellen und ebenfalls ins WAR packen. Allerdings scheiter ich da an den einfachsten Dingen.
Sonst noch irgendwelche Vorschläge?