Babel IT

Java software ontwikkeling

JAX-WS en Spring

Normaal laat je de dependencies door Spring injecteren. Maar hoe doe je dat met objecten die niet door Spring gemanaged worden? In het geval van JAX-WS endpoint klassen is dat ene probleem. Instanties van deze klassen worden gemaakt door de container. Spring biedt wel wat mogelijkheden. In WAS 7 werkt de super-klasse aanpak niet, omdat de Spring context nog niet geinitialiseerd is op het moment dat de instantie wordt aangemaakt. WAS 7 doet dat voordat de web applicatie zelf geinitialiseerd wordt gezamenlijk met de WebApplicationContext. Dat werkt dus niet.

Via een statische klasse die geïnjecteerd wordt door Spring kun je via een omweg alsnog aan de dependencies komen.

Maar, misschien dat de manier met AspectJ in combinatie met Spring 3.1.0 en WebSphere Load Time weaving wel gaat werken. Ik moet het nog verder uitzoeken.

In Glassfish met CDI zijn er blijkbaar ook problemen mee, geeft een kennis van mij aan. Het is blijkbaar allemaal niet zo simpel.

Zodra ik weer wat verder ben, komt er weer een berichtje over.

Update: Met de LTW lukt het ook niet. Ondanks dat de Endpoint klassen door de classloader worden geladen die door Spring is voorzien van LTW, is de endpoint klasse zo’n beetje de enige klasse die niet geweaved wordt. Allemaal heel raar, maar het is zo.

Uiteindelijk gekozen voor een oplossing waarbij de Endpoint klasse zo goed als leeg is. Alle functionaliteit wordt in een Delegate geprogrammeerd. Deze delegaten is een Spring managed klasse. Via een base klasse kan dit op een eenvoudige manier worden gerealiseerd met een minimum aan code in de Endpoint klasse. Het is niet de meest mooie oplossing, maar het werkt wel.

Clean code

Het boek Clean Code van Uncle Bob (Robert C. Martin) is interessant voor zowel ervaren als minder ervaren ontwikkelaars. Het boek richt zich vooral op het belang van goed onderhoudbare code. Uiteindelijk bevat de source code van een programma de waarheid over wat er uitgevoerd wordt. Alle andere documentatie, functionele en technische ontwerpen, architecturen, user stories, etc, bevatten geen uitvoerbare code. Ze hebben hun eigen waarde, maar uiteindelijke zegt de source code echt wat de machine doet. Het is daarom van essentieel belang deze source code goed op te zetten en te onderhouden. Het boek geeft een aantal zeer bruikbare tips om dat te doen.

Inkoppertje is natuurlijk de naamgeving van alle onderdelen van de code. Een goede naam is essentieel voor het begrip van de code. Beter lang nadenken over een goede naam, dan zomaar iets doen. Probeer maar eens code van een paar dagen geleden te lezen en te snappen wat er precies gebeurd. Als de namen niet kloppen, kost dat veel tijd.

Een aanbeveling uit het boek: code moet lezen als een boek. Je moet dus ook structureren als een boek. In geval van Java gebruik je klassen en methoden. Door onderscheid te maken in de verschillende niveau’s van abstractie, krijg je duidelijke hiërarchieën van elkaar aanroepende methoden en elkaar gebruikende klassen. Dit bedenk je niet op voorhand, ja misschien de grote structuren, maar de details komen pas later na een aantal iteraties en refactorings.

Ondanks mijn 15 jaar ervaring met software ontwikkeling, haal ik nog steeds nuttige tips uit het boek. De meeste dingen weet ik wel, maar pas als je er weer eens op gewezen wordt, ga je ze weer netjes toepassen. Het leidt uiteindelijk tot veel betere code en ook betere applicaties voor de eindgebruikers. En daar gaat het tenslotte om.

Nieuwe site

Ja, bij de schilder zit de verf er het slechtst op. Zo ook hier. Eindelijk na 5 jaar een nieuwe site. Nou ja, nieuwe look & feel. Aan de inhoud is nog niet zoveel veranderd. Nu de site is gebaseerd op WordPress zal dat een stuk eenvoudiger gaan. Ik doe mijn best.

Casper