Leichtgewichtige JEE Entwicklung mit dem Spring Framework

Leichtgewichtige JEE Entwicklung mit dem Spring Framework

Posts 1-10 of 15
  • Dagmar Buggle
    Dagmar Buggle    Premium Member
    The company name is only visible to registered members.
    Exceptions in der init-method
    Hallo,
    Newbie-Frage: wie verfährt man eigentlich elegant mit Exceptions, die in der init-method geworfen werden? Also d. h., wie fängt man sie, um sie dann bestenfalls an eine weitere Prozess-Schicht zu leiten?
    Gruß vom Bodensee
    Dagmar
    • 04 Jun 2009, 2:56 pm
  • Post visible to registered members
  • Dagmar Buggle
    Dagmar Buggle    Premium Member
    The company name is only visible to registered members.
    Re^2: Exceptions in der init-method
    Ich habe eine Klasse, die eine XML-DAtei ausliest und darus ein Modul-Objekt erstellt:

    <bean id="moduleReader" class="de.doxanize.xml.ModuleReader" init-method="parse" >
    <constructor-arg value="${xml.testfile}"/>
    </bean>
    <bean id="module" class="de.doxanize.fields.Module" init-method="init" >
    <property name="moduleReader">
    <ref bean="moduleReader"/>
    </property>
    </bean>

    Das Modul soll später mal als Datenobjekt in den Client injiziert werden. Wie schaffe ich es dort, die bei Parse() geworfenen Exceptions anzuzeigen?

    Gruß
    Dagmar
    • 04 Jun 2009, 4:58 pm
  • Post visible to registered members
  • Dagmar Buggle
    Dagmar Buggle    Premium Member
    The company name is only visible to registered members.
    Re^4: Exceptions in der init-method
    Genau, meine Denke war falsch, der ApplicationContext wird gar nicht gestartet. Das heißt, man muss das an dieser Stelle umdesignen, z. B. dass die Exceptions an Ort und Stelle geloggt oder in einer dafür zuständige Klasse gesammelt werden.

    Allerdings heißt das ja wohl auch, dass es eigentlich wenig Sinn macht, dass init-Methoden exceptions werfen dürfen, oder?

    Gruß
    Dagmar
    • 04 Jun 2009, 5:17 pm
  • Oliver Gierke
    Oliver Gierke    Premium Member
    The company name is only visible to registered members.
    Re^5: Exceptions in der init-method
    Es macht eigentlich nur Sinn, das zu tun, wenn der Fehler nicht zu beheben ist und es sinnvoll ist, den ApplicationContext gar nicht zu starten.

    IMHO macht es auch Sinn, anstelle der reinen Spring Option init-method die Annotationen aus JSR-250 zu nutzen um auch im Code explizit zu machen, dass es sich um eine Methode handelt, die nach dem Instantiieren aufgerufen werden *muss*, damit die Klasse ordnungsgemäß funtioniert. Leider ist das bei der programmatischen Nutzung der Klasse in beiden Fällen nicht wirklich ersichtlich.

    Gruß
    Ollie
    • 04 Jun 2009, 5:27 pm
  • Dagmar Buggle
    Dagmar Buggle    Premium Member
    The company name is only visible to registered members.
    Re^6: Exceptions in der init-method
    Oliver Gierke schrieb:
    IMHO macht es auch Sinn, anstelle der reinen Spring Option init-method die Annotationen aus JSR-250 zu nutzen um auch im Code explizit zu machen, dass es sich um eine Methode handelt, die nach dem Instantiieren aufgerufen werden *muss*, damit die Klasse ordnungsgemäß funtioniert.
    Ah genau, und dann werden Exceptions wieder brav zur Laufzeit geworfen und ich kann auf sie reagieren. Danke für den Tipp!
    • 04 Jun 2009, 6:02 pm
  • Eberhard WolffEberhard Wolff is a contact of your contacts
    Eberhard Wolff    Group moderator
    The company name is only visible to registered members.
    Re^3: Exceptions in der init-method
    Hallo,

    <bean id="module" class="de.doxanize.fields.Module" init-method="init" >
    <property name="moduleReader">
    <ref bean="moduleReader"/>
    </property>
    Kleiner Hinweis: Kürzer ist <property name="moduleReader" ref="moduleReader" /> . Existiert seit 1.2, wenn ich nicht irre.

    </bean>
    • 04 Jun 2009, 6:19 pm
  • Eberhard WolffEberhard Wolff is a contact of your contacts
    Eberhard Wolff    Group moderator
    The company name is only visible to registered members.
    Re^6: Exceptions in der init-method
    IMHO macht es auch Sinn, anstelle der reinen Spring Option init-method die Annotationen aus JSR-250 zu nutzen um auch im Code explizit zu machen, dass es sich um eine Methode handelt, die nach dem Instantiieren aufgerufen werden *muss*, damit die Klasse ordnungsgemäß funtioniert. Leider ist das bei der programmatischen Nutzung der Klasse in beiden Fällen nicht wirklich ersichtlich.
    ...oder man nutzt Constructor Dependency Injection und schreibt den Code direkt in den Konstruktor. Zumindest bei de.doxanize.xml.ModuleReader wird ja eh Constructor DI genutzt, so dass eine eigene init-Methode mir zumindest komisch erscheint. Vielleicht kann man de.doxanize.fields.Module ja auch gleich entsprechend ändern.
    • 04 Jun 2009, 6:22 pm
  • Dr. Siegfried Sauter-Fischer
    Dr. Siegfried Sauter-Fischer
    The company name is only visible to registered members.
    Re^7: Exceptions in der init-method
    Die ursprüngliche Frage war ja nicht, wie man am besten Initialisierungs-Code in Spring realisiert, sondern wie man mit Exceptions in der init-methode umgeht.

    Der Kern des Problems ist und bleibt, dass eine Exception bei der Initialisierung fliegt. Ob der Code im Konstruktor, in der Init-Methode oder durch eine PostConstruct-Annotation erledigt, der Kern des Problems bleibt gleich: Am Ende gibt es kein ordentlich initialisiertes Objekt. Entweder die Initilaisierung scheitert komplett (der Applixcation-Kontext lässt sich gar nicht hochfahren) oder man hat am Ende eine Referenz auf ein nicht sauber initialisiertes Objekt.

    Dies hat auch gar nichts mit Spring zu tun, sondern das identische Problem existiert auch, wenn die Objekte durch eine programatische Initialisierung erzeugt würden.

    Ich sehe nur die Möglichkeit, eine solche Situation streng zu vermeiden, d.h. eine Exception niemals in irgendwelchen Konstruktoren, Init- oder PostConstruct-Methoden zu werfen. Hierfür sehe ich zwei offensichtliche mögliche Ansätze:

    - Lazy-Initialisierung. In diesem Fall würde die Exception eben nicht bei der Erstellung und Initialisierung des Objekts fliegen, sondern bei dem späteren Methoden-Aufruf. Das Objekt bleibt konsistent und die Exception müßte halt später beim Methoden-Aufruf behandelt werden.

    - Fangen der Exception. In diesem Fall wäre aber das Objekt leider nicht ordentlich initialisiert und es würde sich die Frage stellen, wie mit diesem Objekt umgegangen werden kann. Das Objekt sollte zumindest wissen, dass es nicht ordentlich initialisiert ist und dann entsprechend reagieren können - z.B. sich die Exception gemerkt haben. Ob diese zweite Alternative wirklich sinnig ist will ich einmal dahin gestellt lassen.

    Grüsse

    Siegfried Sauter-Fischer
    • 05 Jun 2009, 5:01 pm