Blogsystem

Im Prinzip bin ich mit blogger.com zufrieden. Allerdings reizt natürlich auch mal wieder ein neues System...

Vermutlich werde ich meinen Blog umziehen und technologisch auf jekyllbootstrap (http://jekyllbootstrap.com/) umstellen. Mit dem Kommentarsystem von disqus (http://disqus.com) schaut das Ganze eigentlich ganz nett aus :-)

Sobald ich hier technisch dazu gekommen bin, werde ich natürlich hier darüber berichten.

Archivieren von Outlook Mails in Textdateien

Ich habe ein kleines Script geschrieben, mit dem man seine gesamten Outlook Mails (inkl. Archiv) in Textdateien archivieren/exportieren kann. Mail-Attachments werden ebenfalls exportiert.
Um die Formatierung von HTML-Mails nicht zu verlieren, werden die Mails direkt als HTML Datei exportiert und können mit einen Browser betrachtet werden.

Anschließend lassen sich mit der Suche im Windows-Explorer sehr schnell Mails wieder finden.

Das Script ist unter https://github.com/mr678/mail-export-scripts zu finden.

Software Architektur - Designentscheidung: Modelgetriebene Entwicklung

Als Software Architekt steht man zu Projektbeginn vor vielen Entscheidungen.

Eine Entscheidung ist unter anderem ob man Modelgetrieben, inkl. Casetool-Unterstützung, vorgehen will oder eben nicht.

Im folgenden einige Punkte wieso ich mich bisher gegen den MDA / MDSD Ansatz (Model Driven Architecture, Model Driven Software Development) entschieden habe:

• MDA ist cool wenn es ein großes unternehmensweites Datenmodell gibt.
  Unternehmensweite Datenmodelle sind aufgrund der Service Orientierung etwas aus der Mode gekommen (der erste google Treffer zu „Unternehmensweite Datenmodelle“ ist ein Artikel aus der Computerwoche von 1989 (http://www.computerwoche.de/heftarchiv/1989/37/1151959/).
  
  In größeren Unternehmen existieren viele spezialisierte Applikationen die nur über definierte Schnittstellen kommunizieren müssen (beispielsweise über BUS- oder Workflowsysteme). Eine SOA passt hier oft besser als eine große Anwendung, die mit einem unternehmensweiten Datenmodell umgehen kann.
  
  Kleine modulare Applikationen à Sind die einzelnen Applikationen klein bzw. auch deren Datenmodell, stellt sich die Frage ob der Einsatz eines Case-Tools mit Klassengeneratoren eher die Produktionsgeschwindikgeit ausbremst.
• Beim Einsatz eines OR-Mappers bspw. basierend auf JPA wie Hibernate oder EclipseLink ist schon seit langen kein aufwändiges XML mehr notwendig. Mit Hilfe von Annotations lassen sich die Datenbank-Entitäten definieren.
  
  Bei der Verwendung eines MDA-Ansatzes können XML Beschreibungen zu den Java-Entitäts-Klassen automatisch generiert werden. Hier ist ein MDA Ansatz durchaus sinnvoll.
  
  Bei der Verwendung von Annotations wie bspw. in der JEE (@Entity) lässt sich sehr schlank ein Datenmodell definieren. Der Einsatz von Case-Tools mit Klassengeneratoren verringern hier eher die Produktionsgeschwindigkeit.

• Werden UML Diagramme primär zur Dokumentation benötigt, lassen diese sich bequem aus den bestehen Klassen generieren. Diese können bei der JEE direkt ins JavaDoc integriert werden (UMLGraph).

• MDA / MDSD wird im Moment in meiner Wahrnehmung aktuell weniger gepusht als JEE6.
  Verhältnis der JPA Vorträgen zu Modelling- Vorträgen auf aktuellen Java Konferenzen. Ggf. ist dies ein Grund wieso MDA Know How weniger verfügbar ist als JPA Know How.
  
  Als technisch Verantwortlicher für eine Software ist dies ein nicht unwesentlicher Punkt (gibt es Rotationsmöglichkeiten für Entwickler, welches Know How wird zur Softwarewartung benötigt).

Aus diesen Gründen habe ich mich meist gegen MDSD entschieden… ich geh allerdings davon aus, dass es noch weit mehr Gründe gibt ;-)

JBoss AS Security - @RolesAllowed

Mit der Annotation @RolesAllowed (javax.annotation.security.RolesAllowed) kann der Zugriff auf Klassen oder einzelne Methoden von einem AppServer kontrolliert werden.

Leider haben diese Annotation im JBoss AS 7 keine Auswirkungen!

Um EJBs abzusichern wird die Datei jboss-ejb3.xml benötigt (Maven Projekt: src/main/webapp/WEB-INF/jboss-ejb3.xml).

<?xml version="1.0"?> 

<jboss:ejb-jar xmlns:jboss="http://www.jboss.com/xml/ns/javaee"

               xmlns="http://java.sun.com/xml/ns/javaee"

               xmlns:s="urn:security"

               xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

               xsi:schemaLocation="http://www.jboss.com/xml/ns/javaee http://www.jboss.org/j2ee/schema/jboss-ejb3-2_0.xsd

                     http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/ejb-jar_3_1.xsd"

               version="3.1"

               impl-version="2.0">

  <assembly-descriptor>

    <s:security>

      <ejb-name>*</ejb-name>

      <s:security-domain>other</s:security-domain>

    </s:security>

  </assembly-descriptor>

</jboss:ejb-jar>

Die Security Domain “other” ist die Default-Security-Domain auf einem JBoss AS 7. Hier muss bei Bedarf die entsprechende Domain gesetzt warden.

Finde ich irgendwie merkwürdig, dass Teile der JEE Spec erst explizit aktiviert werden müssen.

Beim Deployen einer Anwendung wäre IMHO ein kleiner Hinweis angebracht, der darauf aufmerksam macht, dass  @RolesAllowed verwendet wird aber nicht greift…

Integrationstests mit Arquillian

2012-10-12 Testen mit Arquillian from Matthias Reining

Leider dürften die Folien ohne Tonspur nicht wirklich aussagekräftig sein....

Start Tweeting

ich habe jetzt schon seit "Ewigkeiten" einen Twitter-Account / aber noch nie was gezwitschert.

Hat sich mittlerweile geändert! Ich twittere jetzt auch und freu mich über Follower :-)

http://twitter.com/MatthiasReining

RESTeasy - Troublelogger

Anbei mal nur ein Verweis auf einen anderen Blog:

https://community.jboss.org/blogs/matthias.reining/2012/03/01/resteasy--troublelogger

Hab auch mal probiert bei JBoss was zu bloggen ;-)