Ganz einfach, die Vereinfachung. Java EE6 will immer mehr in die Richtung der Simplifizierung gehen. Je einfacher desto besser und für so ein Heavy- Weight Produkt auch nicht verkehrt. Ein Schwerpunkt der Java EE6 Spezifikation ist vorallem das herauswerfen der XML- Descriptors. Diese sollen jetzt eher optional zur Verfügung stehen. Es soll mehr in den Beans direkt gearbeitet werden und vorallem mit mehr Annotationen. Für eine bessere und Object- orientiertere- Übersicht.

EE6 will mehr auf Profiles eingehen und veraltete Technologie entfernen, so stehen z.b. auch schon in der neuesten Version verschiedenste Pakete auf der Pruning (Pakete die in Zukunft nicht mehr in der Spezifikation vorhanden sein werden) Liste. Eine Neue Art von Beans sind die Singleton Session Beans.

Profiles sind das Hauptmerkmal der neuen Java EE6 Spezifikation, sie sollen den Entwicklern Helfen effektiver zu werden. Profile können für sich entwickelt und deployed werden. Sie können mit anderen Profilen verknüpft oder Teile eines anderen Profils sein.

Restful Webservices – werden immer wichtiger und einfacher gestaltet. Durch Annotationen gesteuert können diese einfachen Services sehr schnell angelegt werden.

@Path("export")
public class BookRessource() {
   @PersistenceContext(unitName = "exportPU")
   private EntityManager em;

   @GET
   @Produces({"application/xml", "application/json"})
   public List getAllBooks() {
     Query query = em.createNamedQuery("findAllBooks");
     List books = query.getResultList();
   return books;
   }
}

Die neue Version der JPA2.0 soll einen größeren Wortschatz besitzen. Erweiterungn wie Collections of Simple Data Types (String, Integer, etc.).  EJB’s werden einfacher zu bewältigen sein, so können diese direkt in der WAR File mit deployed und asynchron ausgeführt werden. Die Annotation @Singleton kann eine einfache Java Class zu einem container – managed – singleton umwandeln.

Für das ganze habe ich mir natürlich ein neues Buch zugelegt und dieses mal in English. So werden die Begriffe nicht extra nochmal übersetzt und verwirren zusätzlich. Es gibt schon einige Neuerungen, daher ist es nicht schlecht wenn man sich das ganze mal genauer betrachtet und die neuen Verfeinerungen und Vereinfachungen der Java EE6 einverleibt.

Hier die ISBN zum Buch: 9781430219545 oder auch als Link direkt zu Amazon: http://www.amazon.de/Beginning-Java-Platform-GlassFish-Professional/dp/1430219548/ref=sr_1_1?ie=UTF8&qid=1260873020&sr=8-1

Jetzt hat man schon so viel zu tun mit JSF und arbeitet sich immer tiefer in die Mysterien der Querverlinken Entities und Session basierten Beans. Bei einer simplen Tabelle mit SessionBean Ressources hängt man dann 40 Minuten und sucht einen Fehler, fast schon zum Mäusemelken. Man verzweifelt langsam an sich selbst bis man bemerkt das der Typ “binding” nichts mit der DataTable zu tun haben sollte. Also die Bean #{bean.viewList} im value deklariert und schon funktioniert alles.

Ich hab bestimmt 25 Minuten mit dem Debugger verbracht bis mir aufgefallen ist in einer anderen DataTable die ich vor 2/3 Tagen angelegt habe, dass ich kein value deklarierte. Blöder Fehler auf den ich hiermit gerne Hinweise, denn man kommt zu schnell in die Versuchung mit dem Vorschlag “binding” zu arbeiten.

<h:dataTable value=”#{bug.viewList}” var=”item”>
<h:column>
<f:facet name=”header”>
<h:outputText value=”Datum” />
</f:facet>
<h:outputText value=”#{item.beTimestamp}“>
<f:convertDateTime type=”both” dateStyle=”short” />
</h:outputText>
</h:column>

Hier noch ein kleines Beispiel. Die einzelnen Zeilen der Liste werden in der Variable item gespeichert und können dann abgerufen werden, jenachdem ob man ein Entity dahinter hat, kann man die getter des jeweiligen Feldes nehmen, wenn ein Vector dahinter steht ganze einfach mit dem jeweiligen Feld  #{item[2]}

Es ist zwar nichts neues, aber um mal wieder einen kleinen Blog Eintrag zu generieren sprech ich heute mal die Übergabe von Parametern mit <h:commandButton> an. Der Commandbutton wird als Standard Submit Button ins HTML geparsed und kann mit diversen Action Listenern verknüpft werden die beim aktivieren des Button’s ausgeführt werden und somit einzelne Werte übergeben.

Ich nutze diesen z.b. um bestimmte Nutzerdaten von ein Bean in das nächste zu schaufeln oder um div. Werte mit zu übergeben die nur ab und an benötigt werden und daher nicht in der Datenbank gespeichert werden sollten.

Ein kleines Beispiel hierzu während ich auf meinen Glassfish Testserver warte.

<h:commandButton id=”addBtn” action=”addBtn” value=”Eintragen”>

<f:setPropertyActionListener target=”#{entry.id}” value=”5″ />

<f:setPropertyActionListener target=”#{entry.name}” value=”#{project.name}” />
</h:commandButton>

In diesem Beispiel wird in mein EntryBean folgendes passieren.

Der Setter für id wird gestartet und mit 5 befüllt also

public void setId(int id) {

this.id = id;

}

public void setName(String name) {

this.name = name;

}

Bei der ganzen Prozedur wird somit aus dem ProjectBean per Getter der Projektname herausgezogen und übergeben. Ich hoffe ich konnte einigen etwsa helfen und wünsch weiterhin viel Spass, als nächstes gibts ein kurzes Tutorial/Howto zu den <h:selectOneListbox /> mit SessionBean Verknüpfung.

Für manche dürfte das ganz normal sein, mal ein Wochenende arbeiten zu dürfen. Ich finde es ab und an auch amüsant, da mich meine Arbeit nicht nervt sondern motiviert. Ich bastel gerne an den verschienen Projekten und auch, so unglaubwürdig wie es klingen mag sitz ich daheim noch viele Stunden am Schreibtisch vor der Kiste. Somit würde ich sagen komme ich am Tag auf gute 16h vorm PC gehangel und fühle mich dennoch nicht kaputt. Man ist zwar geistig total im Arsch aber das Gefühl was erreicht zu haben. Automatismen bestimmen das Leben, somit ist auch der Mensch sehr an sein automatisch ablaufendes fast schon gar wiederholendes Leben gewohnt. Jeden Morgen der Kaffe, eine kleine Brotzeit und ab gehts.

In der Technik und Entwicklung die mein so bescheidenes Leben prägt ist es auch nicht anders. Morgens raus, zur Zeit ist es 6:50 in der mein Wecker meint zu brüllen. Um 7:20 quäl ich mich dann mehr oder weniger doch mal aus dem Bett und um kurz nach 7:35 ist man dann mal auf Arbeit. Kaum hat man die Räumlichkeiten erreicht fühlt man sich wie zu Hause, da wir sehr viel Zeit hier investieren.

Es ist zwar super wenn man sein Hobby zum Beruf macht, nur ist es genauso anstrengend unterscheiden zu können wann damit Schluss ist, wann sich der Tag für einen selbst und für die Firma gelohnt hat, denn man sollte sich nicht gleich aufarbeiten. Die Kreativität ist zwar an manchen Tagen recht bäh und nicht grad explodierendem Fortschritt geprägt aber man macht halt mal.

So, langsam kommen wir auch zu meinem letzten Wochenende… kurz meinen Vater in Untersteinach am Musikvereinshaus besucht der irgendwo auf einem Gerüst krackselnd ein paar Rohre gewechselt hatte, und auch schon die ersten Regentropfen mir das Gespräch versauten. Also ab zurück ins Auto und ab auf die Arbeit. Fast zeitgleich bin ich mit Frank gekommen, wir hatten uns weder abgesprochen noch geschrieben, schon sehr seltsam naja ab an den Schreibtisch und schon war es ein Tag wie viele andere.. mit dem einzigen Unterschied, es nervt niemand. Keine Besuche von Mitarbeitern etc. man konnte in aller Ruhe vor sich hinarbeiten und so manchen Fortschritt erzielen der seit Wochen ausblieb da immer was dazwischen kam. Arbeitsbegin 15:00

Als wir endgültig zu Dritt das ganze Haus unter beschlag genommen hatten, gab es natürlich nichts besseres als eine saftige Familienpizza vom örtlichen Lieferservice der irgendwann auch vorm Tor stand. Somit hatten wir die erste Pause um 18:30. Der Fortschritt ist kaum zu bremsen, nach nur paar Stunden hatten die Verbindungen zwischen RMI/IIOP EJB3 und Glassfisch – für viele waren das grad Hyroglyphen der feinsten Sorte – miteinander kommuniziert, das einzige was extrem störend ist, sind die schwächelnden Rechner mit denen man sich abgeben muss. Ich hätte gerne in einer virtuellen Umgebung gearbeitet, unter einem Unix System und alles direkt live getestet, somit konnte ich leider nur “Demo” – Werte nutzen. Um ca. 23:00 bekamen wir den ersehnten Anruf aus München dass die Umstellung so weit fortgeschritten war, dass wir endlich wieder auf die Server zugreifen konnten. Konfigurierend und gar in dem von uns noch möglichen Tempo einer altersschwachen Schildkröte konnten wir um ca. 3:00 die Klappe schließen. Alles lief soweit und wir konnten zum Glück weitere Projekte vorantreiben.

Einen wunderschönen Sonntag Morgen an alle. Nachdem ich nunmehr seit knapp 18 Stunden vorm Rechner häng und jetzt auch so gut wie fertig bin. Noch ein kleiner Blogeintrag zum Thema RMI / IIOP und Datenübertragung durch serialisierte Klassen über den JNDI.
Wir hatten heute Serverumzug und in den “Wartezeiten” konnte ich einige nützliche Dinge herausfinden, so auch die Kommunikation von RMI Umsetzung mit Glassfish in Eclipse nachdem die Projektverwaltung im Netbeans nicht so meinen Geschmack entsprochen hatte. Dank der überaus guten Einarbeitung in letzter Zeit hat lediglich die Übermüdung meinerseits zu kleineren Fehler geführt.
Einzig und allein die Serververwaltung in eclipse für Glassfish ist nicht ganz so rosig, da die Steuerung zwischen Domain und Server in Eclipse nicht so wirklich ausgereift ist.
Aber jetzt zum eigentlichen Thema: RMI / IIOP Konfiguration im unabhängigen Client

Properties props = new Properties();
props.setProperty(“java.naming.factory.initial”,
“com.sun.enterprise.naming.SerialInitContextFactory”);
props.setProperty(“java.naming.factory.url.pkgs”,
“com.sun.enterprise.naming”);
props.setProperty(“java.naming.factory.state”,
“com.sun.corba.ee.impl.presentation.rmi.JNDIStateFactoryImpl”);

// optional.  Defaults to localhost.  Only needed if web server is running
// on a different host than the appserver
props.setProperty(“org.omg.CORBA.ORBInitialHost”, “localhost”);

// optional.  Defaults to 3700.  Only needed if target orb port is not 3700.
props.setProperty(“org.omg.CORBA.ORBInitialPort”, “3700″);

try {
InitialContext ic = new InitialContext(props);
this.foo = (Test) ic.lookup(“de.jk.package.bean.remote.Test”);
} catch (NamingException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}

Der Aufruf ist fast intuitiv, das EJB3 Remote Interface wird per JNDI Aufruf auf den jeweiligen Server serialisiert übertragen und im Client verwendet. Standard Glassfish Port ist hierbei die 3700 der Server in meinem Fall localhost und mein Interface das “geladen” werden soll de.jk.package.bean.remote.Test der volle Name muss angegeben werden da sonst das Interface nicht gefunden wird, ich hab lang genug herumprobiert ob man es auch anders erreichen könnte, aber keine Chance. Also Packagename + RemoteInterfaceClassName.

Ich würde euch gerne ein paar Screenshots davon zeigen, aber nachdem dieser Blogeintrag anhand eines reellen Projekte entstand, wird das vorerst ausbleiben, falls ich morgen die geistige “Frische” erreiche und mich dazu durchringen kann, werde ich noch eine kleine Demoapplikation veröffentlichen und hier zum Download anbieten.

Sehr nützlich war der Link von Sun die es einwandfrei beschreibt. Zum Artikel

Ich habe heute mal wieder etwas Zeit mein kleines Projekt voran zu treiben. Bei diesen Gelegenheiten stößt man wie immer schnell an ein kleines Prolbem. Wie übergebe ich z.b. eine Id von A nach B in einem Hiddenfield da es den Endbenutzer nicht zu interessieren hat.
Wenn man mit PHP und Html arbeitet deklariert man ein

<form method=”POST”>

<input type=”hidden” name=”hiddenField” value=”12345″>

<input type=”submit” name=”action” value=”LeseId”>

</form>

und ruft es mit PHP ab:

<?

if(isset($_POST['action'])  {

echo $_POST['hiddenField'];

}

?>

Im JEE Verfahren mit JavaServer Faces ist das ganze etwas anders, aber sobald man sich daran gewöhnt hat doch um einiges einfacher, da man beliebig viele Properties dem Action Listener dazu geben kann.

Hier zur Lösung

So, mal wieder einen kleinen Bericht über meine IDE Erfahrungen. Mitlerweile gefallen mir beide der Plattformen recht gut, ich komm zügig voran in meinen Projekten und kann relativ flott aggieren. Relativ flott ist vorallem beim Eclipse die Probe aufs Exempel da es bei schwächeren CPU’s leicht stutzig wird, da schlägt sich Netbeans um einiges besser. Es ist schneller mit Code – Intellisense und in der RAM Auslastung.

Eclipse hat eine weite Verbreitung daher bekommt man sehr schnell Unterstützung in Communities und Foren zu diversen Problemen, wobei etwas googlen vorher fast jedes Hindernis lösen kann.

Eclipse ist vorallem zum Lernen von div. Techniken ein wunderbares Hilfmittel da dem Programmierer nicht alles vorgelegt wird sondern man noch viele Freiheiten zum Eingreifen besitzt. Netbeans ist vom ganzen automatisierten Ablauf viel weiter und generiert sehr viel von alleine worüber sich der Programmierer erst Gedanken macht wenn ein Fehler darin auftritt. Somit ist ganz klar Eclipse für den Einsteiger ein besseres Werkzeug da er sich viel Erarbeiten muss, und sich so schneller mit der Materie auseinander setzen kann.

Wer vom Wissen her bereits soweit ist und schon mit beiden Programmierumgebungen im JEE Bereich gearbeitet hat, wird auf anhieb nur kleine Unterschiede merken. Rein die Servletsteuerung bei Netbeans ist relativ simpel gehalten, wo Eclipse eine kleine Stärke verbuchen kann da diese von dem standardmäßigen anlegen von Servlets bishin zu Filtern und Rules alles unterstützen. Wer aber mit dem moderneren Werkzeug arbeiten möchte ist bei Netbeans wieder mit vorne dran, die Unterstützung von Java Server Faces (JSF) ist voll implementiert so das man damit schnell voran kommt.

Von der Datasource verwaltung ist es im Netbeans angenehmer da man seine Entity – Klassen direkt im Projekt erzeugen kann und diese auch die passenden Datasources anlegen. Eclipse dagegeben benötigt noch relativ viel händisches Eingreifen bis die Beans, Entities und Webservices miteinander kommunizieren können. Ist ABER eine sehr gute Übung um zu sehen wie die Projekte untereinander verknüpft werden müssen und welche Fehler dabei entstehen wenn dies nicht getan wird, da der J2EE Server meist allgemeine Fehler herauswirft die alles sein können.

Bei gelegenheit werde ich noch einen kleinen Text über Serverprogrammierung auf beiden IDE’s verfassen. Schönen Feierabend allen.

mfg Jo.

Ich konnte bisher noch keinen JNDI Lookup auf den Glassfish testen, aber für eine schnelle Lösung habe ich zwar den “langsamen” aber dennoch funktionieren Weg des CORBA Lookups gewählt, das allgemine Verbindungsprotokoll für die Sprachenunabhängigkeit. 

Hier noch der kleine Auschnitt zum testen.

viel Spass.

Ich habe heute mal Glassfish und jBoss im Test auf meinem Rechner. Nachdem der jBoss zwar ein mächtiges Werkzeug ist aber für viele Anwendungen einfach zu viel beherrscht und auch gar nicht genutzt wird, habe ich mich vorerst für den kleinere Konkurenten Glassfish entschieden. Durch die Übernahme von SUN sollte sich auch Glassfish in den kommenden Versionen zu einer 1A Kombination mit MySql entwickeln. Die Oberfläche des Glassfish Application Server ist super übersichtlich und nach nur ein paar Minuten einsatzbereit. Deployen von Applications funktioniert ohne Probleme und auch Connection Pools erstellt man im Handumdrehen. jBoss dagegen setzt noch auf die, doch meist unzuverlässige Handarbeit wert. Man benötigt unter anderem länger als dass auch die Fehlerquote sehr hoch sein kann. Im Starten der Maschine hat auch wieder Glassfish die Nase vorne. Innerhalb von 40 Sekunden ist er voll einsatzfähig und deployed die ersten Applications.  Der jBoss startet zwar fast in der selben Geschwindigkeit, ist aber vom Poolingaufbau und controlling etwas schwerfälliger und langsamer. Statefull – Session – Binding ist bei einer Maschine ohne ausreichenden RAM nicht zu empfehlen da dieser Prozess pro Client die Beans initialisiert und Clientgebunden ausliefert. Für “schwachbrüstige” – Developer Maschinen greife ich daher die nächste Zeit zum Glassfish als Appserver. Solange jBoss es nicht schafft eine anständige Console zur Konfiguration des Server zur verfügung zu stellen, und mein Rechner auf der Arbeit weiterhin fast den Geist aufgibt sobald man versucht den jBoss zu starten.

Die aktuellste Version von jGrab Web läuft, durch ständigen lerneffekt im Umgang mit jBoss dessen Ressourcen und Pooling Systemen fällt es mir jetzt umso leichter neue Versionen von jGrab Web zu releasen. Zwischenzeitlich lief Version 0.2.5 die aber wenige änderungen zur Version 0.2.1 hatte und daher keien Eintrag “wert” war.

Jetzt gibt es aber wieder ein paar größere Änderungen zum Versionssprung 0.2.7.  Zum einen eine Ajax basiere Suche, also auch der Punkt “finde interessante Feeds” funktioniert nun ohne Probleme, und zum anderen könnt ihr nun in die Headline der Feeds klicken und euch die letzten 20 News ansehen. Die “Ajax” Funktionen die im Hintergrund stehen sind noch nicht ganz optimiert bzw.  wird das CSS in den nächsten Tagen noch angepasst werden. Neben der Suche wurden nun endlich auch die Top 10 der meist aufgerufenen Feeds gelistet.

Aber wir nähern uns der Auslastung vom Server schon fast einem Green-IT Status … max. Leistung aus dem Server heraus zu holen.

Ich werde heute im laufe des Tages die Feeds auf ca. 100 aufstocken um zu sehen das der Server etwas Last verträgt und auch der jGrabServer stabil läuft. Da momentan schon ca. ~ 100.000  Einträge in der Datenbank vorhanden sind, und nur 11 Feeds abgegrast werden. Ich freu mich schon

ZUR SEITE