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.

Es ist schon sehr kuios, eigentlich sollte ein Update der Software Fehler verhindern oder gar einige neue Features beinhalten nicht jedoch wenn man ein Macupdate macht. Habe heute meine neue Software installiert und muss sagen, Eclipse geht nicht mehr. Gleichauf mit dem Neustart des Rechners wollte ich Eclipse laden um sofort wieder an mein kleines Projekt zu gehen und ein paar Kleinigkeiten auszuprobieren. Nix wars! Eclipse wollte einfach nicht, und ließ mich mit einem kleinen Hinweis einfach liegen. Aber für euch die Lösung in ein paar Sekunden. Falls ihr in der Log folgendes findet:

!SESSION 2010-06-17 23:10:59.850 -----------------------------------------------
eclipse.buildId=
java.version=1.6.0_20
java.vendor=Apple Inc.
BootLoader constants: OS=macosx, ARCH=x86, WS=cocoa, NL=de_DE
Framework arguments:  -product org.eclipse.epp.package.jee.product -keyring /Users/lyrixx/.eclipse_keyring -showlocation
Command-line arguments:  -os macosx -ws cocoa -arch x86 -product org.eclipse.epp.package.jee.product -keyring /Users/lyrixx/.eclipse_keyring -showlocation

!ENTRY org.eclipse.osgi 4 0 2010-06-17 23:11:01.568
!MESSAGE Application error
!STACK 1
java.lang.NullPointerException
	at org.eclipse.swt.graphics.Device.getFontList(Device.java:369)
	at org.eclipse.jface.resource.FontRegistry.filterData(FontRegistry.java:465)
	at org.eclipse.jface.resource.FontRegistry.createFont(FontRegistry.java:499)
	at org.eclipse.jface.resource.FontRegistry.defaultFontRecord(FontRegistry.java:563)
	at org.eclipse.jface.resource.FontRegistry.getFontRecord(FontRegistry.java:673)
	at org.eclipse.jface.resource.FontRegistry.get(FontRegistry.java:613)
	at org.eclipse.jface.resource.JFaceResources.getDialogFont(JFaceResources.java:273)
	at org.eclipse.jface.dialogs.Dialog.initializeDialogUnits(Dialog.java:925)
	at org.eclipse.jface.dialogs.TitleAreaDialog.createContents(TitleAreaDialog.java:131)
	at org.eclipse.jface.window.Window.create(Window.java:431)
	at org.eclipse.jface.dialogs.Dialog.create(Dialog.java:1089)
	at org.eclipse.jface.window.Window.open(Window.java:790)
	at org.eclipse.ui.internal.ide.ChooseWorkspaceDialog.prompt(ChooseWorkspaceDialog.java:91)
	at org.eclipse.ui.internal.ide.application.IDEApplication.promptForWorkspace(IDEApplication.java:275)
	at org.eclipse.ui.internal.ide.application.IDEApplication.checkInstanceLocation(IDEApplication.java:223)
	at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:103)
	at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:194)
	at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110)
	at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79)
	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:368)
	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:597)
	at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:559)
	at org.eclipse.equinox.launcher.Main.basicRun(Main.java:514)
	at org.eclipse.equinox.launcher.Main.run(Main.java:1311)

Jetzt zur Lösung. Zwar haben einige mit einem Clean in der Config.ini versucht das Problem zu beheben. Aber bei viele wird das einfach scheitern da die Fenster nicht richtig geladen werden. Meines erachtens geht da bei der Erstinstallation des Updates was schief. Also was tun? Richtig, das Update erneut herunter laden. Hier zum Combo Update für Snow Leopard. Wenn das Update erfolgreich installiert wurde und der Rechner neu gestartet wurde könnt ihr gerne euer Eclipse erneut starten und siehe da, es geht wieder. Dann weiterhin viel Spaß beim Entwicklen.

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.

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

Nachdem die Welt immer kleiner wird durch neue Technologien und sollte man die Realität nicht aus dem Auge verlieren.

Die Welt wir immer komplexer, Infrastruktur und Mensch müssen zusammen arbeiten um eine smartere Welt zu bilden. IBM will jetzt mit viel Einsatz dieses Ziel verwirklichen. Es ist doch nervig für jeden der mal in einer der größeren Städe “tagsüber” unterwegs war. München eine Katastrophe oder dann auch schon in Nürnberg teilweise zum schreien. Was mich verrückt macht, macht auch viele andere wahnsinnig und IBM arbeitet an Lösungen.

Twitter ist mitlerweile ein sehr interessantes Informationsmedium geworden vorallem wenn man Leuten folgt die sich für die neusten Technologien begesitern und auch das Leben.  IBM fängt in den Städen an und versucht durch z.b. intelligente Mautsystemen den Verkehr zu kontrollieren. http://www-05.ibm.com/de/pov/stockholm/ Smart – Cities hört sich doch schon mal ganz spannend an.

Die Finanzkrise war ein deutlicher Weckruf. Schlagartig hat sie uns die Augen für die Gefahren hoch komplexer globaler Systeme geöffnet. Im ersten Jahrzehnt des 21. Jahrhunderts gab es eine ganze Serie solcher Weckrufe. Ihr gemeinsamer Nenner: die globale Integration wird Wirklichkeit – mit zum Teil schwer vorhersehbaren Folgen.

Zu diesen Folgen einer umfassend vernetzten Welt gehören viele Probleme, die uns seit dem Beginn des Jahrzehnts beschäftigen: Klimawandel, Energie, die weltweite Versorgung mit Nahrungsmitteln und Medizin, neue Bedrohungen von Online-Kriminalität bis Terrorismus.

Wir müssen einsehen, dass „vernetzt sein“ alleine nicht genügt. Es genügt nicht, dass die Welt immer „kleiner“ und „flacher“ wird. Zum Glück zeichnet sich noch eine weitere, viel versprechende Entwicklung ab: die Welt wird “smarter”.

Soll heißen, Intelligenz durchdringt zusehends die Abläufe unserer Welt: all die Prozesse, Systeme, Infrastrukturen, die wir brauchen, um Produkte zu entwickeln und zu produzieren; um den Austausch von Waren, Leistungen und Kapital, von Geld, Öl, Wasser oder Informationen zu erleichtern.

Zum Artikel

Google hat die Fehler der vergangenen Monate eingesehn und das G1 als verfrührte und qualitativ schwache Vorstellung eingesehen. Jetzt kommt das HTC Magic mit Android 1.5.

Für Googles Android-Betriebssystem hagelte es Vorschusslorbeeren, viele sahen es als iPhone-Killer. Im Test zeigt das Magic von HTC mit dem brandneuen Android 1.5, ob es die Erwartungen erfüllt.

So, nachdem aber Google was ganz anderes vor hat mit dem HTC Magic als für die Breite Masse tauglich zu sein, will es die Bastler und Entwickler überzeugen. Mit der IDE Eclipse können Just in Time Anwendungen für die Android Smartphones entwickelt werden und somit für einen schnellen Anstieg an Applikationen führen.

Ich gehe davon aus das Google im ersten Sinn die Entwickler ansprechen will, um schnellst möglich mit Apples Appstore konkurieren zu können. Aber mit der zehnfachen Masse an Applikationen im System wird dies noch einige Zeit in anspruch nehmen. Es gibt zwar mehr Entwickler die mit Java arbeiten und auch umgehen können, aber auch beide Plattformen bieten Compiler von z.b. C/C++ Programmen an um schnell Spiele und andere Tools zu releasen.

Einen großen Nachteil sehe ich darin dass die Geräte im Android Markt ziemlich unterschiedlich sind und somit auch von der Hardware verschieden sein werden. Zum anderen könnten Spiele oder ähnliches nicht mit jedem Android Handy gespielt werden oder nur mit div. Hindernissen (Spielgeschwindigkeit, Usability)

Meine Einschätzung ist der Angriff von Android auf das iPhone und dessen Konkurenz spätestens Mitte nächsten Jahres wenn die Stores so weit gefüllt sind. Für die breite Masse ein qualitativ Hochwertiges Produkt geschaffen wird das nicht bei 5mal benutzen droht auseinander zu fallen.  (Apple schafft es schließlich auch)

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.