Labels: GR8, Grails, Groovy, Konferenz

¶ 13:34 0 comments

@Controller
public class KundeController {

  @RequestMapping
  public Kunde showForm() {
    return new Kunde("Wolff","Eberhard",42);
  }
}

<beans default-autowire="byType"
...>

  <bean id="orderService" class="....OrderServiceImpl" />
...

@Service
public class OrderServiceImpl implements OrderService {

  private CustomerRepository customerRepository;

  @Autowired
  public void setCustomerRepository(CustomerRepository customerRepository) {
    this.customerRepository = customerRepository;
  }
...
}

• Der PropertyOverrideConfigurer erlaubt es, bei beliebigen Spring-Beans beliebige Werte zu überschreiben. Das ist im allgemeinen zu mächtig. Man will meistens kontrollieren, welche Werte wo gesetzt werden können und auch sehen, womit die Werte überschrieben werden. Daher habe ich bisher in der Praxis eigentlich nur den PropertyPlaceholderConfigurer gesehen, der aber wesentlich expliziter und aufwändiger ist.


• Bei den Controllern kommt in Trainings oder Präsentationen oft die Frage, ob man nicht das Mapping zwischen URLs und Code irgendwo zentral im XML konfigurieren kann. Und das, obwohl die Mappings mittlerweile auch von den Tools gut unterstützt werden und man dadurch Übersichtlichkeit hat. Der Aufwand für eine explizite Angabe der URL, des View-Names und der Model-Namens sind auch nicht sehr groß:
  

  
  @Controller
  public class KundeController {
  
   @RequestMapping("/kunde")
   public Kunde showForm() {
    return new ModelAndView("kunde","kunde",new Kunde("Wolff","Eberhard",42));
   }
  

  
  


• Und Autowiring wird auch selten genutzt - das häufigste Gegenargument ist die mangelnde Übersicht, was genau wohin injiziert wird. Das ist vor allem spannend, weil in den meisten Fällen sowieso nur ein typ-kompatible Spring-Bean existiert, weil es eben nur eine Implementierung des Interfaces oder eine Instanz der Klasse gibt. Nur in Ausnahmefällen gibt es eine echte Wahl. Das bedeutet, dass die explizite Konfiguration nicht wesentliche Vorteile bringt - weil in den meisten Fällen sowieso klar ist, was wohin injiziert werden muss.

Labels: Convention over Configuration, Spring

¶ 09:50 4 comments

Labels: Jürgen Höller, Spring 3.0, Webinar

¶ 16:09 0 comments

Labels: Bundlor, ivy, Maven, OSGi

¶ 16:43 0 comments

• Pooling nimmt an, dass das Erzeugen und Zerstören von Objekten teuer ist - sonst könnte man sie ja jedesmal erzeugen und zerstören, statt sie zu poolen. Bei Objekten wie Datenbank-Verbindungen und Threads stimmt das auch nach wie vor. Aber Objekt-Erzeugung und Zerstörung einfacher Java-Objekte ist mittlerweile sehr billig. Kurzlebige Objekte sind praktisch umsonst. Die Hotspot-FAQ warnt sogar vor Pooling: http://java.sun.com/docs/hotspot/HotSpotFAQ.html#gc_pooling
Der Hintergrund ist die Speicherverwaltung von Java. Für ein neues Objekt holt Java sich bei den neueren VMs einfach nur einen neuen Speicherbereich in der Young Generation durch Erhöhen eines Pointers. Wenn die Young Generation voll ist, wird durch einen Copying Garbage Collector die überlebenden Objekte, auf die noch Referenzen existieren, umkopiert. Die Komplexität dieses Garbage Collectors hängt von der Anzahl überlebender Objetke ab. Kurzlebige Objekte bedeuten also nur, dass diese Garbage Collection öfter läuft, aber nicht, das sie länger dauert. Beim Pooling hingegen hat man langliebige Objekte, bei denen die Garbage Collection länger dauert, und durch das Ausgreifen aus dem Pool auch ein Overhead. Übrigens muss C++ bei der Objekt-Erzeugung den Heap nach einem passend großen Speicherplatz durchforsten. Das ist wesentlich komplexer als die Pointer-Manipulation bei Java. Ein Umkopieren der Objekte ist bei C++ nicht möglich und somit ist der Heap nach einiger Zeit fragmentiert, weil Objekte wieder freigegeben werden und so Lücken entstehen. Java und Garbage Collection können also gerade bei Speicherverwaltung effizienter sein als C++.

• Pooling geht ja davon aus, dass nur ein Thread zur Zeit ein Objekt nutzen kann. Aber die typischen Services, DAOs und Repositories heutiger Systeme sind von mehreren Threads parallel nutzbar. Sie sind zustandslos, so dass sie die wesentlichen Informationen über Parameter bekommen oder die Informationen hängen am Thread (zum Beispiel die aktuelle Transaktion oder die Datenbankverbindung). Nur in Ausnahmesituationen ist das Objekt nicht thread-safe - zum Beispiel wenn man statt eine lokalen Variable eine Instanz-Variable nutzt, die dann bei paralleler Ausführung der Methode in mehreren Threads überschrieben wird. Wenn man allerdings die Instanz-Variablen durch lokale ersetzt, hat man kein Problem - also ist das ein handwerklicher Programmierfehler.

Labels: EJB, Pooling, Spring

¶ 17:54 2 comments