POJOs testen mit openpojo

Wer nach einer Möglichkeit sucht um POJOs sinnvoll und einfach zu testen, kann die openpojo API nutzen.

Es lassen sich damit

  • Getter/Setter
  • Business identity
  • default values

ziemlich einfach testen.

Maven Konfiguration:

OpenPOJO1

Hierzu gibt man am Anfang zuerst das Package an, in dem die zu testenden POJOs liegen:

private static final String POJO_PACKAGE = "com.openpojo.samplepojo";

Dann gibt man dieses bei der Instanziierung mit:

OpenPOJO2

Jetzt hat man die Möglichkeit, eine Auswahl an verschieden Regeln zu treffen, die auf die POJOs angewendet werden sollen. Diese kann man ganz einfach so hinzufügen:

OpenPOJO3

Dann kann noch eine Auswahl an Tests, die durchgeführt werden sollen, getroffen werden:

OpenPOJO4

Am Ende noch der Test:

OpenPOJO5

Welcher Thread setzt meinen Server unter Last?

Hallo zusammen,

wenn eine Java-Webanwendung Probleme bereitet und die Auslastung des Servers auf 100% schnellt, ist es meist recht schwer herauszufinden, wer denn nun eigentlich der Übeltäter ist. Dabei ist eine genaue Analyse leichter als gedacht. Kurz zusammengefasst:

  1. Mithilfe von top die PID des Java-Prozesses ermitteln.
  2. In top Shift-H drücken. Dadurch werden, statt Prozessen, die einzelnen Threads angezeigt.
  3. Die ID des Java-Threads mit der hohen Auslastung heraussuchen und notieren.
  4. Einen Threaddump der Anwendung ziehen, z.B. mit jstack <PID>
  5. Die ID des Java-Threads in Hex umwandeln.
  6. Diese Hex-ID könnt ihr nun im Threaddump suchen und so ermitteln, welcher Thread der Übeltäter ist.

Eine etwas ausführlichere Anleitung findet ihr hier: http://code.nomad-labs.com/2010/11/18/identifying-which-java-thread-is-consuming-most-cpu/

Jetzt nativ in JavaFX: Einfache Alert- und Dialogboxen

Im aktuellen Minor Release von Java 8 – JDK 8u40 („Limited Updates Release“) ist „mal schnell“ dazu gekommen, was bisher gefehlt hat: eine einfache und code-sparsame Möglichkeit, Alert- und Dialogboxen anzuzeigen.

Eine einfache modale Infobox geht jetzt z.B. mit der Klasse Alert folgendermaßen:

Alert alert = new Alert(AlertType.INFORMATION);
alert.setTitle(„Information Dialog“);
alert.setHeaderText(null);
alert.setContentText(„I must inform you that …“);
alert.showAndWait();

Eine Beschreibung unterschiedlichster Dialoge findet ihr in diesem Blogbeitrag.

Außerdem sind in diesem Release für JavaFX dazu gekommen: Unterstützung von formatiertem Text in Eingabecontrols und ein SpinnerControl.

Eclipse und Maven – pom.xml direkt in der XML-Ansicht öffnen

Eine kleine, aber feine Eclipse-Einstellung, die wir in unserem Brown Bag Lunchmeeting entdeckt haben:
Window => Preferences => Maven => User Interface => Haken setzen bei „Open XML page in the POM editor by default“
Somit wird die pom.xml immer gleich in der XML-Ansicht geöffnet, in der man sie ja üblicherweise auch braucht.
Das Umschalten weg von der Overview-Ansicht entfällt dann.

eclipse-maven-open-pom_screenshot

"Java ist raus aus den Kinderschuhen"

Eine Welt ohne Java? – Das ist für doubleSlash-Mitbegründer Oliver Belikan nicht vorstellbar. Ganz im Gegenteil: doubleSlash hat bei der Entwicklung der objektorientierten Programmiersprache selbst einen entscheidenden Anteil geleistet und sich von Anfang an in der Entwicklercommunity engagiert. Die objektorientierte Programmiersprache ist heute nicht nur bei Software und Webanwendungen, sondern auch bei uns ein fester Bestandteil bei der Softwareentwicklung in Kundenprojekten und bei der eigenen Produktentwicklung. So steckt die Java-Technologie beispielsweise im Postfinder oder dem BMW-Produktkonfigurator. Im Interview berichtet Oliver Belikan von Java-Erfahrungen aus der Praxis und wirft einen Blick in die Zukunft.

Mehr…

Tutorial: Datenbankanbindung mit EclipseLink unter Apache Karaf

©-t_kimura---istockphoto.com_blogMöchte man eine OSGi Anwendung betreiben, ist dazu erstmal nicht viel nötig: Die gewünschte Implementierung nehmen, eigene Bundles deployen und schon kann es losgehen. Wächst mit der Zeit die eigene Software, steigen aber auch die Anforderungen an die Laufzeitumgebung. Mit Karaf bietet das Apache Projekt eine kompakte Plattform zum Betrieb von OSGi Anwendungen, welche sich durch ein reichhaltiges Plugin-Angebot (sog. Features) erweitern lässt.

Mehr…

Sichere Benutzer- und Rollenvergabe durch container managed security

©-voyager624---Fotolia.com_blogAuthentifizierungs- und Autorisierungsmechanismen stellen in unternehmenskritischen Anwendungen unerlässliche Bestandteile dar. Java EE-konforme Applikationsserver wie z.B. der Oracle GlassFish Server bieten mit der „container managed security“ ein mächtiges Werkzeug zur Umsetzung von Authentifizierung und rollenbasierter Autorisierung in Webapplikationen.

Die Idee hinter dem Konzept der container managed security ist die Definition von Benutzern und Rollen außerhalb der eigentlichen Enterprise-Applikation und der Einsatz eines standardisierten Mechanismus zur Legitimation des Benutzers. Sämtliche Entscheidungen zur Zugriffskontrolle werden automatisch durch den eingesetzten JEE-Applikationscontainer getroffen. Der Entwickler selbst definiert lediglich, welche Applikationsbestandteile abgesichert werden sollen und für welche Benutzerrollen diese verfügbar sind.

Hierfür stehen dem Entwickler diese beiden Konstrukte zur Verfügung:

Deklarative Sicherheit (declarative security)

Bei der deklarativen Konfiguration werden die Sicherheitsanforderungen der Applikation entweder über Deploymentdeskriptoren oder Java-Annotations definiert. Im Falle von Webkomponenten erfolgt dies über den Deskriptor web.xml, bei Java Enterprise Beans über die Datei ejb-jar.xml.

Folgende Beispielkonfiguration beschränkt den Zugriff auf sämtliche Web-Ressourcen unter der URL /private auf Benutzer der Rolle user:

<security-constraint>
 
<web-resource-collection>
 
            <web-resource-name>private</web-resource-name>
 
            <url-pattern>/private/*</url-pattern>
 
     </web-resource-collection>
 
     <auth-constraint>
 
            <role-name>user</role-name>
 
     </auth-constraint>
 
</security-constraint>

Erfolgt ein Zugriff auf diesen Bereich, wird der Benutzer aufgefordert sich zu authentisieren. Der Login – beispielsweise über ein HTML-Formular – wird folgendermaßen definiert:

<login-config>
 
     <auth-method>FORM</auth-method>
 
     <realm-name>myrealm</realm-name>
 
     <form-login-config>
 
            <form-login-page>/login.html</form-login-page>
 
            <form-error-page>/error.html</form-error-page>
 
     </form-login-config>
 
</login-config>

Die Authentifizierung erfolgt gegen die angegeben Realm. Dies kann z.B. ein vorhandener LDAP-Server im Unternehmensnetzwerk sein.

Programmatische Sicherheit (programmatic security) 

Es gibt Anwendungsfälle, in denen ein komplexeres Sicherheitsmodell in der Applikationabgebildet werden muss, das sich nicht mit der deklarativen Sicherheit beschreiben lässt. Das ist beispielsweise der Fall, wenn bei häufig fehlgeschlagenen Loginversuchen externe Systeme wie z.B. ein Security Incident Tool benachrichtigt werden müssen.

In solchen Fällen kann mit der programmatischen Sicherheit während der Authentifizierung weitere Geschäftslogik ausgeführt werden. Der Zugriff auf Methoden zur Authentifizierung und Autorisierung erfolgt hierbei über die Schnittstelle HttpServletRequest der Servlet 3.0 Spezifikation.

container managed security: sicher, effizient und wartungsfreundlich 

Die container managed security trägt maßgeblich zur Sicherheit von Unternehmensanwendungen bei, da die fehleranfällige Implementierung von Authentifizierungs- und Autorisierungsmechanismen durch den Anwendungsentwickler vermieden wird.

Durch Wegfall der Implementierung von Schnittstellen zu den dahinterliegenden Authentifizierungssystemen und Verzeichnisdiensten, wird nicht nur die Effizienz des Entwicklerteams, durch weniger Programmcode/Bugs und einfachere Konfiguration, sondern auch die Wartungsfreundlichkeit der Applikation verbessert.

 


Quellen:
[Bild] © voyager624, Fotolia.com_blog

Weiterbildung bei doubleSlash: Employer Branding mal anders

Techdays 14Von Mitarbeitern für Mitarbeiter – das ist das Credo der „Technology Days“, ein zweitägiger Workshop, den doubleSlash jährlich gemeinsam mit den Mitarbeitern veranstaltet.

Themen und Trends rund um technische und businessrelevante Inhalte waren Bestandteil der Fachvorträge auf den „Technology Days 2014“. In kleinen Gruppen haben wir uns rege zu Themen wie „Was tut eigentlich ein Garbage Collector?“ oder „Neues in Java 8“ ausgetauscht.
Dabei kamen auch neue Präsentationsformate zum Einsatz. Der Lightning Talk (Blitzvortrag) ist ein gängiges Format auf technischen Konferenzen. Ein Vortrag dauert nur ein paar Minuten, für jeden Slide wird eine bestimmte Sekundenzahl vorgesehen. Mehrere Referenten sprechen dann in einem vorgegebenen Slot zu unterschiedlichen Themen.[1]Mehr…

Security in Webanwendungen Teil 3: Sicherer Betrieb von Webapplikationen

In dieser Blogserie haben wir bereits die Themen Design– und Programmierung von sicheren Webanwendungen behandelt. Im letzten Teil wird beschrieben, wie der sichere Betrieb von Webapplikationen gewährleistet werden kann.

Reduzieren von Serverinformationen

Selbstverständlich möchte man einem Hacker so wenig Informationen über ein System geben wie nur möglich. Allein die Anzeige der Versionsnummer der verwendeten Server kann genutzt werden, um gezielt nach Informationen über Sicherheitslücken der spezifischen Versionen zu suchen. Dadurch wird der Aufwand, in das System einzudringen, für einen Angreifer geringer.

Das übliche sicherheitssensible System nutzt einen Proxyserver um die SSL-Verschlüsselung der Verbindung zu terminieren, damit der eigentliche Applikationsserver vor dem direkten Zugriff durch die Nutzer geschützt wird. Die Datenübertragung zwischen dem Proxy- und Applikationsserver erfolgt dann oft unverschlüsselt. Somit gibt es bereits für eine Webapplikation zwei Server, bei denen man die Versionsnummer verbergen muss. Das Verbergen der Server- und Versionsinformationen hat Auswirkungen auf zwei Ebenen. Die eine Ebene ist das HTTP-Protokoll, die zweite Ebene die Anzeige von Exceptions in der Webapplikation. In beiden Ebenen werden keine oder nur reduzierte Informationen angezeigt. Generell sollten dem Nutzer jedoch sowieso keine Exceptions oder Stacktraces angezeigt werden.

Im Folgenden wird an einer Beispielarchitektur gezeigt, wie sich die Versionsnummern abschalten lassen. Genutzt wird ein Apache Webserver in der Version 2.2 als TLS-Proxy, welcher die SSL-Verbindung terminiert und einen Apache Tomcat in der Version 7, der als Applikationsserver dient.

Im Apache Webserver lassen sich die Serverinformationen über den folgenden Eintrag in der Datei „httpd.conf“ anpassen:

ServerTokens Prod

Mit dieser Angabe wird lediglich der Name des Servers angezeigt, im Ursprungszustand würde der Apache Webserver die folgenden Informationen ausgeben:

  • Name des Servers
  • Versionsnummer
  • Name des verwendeten Betriebssystems
  • Name und Versionsnummer der verwendeten Module

Diese Informationen wären für einen Hacker sehr nützlich, denn er kann auf dem Schwarzmarkt gezielt Tools einkaufen, die ihm helfen den Server zu kompromittieren.

Die Reduzierung der Serverinformationen beim Apache Tomcat 7 gestaltet sich etwas schwieriger. Um hier die Serverinformationen zu reduzieren, muss man die Datei „ServerInfo.properties“ aus dem JAVA-Paket „catalina.jar“ entpacken. Zum Entpacken öffnet man die Konsole des Betriebssystems und wechselt in das Verzeichnis „lib“ innerhalb des Apache Tomcat. Anschließend führt man folgenden Befehl aus:

jar xf catalina.jar org/apache/catalina/util/ServerInfo.properties

Nun befindet sich innerhalb des Bibliotheksverzeichnisses der Verzeichnispfad „org/apache/catalina/util“, in dem wiederum die Datei „ServerInfo.properties“ existiert. Im folgenden Beispiel ist der Inhalt der Datei bereits angepasst und im Eintrag „server.info“ die Versionsnummer entfernt:

server.info=Apache Tomcat
server.number=7.0.50.0
server.built=Dec 19 2013 10:18:12

Nun zeigt auch der Apache Tomcat im HTTP-Protokoll und bei Exceptions keine Versionsnummern mehr an.

Die Sicherheit in Webapplikationen kann also an mehreren Stellen optimiert werden. Schon beim Desgin wird durch die Beachtung von Sicherheitsmechanismen ein höherer Standard gewährleistet. Maßnahmen bei der Programmierung, wie beispielsweise das Escaping von Metazeichen oder die Nutzung eines Sicherheitstokens, sorgen ebenfalls für mehr Sicherheit in Webanwendungen. Durch die Reduzierung der Serverinformationen kann auch beim Betreiben von Webapplikationen das Risiko eines Hackerangriffs gesenkt werden.

Produktiver modular arbeiten dank OSGi Blueprint

QuellcodeDie Modularisierungsspezifikation OSGi hat zwar schon ein paar Jahre auf dem Buckel, trifft aber noch immer den Zahn der Zeit. Dies zeigt sich nicht zuletzt dadurch, dass Oracle für Java 8 ein ähnliches System namens Jigsaw plant. Doch während Jigsaw noch Zukunftsmusik ist, wird OSGi bei doubleSlash bereits fleißig eingesetzt.

Während der Einarbeitung in das Thema OSGi starten in der Regel alle Lernwilligen bei einfachen Services, die händisch registriert und abgefragt werden. Dies ist ein guter Weg, um das System kennenzulernen, artet aber im produktiven Einsatz sehr schnell aus. Um diese elementaren Funktionen zu erleichtern, lohnt es sich, einen Blick in die Enterprise-Spezifikation von OSGi zu werfen.

Unter dem Begriff „Blueprint“ findet man eine zeitgemäße Behandlung der Services: Dependency Injection!

Voraussetzung dafür ist eine lauffähige Implementierung des Standards, z.B. Apache Aries. Um einen neuen Service zu registrieren, wird zunächst eine XML Datei unter OSGI-INF/blueprint/ angelegt (Beispiel von aries.apache.org):

<?xml version="1.0" encoding="UTF-8"?>
<blueprint xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0">
   <service id="serviceOne" ref="account" interface="org.apache.aries.simple.AccountInterface" />
   <bean id="account" class="org.apache.aries.simple.Account"/>
</blueprint>

Blueprint sorgt nun automatisch dafür, dass dieser Service im OSGi Container registriert wird.

Um diesen jetzt in einer Java Klasse (im Beispiel „AccountClient“) verwenden zu können, bedarf es folgender Konfiguration:

<?xml version="1.0" encoding="UTF-8"?>
<blueprint xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0">
   <bean id="accountClient" class="org.apache.aries.simple.AccountClient">
      <property name="account" ref="accountRef" />
   </bean>
   <reference id="accountRef" interface="org.apache.aries.simple.AccountInterface"/>
</blueprint>

Damit hat man bereits alles Nötige, um den Service verwenden zu können. Der Code wird entschlackt und die Testbarkeit der Anwendung deutlich verbessert. Natürlich bietet Blueprint noch einige weitere Features – beispielsweise die Handhabung von kurzfristig ausfallenden Services über Proxies, welches ein grundlegendes Problem in einer so dynamischen Umgebung ist.

Auch wenn die Fülle an Möglichkeiten Einsteiger etwas erschlagen kann, sollte man keine Scheu haben, früh einen Einblick jenseits der Kernspezifikationen zu wagen. Die Belohnung sind oft große Produktivitätszuwächse. Durch die Modularisierung der einzelnen Bereiche einer Software werden diese kleinen Teile automatisch wartbarer. Komplexität und Abhängigkeiten werden reduziert und dadurch langfristig auch die Kosten eines Projekts.