Guice 3 mit @PostConstruct = Mycila

Von Spring habe ich mich schon länger verabschiedet und bin für meine clientseitigen Programme auf Guice gewechselt. Bis auf die Tatsache das es keinen automatischen Autoscan gibt, hat mir nichts wirklich gefehlt. Guice unterstützt auch standardmäßig nicht die Common Annotions, aber bei Guice 2 hatte ich http://code.google.com/p/guiceyfruit/ im Einsatz, da das jedoch auf intern Datenstrukturen von Guice 2 zurückgriff, konnte ich nicht auf die neue Version Guice 3 migrieren. Also schmiss ich GuiceFruit raus und suchte eine Alternative. Die gibt es mit dem Projekt http://code.google.com/p/mycila/:

http://code.mycila.com/wiki/MycilaGuice

Google Guice contributions:

  • ServiceLoader plugin (enables injection into loaded services)
  • JSR250 supports improved from GuicyFruit
  • Custom Injector with more useful methods which consider the whole Injector hierarchy
  • CachedScope to cache your binding for a specific duration

Neben Mycila Guice gibt es auch noch andere tolle Dinge:

  • Mycila Event
  • Mycila JMX

Ähnliche Beiträge

3 Gedanken zu “Guice 3 mit @PostConstruct = Mycila

  1. „automatischer Autoscan“ ist gut… 🙂

    Hast Du Dich in Deinem Blog mal darüber ausgelassen, welche Gründe Dich weg von Spring hin zu Guice gebracht haben? Konnte eben auf Anhieb nichts dazu finden.

    Gruß
    Burkhard
    (begeisterter Spring-Anhänger ;-))

  2. Ohne IoC kann ich heute keine Software mehr bauen und ich halte DI für DAS zentrale Architekturpattern der letzten Jahre. Ich wüsste nicht, was so einen großem Impact auf das Design von Anwendungen hatte. Spring war für mich daher immer als IoC-Container interessant, für die Clientseite und Serverseite. Jetzt gab es es drei Entwicklungen. a) Die erste war, das ich auf Standards migriert habe, also etwa weg von XML-Konfigs zu Annotationen, von Hibernate zu JPA, … Das zweite war, dass ich für Enterprise-Anwendungen von J2EE 1.4 auf Spring gewechselt bin, dann nach Punkt a) diese standardisiert habe und dann auf Java EE 5 und Java EE 6 und —- ich vermisse nichts! c) Der dritte Punkt ist die Clientseite. Im Grunde nutze ich heute nur noch einen IoC Container, und brauche das ganze spezielle Schnick-Schnack nicht. (Und für JPA-Persistenz kann man http://code.google.com/p/google-guice/wiki/GuicePersist nutzen.) Wenn ich die Möglichkeiten also zusammenfassend von Spring betrachte, ist das für mich alles irrelevant. Statt Spring-MVP nutzt ich privat GWT, Meta-Annotationen nie gebraucht, EL finde ich unpassend, Exporter für RMI/WS sind bei Java EE unnötig, CDI ist WAHNSINN mit Events usw. Insgesamt alles toll, aber brauche ICH nicht. Darum kann ich mich auch ohne Abstriche von Spring verabschieden.

  3. Hi,

    wollte nur gerade einen kleinen Hinweis da lassen. AutoScan gibt es. 😉 Da ich satt war, immer die ESL von Guice zu nutzen (welche ich extrem gut gelungen finde), habe ich eine Erweiterung geschrieben, welche deinen Classpath scanned und entsprechend die Bindings aufbaut.

    Es werden mehrere Scanner unterstützt (Sonatype, Reflections und mein eigener auf ASM basierend).
    Du kannst Heute schon Teile von der Java EE 6-API nutzen. (@WebServlet, @WebFilter, @Alternative, beans.xml, …)

    Und man kann super einfach neue Features miteinbinden. (z.b. hatte ich für @PostConstruct GuicyFruit genutzt)

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert