Es ist ein Graus. Konakart Webshop Software arbeitet per SOAP Schnittstelle einfach nicht mit Netbeans zusammen. Die Java IDE ist sehr einfach und auch das Webservice einbinden ist mit ein paar Klicks erledigt. Ich werde euch, wenn ich noc eine andere Lösung finde darüber informieren. Aber derzeit ist es mir nicht möglich gewesen einen vernünftigen, vorallem schnellen Workaround für das Problem zu schaffen. Auch das anpassen der WSDL Files bringt keinen rechten Erfolg daher einen kurzen Tipp von mir.

Ladet euch Eclipse herunter und startet ein Java Projekt. Führt hierbei den den Webservice Client Punkt aus und includiert beide WSDL Files. Im Normalfall findet ihr sie unter:

http://meinserver.local/konakart/services/KKWebServiceEng?wsdl
http://meinserver.local/konakartadmin/services/KKWSAdmin?

Anschließend könnt ihr per Import in Netbeans das Projekt in euere IDE importieren. Die fehlenden JAR’s werden direkt verlinkt. Dieses könnt ihr in euer Hauptprojekt so einbinden und übernehmen. Es läuft ohne Probleme.

Es ist keine vernünftiger Workaround und eigentlich auch schade das es bisher auch noch keine vernünftige Lösung von Konakart gibt. Evtl. schaffe ich es noch die WSDL Files so anzupassen das sie auch vernünftig im Netbeans verarbeitet wird.

Die JAX-RPC Plugin Erweiterung im Netbeans macht schon einige Fortschritte.

http://wiki.netbeans.org/MovingJaxrpcToUpdateCenter

Aber das gelbe vom Ei ist es noch nicht. Falls jemand schon andere Erfahrungen damit gemacht hat oder wie einfach es sich mit der RMI Schnittstelle arbeitet, lasst es mich bitte wissen.

Kleine Vorschau zum nächsten Blogeintrag:

Thema: Android – Listviews optimieren und mit Viewhandlern arbeiten. Recyceln von Views. Änderungen in Listviews darstellen. Das richtige Ansprechen von Feldern in Listviews. 2 verschiedene Möglichkeiten.

Jahre lang ging es gut. Gute Zusammenarbeit von Community und Konzern. Man profitiert voneinander. Eine riesige Gemeinde an Entwickler scharrt im Garten von Oracle. Der US Konzern vor allem durch seine Datenbank bekannt will den Open Source Java Standard 7 einführen und Entwickler beschneiden. Apache ruft zum Gegenschlag und fordert Entwickler auf gegen die JVM 7 zu stimmen.

Die JCP und Apache Foundation vordern weiterhin ein offenes Java für jeden Entwickler Möglichkeiten bieten seine “Umwelt” selbst zu gestalten ohne Restriktionen von Oracle oder Co. Der Datenbankhersteller ist nicht nur durch die Prozesswelle gegen google’s Android OS in den Medien gelandet. Man gefährdet viel wenn der Konzern nicht nachgeben will. Zum Beweis haben sich schon einige kreative Köpfe von dem US Unternehmen zurückgezogen und suchen Andernorts neue Herausforderungen.

Oracle konnte hingegen im Oktober punkten, als IBM ankündigte, seine bislang unabhängige Java-Strategie zugunsten einer gemeinsamen Zusammenarbeit an Oracles OpenJDK-Projekt aufzugeben.

Bislang galt für mich IBM als einer der Urgesteine und einer der besten Arbeitgeber auf der Welt. Förderer modernster Technologien mit großen Denkern tief im Unternehmen verwurzelt. Durch ihre PR Aktionen eines smarter Planets eigentlich überall in den Medie egal ob Zeitschrift oder Werbespot. Jetzt will sich IBM aber auf die Seite von Oracle, ich will nicht des Bösen sagen aber in diesem Moment scheint es so zu sein schlagen.

Ein Artikel von Heise zum Geschehen.

So, mich hat die letzen paar Tage mal wieder ein kleines Thema gequält und überaus viele Nerven gekostet. Ein alternatedocroot wie es so schön heißt im Glassfish. Im Endeffekt ist, wenn man die Lösung kennt es ganz einfach zu handlen. Ein Alternatedocroot ist nichts weiter als eine Verklinkung auf ein anderes Verzeichnis irgendwo auf den Platten der Server. Für meine Zwecke z.b. für eine Bilddatenbank und unmengen immer wieder wechselnder Files die nicht mit deployed werden können.

Glassfish bietet dazu einiges Möglichkeiten. In den virtuellen Servern kann man das Property anlegen, was relativ unelegant beim Deploy über Netbeans z.B. ist.

Wenn ich allerdings meine Daten in der sun-web.xml mitgebe, wird es ebenfalls erkannt und ich kann jederzeit ohne die Administrative Console des Glassfishes anlangen zu müssen meine alternatedocroots festlegen.

Der alternatedocroot oder Redirect auf einen lokalen Ordner, kann jenachdem wie er definiert wird verwendet werden. Man kann einfache Filterregeln mit übergeben, in denen man z.b. nur *.jpg Files aufrufen kann.

Das mitgegebene Property sieht wie folgt aus:

<property name=”alternatedocroot_1″ value=”from=/foto/* dir=/var/www” />

Man darf nicht direkt auf den neuen pfad verlinken sondern auf seinen masterfolder. In diesem Fall muss im Ordner /var/www der Ordner foto erstellt werden um über z.b. http://localhost:8080/meinProjekt/foto alle Fotos anzusprechen die dort liegen.

Nichts Neues ist der Einsatz von Thin Clients in Unternehmen um kostengünstig Terminalclients anzubieten. Neue Mitarbeiter können so schnell und effektiv im Unternehmen aufgenommen werden. Jedoch kommt hier wieder der Einsatz moderner Technologie. Webservices, Cloud’s und Remoteapplications.
Google bietet mit dem Collaboration Werkzeug Wave eine Möglichkeit an schnell Prozesse und Projekte zu planen und deren Abläufe zu bestimmen. In Gruppen können Mitarbeiter Dokumente, Bilder etc. tauschen.
Amazon bietet mit einem gigantischen Cloudservice Rechenleistung an und versucht somit die Power zu Zentralisieren. Somit benötigt ein Unternehmen keine eigenen Server die zu 20% ausgelastet sind und den Rest des Tages warme Luft produzieren. Da bekommt der Begriff “On Demand” ein ganz neues Bild. Nicht nur Software die auf den Kunden zugeschnitten wurde, auch Rechenleistung die dann abrufbar ist, wenn man sie braucht.
Jetzt kommt auch IBM ins Spiel. Big Blue wirft wieder einen neuen Begriff auf den Markt, “Smarter Planet” nennt sich das Projekt des Riesen. Smart, was versteht der Konzern darunter. Wenn einfach, einfach einfach ist. Man beschäftigt sich nicht nur mit der Austattung von Städten mit intelligenten Systemen. Man arbeitet sich bis auf die Workstation vor. Wie kann ein Mitarbeiter effektiver werden? Warum benötigt man so viel Zeit zur Suche nach Daten? …
Ich selbst Glaube, das es auf die unterschiedliche Arbeitsweisen zurück zu führen ist. Katastrophale Ordnung und wüstes Speichern von Daten. Kein System, keine Ordnung und meistens, vor allem im Mittelstand unzureichende Software oder auch Kenntnisse zum Einsatz dieser. Es ist viel Arbeit ein Unternehmen mit richtiger Software auszustatten. Denn wachsende Aufgabengebiete möchten auch schnellst möglich abgedeckt sein. Je nach Spezialisierung der Software ist es aber nicht so einfach möglich.
Flexibel ist man daher per Webapplikation. Je mehr auf den Browser abgebildet werden kann, desto schlankere Clients können verwendet werden, desto höher ist die Auslastung der hauseigenen Server und man spart einiges an Energie und Lizenzkosten, installierbare Software.

Es ist mal wieder soweit. Die Version 6.7 von Netbeans noch nicht all zu lange auf dem Markt und schon gibts eine neue Beta. 6.8, das neue Glanzstück der von SUN präsentierten IDE beinhaltet den neuen JEE6 Standard. Somit habe ich mir gerade einmal die akteulle Entwicklungsumgebogen gedownloaded und werde im Laufe des Tages oder auch übers Wochenende mich in den neuen Standard einarbeiten.

Ich habe mir bei JavaThreads.de schon mal kurz den Blogeintrag angesehn und kurz überflogen. Folgendes ist dort zu lesen und auch die SUN Präsentation sieht sehr vielversprechend aus. An und für sich soll alles wieder einen Schritt einfacher werden. Die Verbindung der EJB zu JSP und anderen Frameworks soll um einiges einfacher werden und dass dank einer größeren Annotationsbibiliothek.

Hier der Beitrag von JavaThreads.de

Wer wissen möchte in welche Richtung es in Java EE 6 geht wird nicht darum herumkommen sich mit dem JSR 299, auch Web Beans genannt, zu beschäftigen. Der Fokus des JSR 299 liegt auf der Vereinfachung von Dependency Injection in einer JEE Umgebung zwischen allen Schichten und diese auf vielfältige Art und Weise. Vor allem das Problem von der View (JSF oder JSP) auf EJBs einfach zugreifen zu können soll damit behoben werden aber auch vieles mehr vereinfacht. Web Beans selbst beschreibt sich auf der Web Beans Webseite in einem Satz so

Und der restiche Artikel hier zu finden.

Als Application Server wird der Glassfish 3.1 Prelude verwendet mit komplett integriertem JEE6 Standard.

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 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.

Nachdem ich jetzt auch weiter gekommen mit der jGrab Console, habe ich mich mal rangesetzt und den Server dementsprechend modifiziert.

Es werden nun folgendes Formate ohne Probleme unterstützt und laufen 1A, auf meinem lokalten Testsystem werden zur zeit 15 Feeds gegrabbt.

Unterstützte Formate:

RSS 0.9/1.0

RSS 2.0

ATOM

Die Feeds werden wie gewohnt per XML gesteuert, gegrabbte Einträge anschließend in der Datenbank gespeichert. Zur zeit steht eine MySql 5.1 Datenbank zur verfügung. Es können aber durch die modulare Programmierung jegliche Datenbanken im Background laufen.

Ich werde demnächst die erste Alpha veröffentlichen um schon einmal einen kleinen Einblick in den Funktionsumfang der Console zu gewähren, bzw. aktiv verwendbar zu machen. Bisherl aufen die lokalen Tests sehr gut.

Ich habe in den letzen paar Minuten mal Visio ausgepackt und versucht es etwas zu verdeutlichen. Meine ersten Versuche mit Visio un dem Flussdiagramm, schaut doch schon mal recht unübersichtlich aus. Fehlen nur noch ein paar Fachbegriffe und schon versteht einen die Welt nicht mehr.

Lasst euch überraschen was noch alles kommt, ich habe noch einige Ideen und falls es die Zeit zulässt werde ich diese auch umsetzen.