JDeveloper – Austausch des Integrated WebLogic Server

Einer der Vorteile des JDeveloper ist der integrierte WebLogic Server. Dadurch können Anwendungen schnell gestartet und getestet werden. Der einzige Nachteil dabei ist, dass die Server Installation gut versteckt ist. In der Regel befindet sich der WebLogic Server im Benutzer Homer Verzeichnis und AppData – Roaming – JDeveloper. Neben dem Nachteil, dass hier der Platz unkontrolliert wachsen kann, ist es auch schwierig, die Einstellungen zu überwachen und notwendige Patches einzuspielen. Gerade für ADF ist es sinnvoll mit den aktuellsten Patches zu arbeiten. Natürlich können weitere Integrierte WebLogic Server im JDeveloper eingebunden werden. Aber es wäre schon gut, wenn mit CTRL-F11 weiterhin die JSP oder ADF Anwendung schnell und einfach gestartet werden könnte. Der Trick ist eigentlich ganz einfach und es geht wirklich schnell.

Voraussetzung für einen neuen Integrated WebLogic Server ist zum einen die Weblogic Server Installation auf den gleichen Rechner. Der JDeveloper soll den Server automatisch starten und stoppen können. Hierfür werden WLST Skripte aus dem JDeveloper gestartet, die Zugang zum Domain Verzeichnis benötigen. Zum anderen muss eine Domain vorhanden sein, die ich als Integrated WebLogic Server Instance nutzen will. Zum Anlegen eines Integrated WebLogic Server, über den der JDeveloper die Kontrolle haben soll, wird das Domain Verzeichnis benötigt. Ein anderen Punkt, der vorher durchgeführt sein muss: Es muss nach der Installation des JDeveloper einmal der mitgelieferte Integrated WebLogic Server gestartet worden sein. Dadurch wird eine Default Domain im Benutzer-JDevloper-System Verzeichnis angelegt, die in den internen Konfigurationsdateien eingetragen wird. Also: kurz eine simple JSP schreiben und starten. Die Konfiguration kann später wieder gelöscht werden. Wichtig: Bevor eine neue Integrated WebLogic Server Instanz angelegt werden kann, muss die bestehende gestoppt werden.

Der erste Punkt zum Anlegen ist der Aufruf der Application Server Navigator View. Dies ist ganz wichtig, da nur hier der Integrated WebLogic Server angelegt werden kann. Beim Entwickeln arbeitet man in der Regel über die Resource Palette View. Diese beinhaltet jedoch nicht die Funktionalität. In der Übersicht der Application Servers sollte sich der Integrated WebLogic Server befinden. Dies ist der Eintrag von dem mitgelieferten WebLogic Installation. Dieser muss zuerst gelöscht werden.

Als nächstes wird an dieser Stelle ein neuer Application Server eingerichtet (rechte Maus-Taste – „New Application Server …“). Auf der ersten Seite muss „Integrated Server“ ausgewählt werden. Unter Usage erscheinen dann drei weitere Punkte.

Auf der zweiten Seite ist der Name entscheidend. Hier muss „IntegratedWebLogicServer“ eingetragen werden. Nur so funktioniert es mit der CTRL-F11 Taste. Ferner muss die Checkbox für die JDeveloper Kontrolle ausgewählt werden. Damit können dann auch das Domain Verzeichnis und der Server ausgewählt werden. Unter Domain Verzeichnis wird das Verzeichnis verstanden, das meine Domain beinhaltet, zum Beispiel

C:\Anwendungen\Oracle\Middleware\WLS_DOMAINS\domains\JDeveloperDomain

clip_image002

In diesem Verzeichnis muss ein Verzeichnis „servers“ vorhanden sein. Bei der Auswahl der Server Instance springt das Auswahlmenu genau auf dieses Verzeichnis. Als Server Instance muss eines der Verzeichnisse angegeben werden.

Danach und nach der Eingabe vom Administrator Account muss noch die Host-Konfiguration angegeben werden. An dieser Stelle erfolgt dann der Name der WebLogic Domain. Der Rechnername und Port wird benötigt, um vom JDeveloper Web Anwendungen direkt starten zu können.

Anschließend kann mit Finish die Eingabe beendet werden. Ein Test ist nicht möglich. Da der JDeveloper den WebLogic Server starten und stoppen soll, ist die Instanz noch nicht gestartet und kann somit nicht getestet werden.

Zum Schluss kann nochmals eine JSP zum Testen gestartet werden. Im Fenster mit den Meldungen müssen nun die Verzeichnisse der angegebenen WebLogic Server Installation erscheinen.

Um Platz zu sparen, kann nun die erste Domain Installation gelöscht werden. In der Regel ist das Verzeichnis um die 100 MByte groß. es liegt unter

c:\Users\<Benutzer>\AppData\Roaming\JDeveloper

Leider kann sie nicht so einfach gelöscht werden. Der JDeveloper prüft das DefaultServer Verzeichnis. Ist nicht mehr vorhanden erfolgt erneut die Intergrated WebLogic Server Domain Installation. Was eigentlich nicht schlimm ist, da nur die Konfigurationen erstellt werden. Erst beim Starten werden Anwendungen deployed, die den eigentlichen Platz benötigen. Bei mir habe ich alles unter dem Verzeichnis

…\JDeveloper\system11.1.1.7.40.64.93\DefaultDomain\servers\DefaultServer

gelöscht (dort stecken die 100 MBytes).

Viel Spaß beim Testen Zwinkerndes Smiley

Eines sei noch bemerkt: Dem JDeveloper ist die Version des WebLogic Server in erster Linie egal. Bei dem JDeveloper 11.1.1.7 kann ich damit auch den WebLogic Server 12c hinterlegen 😉

Veröffentlicht unter JDeveloper, Technik, WebLogic Server | Kommentar hinterlassen

SQLPlus Variable per SQL Abfrage

SQLPlus der Oracle Datenbank ist ein mächtiges Tool. In den meisten Fällen wird nur ein Teil der Features genutzt. Etwas was ich oft in Reports nutze ist das Füllen von Variablen über SQL Befehle.

Ein Beispiel hierfür ist Erstellen von Reports in Dateien. Um den Dateinamen eindeutig zu halten nutze ich das Datum mit der Zeitangabe. In Unix ist ist es ganz einfach, dort setze ich eine Variable und lenkte die Ausgabe dann um:

$> export LOGFILE=REPORT_`date +“%Y%m%d_%H%M%S“`.log
$> echo $LOGFILE
REPORT_20140506_115225.log
$> echo „Hello World“ >> $LOGFILE
$> more $LOGFILE
Hello World

In SQLPlus wird nicht mit Umlenkung gearbeitet, sondern mit Spool. Das Umlenken ist jedoch ähnlich einfach.

set feedback off
set heading off
column d1 new_value FILEDATE noprint
select ‚REPORT_‘ ||
    to_char(sysdate, ‚yyyymmddhh24miss‘) || ‚.log‘ d1
   
from dual;
prompt &FILEDATE
spool &FILEDATE
prompt Hello World
— meine SQL Abfragen
spool off

Die ersten beiden zeilen dienen dazu, Ausgaben beim SQL Select zu unterdrücken. Auch wenn ich eine Spalte in SQL als noprint angebe, wird der SQL ausgeführt und das Ergebnis (in dem Fall nur Leerzeilen) angezeigt. Anschließend setze das Format der Spalte d1, die den Namen meiner Log-Dateiu sein soll. Mit noprint sage ich, dass sie nicht ausgegeben werden soll, und mit new_value sage ich, dass das Ergebnis der neue Wert für die Variable FILEDATE sein soll. Nun muss nur noch der Wert berechnet werden. Dies geschieht durch ein Select über dual. Und das war es dann eigentlich schon. Mit spool mache ich die Umlenkung und spool off beende ich sie.

Ein anderes Beispiel ist die Berechnung einer Zeitdauer. Bei den Reports möchte ich immer gerne wissen, wie lange er dauert. Bei Oracle BPEL Purging Reports können Statements leicht einige Minuten dauern, wenn die SQL Anweisungen nicht sorgfältig gewählt werden auch mal einige Stunden. Mein Skript sieht wie folgt aus:

set feedback off
set heading off
set verify off
column d1 new_value STARTT noprint
column d2 new_value ENDT noprint
select (((extract (day from p_interval) * 24
    + extract (hour from p_interval) ) * 60
    + extract (minute from p_interval)) * 60
    + extract (second from p_interval)) * 1000 d1
    from (select systimestamp – to_timestamp(‚1.5.2014‘, ‚dd.mm.yyyy‘) p_interval from dual);
set feedback on
set heading on
set verify on
— meine SQL Anweisungen
select count(*) from user_source where text like ‚%while%‘;
set feedback off
set heading off
set verify off
select trunc((((extract (day from p_interval) * 24
    + extract (hour from p_interval) ) * 60
    + extract (minute from p_interval)) * 60
    + extract (second from p_interval)) * 1000 – &STARTT) d2
from (select systimestamp – to_timestamp(‚1.5.2014‘, ‚dd.mm.yyyy‘) p_interval from dual);
prompt Der Report dauerte &ENDT msec

Zuerst setze ich einige Werte, um die SQL Ausgaben zu minimieren. Dann definiere ich zwei Variablen STARTT und ENDT für das Startdatum und den zum Schluss berechneten Wert. Beim SQL berechne ich dann die Millisekunden vom Zeitpunkt 01.05.2014 (ginge natürlich auch vom 01.07.1970, was normal üblich ist). Anschließend führe ich meine SQL Anweisungen durch. Als Beispiel nehme ich das Durchsuchen von PLSQL Code nach „while“ (dauert einwenig, sonst ist die Datenbank einfach zu schnell ;-)) Zum Schluss berechne ich nochmals das gleiche Zeitinterval, ziehe jedoch gleich den Startwert ab. Als Ergebnis bekomme ich die Millisekunden. Da die Oracle Datenbank auf Linux mit Nanosekunden arbeitet, werfe ich die Nachkommastellen einfach weg. Die Ausgabe sieht dann bei mir wie folgt aus:

SQL> @SimpleReport
COUNT(*)
———-
76
1 row selected.
Der Report dauerte 6584 msec

Bei einem Select macht es keinen Sinn. Hier ist das SQL Timing (set tining on) viel besser. Wenn jedoch einige zig verschiedene Operationen durchgeführt werden und eventuell bei Lasttests die Daten für Auswertungen benötigt werden, ist das Berechnen in den Reports vorteilhaft.

Beim letzten Beispiel nutze ich die Variable, um SQL Abfragen zu optimieren. Manche Abfragen machen nur Sinn, falls auch Daten vorhanden sind. Kann nicht darauf zugegriffen werden muss in der Regel eine EXISTS Sub-Abfrage eingebaut werden (oder man bekommt einen Fehler). Um nicht bei jeder Abfrage diese EXISTS Sub-Abfrage durchführen zu müssen, kann das Ergebnis in eine Variable gespeichert werden.

set feedback off
set heading off
set timing on
column v1 new_value VALUE1 noprint
select count(*) v1 from user_source
    where text like ‚%patch 912-%‘;
prompt Anzahl Eintraege mit Patch: &VALUE1
set feedback on
set heading on
select text from user_source
    where (&VALUE1 > 0) and text like ‚%patch 912-123455%‘;
select text from user_source
    where (&VALUE1 > 0) and text like ‚%patch 912-257455%‘;

In diesem Skript prüfe ich zuerst, ob in den Sourcen der Patch 912 eingespielt wurde. Durch den like Befehl dauert dies 5 bis 10 Sekunden. Erst danach suche ich dann die einzelnen Stellen, die überprüfen will. Ohne das Überprüfen mittels der Variable würde jede SQL Abfrage 5-10 Sekunden dauern, so braucht – falls kein Patch eingespielt wurde – nur die erste SQL Anweisung die 5-10 Sekunden, alle anderen (dank der Optimierung) nur wenige Millisekunden.

Sei noch gesagt: SQLPlus kann Werte auch in Bind-Variablen halten. Dies sind jedoch PLSQL Variablen, die in SQLPlus Befehlen nicht verwendet werden können. Mein obiges Beispiel könnte diese jedoch verwenden:

variable value1 number
set feedback off
set heading off
set timing on
column v1 noprint
exec select nvl(count(*), 0) v1 into :value1 from user_source where text like ‚%patch%‘;
prompt Anzahl Eintraege mit Patch:
print value1
set feedback on
set heading on
select text from user_source
where (:value1 > 0) and text like ‚%patch 123455%‘;
select text from user_source
where (:value1 > 0) and text like ‚%patch 257455%‘;
….

Wichtig: Beim Ausführen des ersten SQL Befehls wird eine PLSQL Routine überführt (durch exec wird der Befehl in begin – end; umschlossen). Dadurch kann der Wert in die Bind-Variable gespeichert werden. Der Befehl muss in einer Zeile geschrieben werden.

Viel Spaß beim Probieren Zwinkerndes Smiley

Veröffentlicht unter PLSQL/SQL, Technik | Kommentar hinterlassen

JDeveloper: Welche WebLogic Version bitte?

In den meisten Fällen weiß man ganz genau, welche WebLogic Version mit dem JDeveloper ausgeliefert wird. Doch gerade bei neuen Versionen ist man nicht so sicher. Eine einfache Methode dies herauszufinden ist, eine JSP zu schreiben, die die Version von WebLogic  ausgibt.

In meine früheren Artikel https://volbers.wordpress.com/2011/06/17/weblogic-version-bestimmen/ habe ich bereits gezeigt, wie die WebLogic Version über einen direkten Java Aufruf zu bestimmen ist. Beim JDeveloper kann dies einfach über eine JSP erfolgen. Mein Beispiel habe ich mit der JDeveloper Version 12.1.2 durchgeführt. In Java sähe der Aufruf wie folgt aus. Zum Beispiel:

$>java -cp ./weblogic.jar weblogic.version

WebLogic Server 12.1.2.0.0 Fri Jun 7 15:16:15 PDT 2013 1530982 WLS_12.1.2.0.0_GENERIC_130607.1100

Use ‚weblogic.version -verbose‘ to get subsystem information

Use ‚weblogic.utils.Versions‘ to get version information for all modules

Dies möchte ich nun in einer JSP implementieren. Das Gute bei den JSPs ist, dass sie einfach geschrieben und dann mittels Control-F11 gestartet werden können. Im Hintergrund startet der JDeveloper dann seinen „Intergrated WebLogic Server“ und zeigt das Ergebnis an.

WebLogic Server 12.1.2.0.0 Fri Jun 7 15:16:15 PDT 2013 1530982 WLS_12.1.2.0.0_GENERIC_130607.1100

Oder bei der einfachen Ausgabe der Release Nummer:

12.1.2.0.0

Um zu wissen, wo sich die WebLogic Installation befindet, kann natürlich auch das Domain Home ausgegeben werden (beim JDeveloper finde ich immer schwierig dies herauszufinden, da alles automatisch installiert wird Zwinkerndes Smiley ). In einem anderen Artikel werde ich noch beschreiben, wie der Integrated WebLogic Server vom JDeveloper geändert werden kann. Dies ist bei dem JDeveloepr 11.1.1.7 unter Umständen sinnvoll, da er noch den WebLogic Server 10.3.5 beinhaltet. Aber auch, wenn doch öfters Patches benötigt werden, kann eine Umstellung des Integrated Weblogic Server einen Nutzen haben.

Meine komplette JSP sieht nun wie folgt aus:

<!DOCTYPE HTML PUBLIC „-//W3C//DTD HTML 4.01 Transitional//EN“
http://www.w3.org/TR/html4/loose.dtd“&gt;

<%@ page contentType=“text/html;charset=windows-1252″%>
<%@ page import=“weblogic.version“ %>
<html>
  <head>
    <meta http-equiv=“Content-Type“ content=“text/html;charset=windows-1252″/>
    <title>index</title>
  </head>
  <body>
    The version of the WebLogic server is: <br>
    <%= version.getBuildVersion() %>
    <br>=====================================<br>
    The short version number is:
    <%= version.getReleaseBuildVersion() %>
    <br>=====================================<br>
    The domain home directory is:
    <%= System.getenv(„DOMAIN_HOME“) %>
  </body>
</html>

Zuerst muss ich die Klasse “version” (ist leider klein geschrieben) importieren. Im Ergebnis kann ich verschiedene static Methoden aufrufen, die mir einen String zurückliefern. Als letzte Methode hole ich mir die System Umgebungsvariable für das Domain Home. Als Ergebnis erhalte ich dann folgendes:

The version of the WebLogic server is:
WebLogic Server 12.1.2.0.0 Fri Jun 7 15:16:15 PDT 2013 1530982 WLS_12.1.2.0.0_GENERIC_130607.1100
=====================================
The short version number is: 12.1.2.0.0
=====================================
The domain home directory is: C:\Users\developer\AppData\Roaming\JDEVEL~1\SYSTEM~1.68\DEFAUL~1

Viel Spaß beim Probieren Zwinkerndes Smiley

Veröffentlicht unter Java, Technik, WebLogic Server | Kommentar hinterlassen

Java 8 kommt am 18. März

Nun ist es endlich so weit: Die neue Java SE 8 Version soll endlich am 18. März kommen.
Die Beschreibung der neuen Version ist in JSR-337: Java SE 8 Release Contents beschrieben.
Viele Entwickler haben schon lange darauf gewartet. Hauptaugenmerk wurde auf die Lambda Expressions gelegt. Damit ist es endlich möglich Funktionen beziehungswese Funkionsbausteine oder Anonyme Funktionen zu übergeben. Eine andere tolle Änderung sind Erweiterungen für die Date und Time API. Mit der neuen Klasse „Clock“ kann auf die aktuelle Zeit mit einer Zeitzone zugegriffen werden.
Eine Übersicht der Änderungen steht in der JSR-337:
Language:
– Access to Parameter Names at Runtime (JSR 269 MR, 337)
– Add Javadoc to javax.tools (JSR 199 MR)
– Annotations on Java Types (JSR 308)
– Generalized Target-Type Inference (JSR 335)
– Lambda Expressions & Virtual Extension Methods (JSR 269 MR, 335)
– Repeating Annotations (JSR 269 MR, 337)
Core Libraries
– Base64 Encoding & Decoding
– Bulk Data Operations for Collections (JSR 335)
– Concurrency Updates
– Date & Time API (JSR 310)
– Enhance Core Libraries with Lambda (JSR 335)
– JDBC 4.2 (JSR 114 MR, 221 MR)
– Parallel Array Sorting
– Statically-Linked JNI Libraries
I18n:
– BCP 47 Locale Matching
– Unicode 6.2
Networking:
– HTTP URL Permissions
Security:
– Configurable Secure Random-Number Generation
– Enhance the Certificate Revocation-Checking API
– Limited doPrivileged
– NSA Suite B Cryptographic Algorithms
– TLS Server Name Indication (SNI) Extension
XML:
– Restrict Fetching of External XML Resources (JSR 206 MR)
Platform:
– Compact Profiles (JSR 3 MR, 160 MR, 337)
– Prepare for Modularization (JSR 173 MR, 206 MR, 337)

Die Änderungen der Java Spezifikation werden sicherlich nicht so schnell in die Produkte (wie zum Beispiel Oracle WebLogic Server) einfließen können, jedoch wird es nicht lange dauern, bis der WebLogic Server auch mit Java 8 betrieben werden kann. Und damit können dann die neuen Features genutzt werden.

Veröffentlicht unter Java, Technik | Kommentar hinterlassen

JDeveloper OPatch mit Hindernissen

In der Regel ist beim JDeveloper es nicht notwendig, dass ein Patch eingespielt werden muss. Doch in manchen Fällen lässt es sich nicht vermeiden. Bei uns wurde es notwendig, als wir ein größeren Patch für ADF bekommen haben. Dieser beinhaltet nicht nur Runtime Bibliotheken sondern auch Änderungen bei den Design Klassen. Somit muss er im JDeveloper Home eingespielt werden.

Wie bei den meisten Projekten läuft auch bei uns der JDeveloper auf ein Windows System. Nach dem Entpacken des Patches liest man im README.txt, dass der Patch für zwei Oracle-Homes erstellt wurde: für MW_HOME/oracle_common und MW_HOME/jdeveloper und dafür zwei verschiedene Unterverzeichnisse existieren, einmal das normale opatch und das für den JDeveloper erstellte sa_opatch.

In dem README.txt des sa_opatch Verzeichnisses lesen wir dann, dass die Installation nur mit dem Standalone OPatch durchgeführt werden kann. Dieser kann mit dem Patch 5912518 heruntergeladen und entpacken werden.

Beim Starten des Standalone Patches muss jedoch einiges beachtet werden. Zum einen muss das Oracle Home gesetzt werden.

$> set ORACLE_HOME=C:\111160\JDev\jdeveloper

Zum anderen muss das JAVA_HOME gesetzt werden.

$> set JAVA_HOME=C:\111160\JDK\java

Bei diesem Schritt kommen bereits zwei Schwierigkeiten. Der erste Punkt: Es nützt nicht JAVA_HOME und den Pfad für Java zu setzten. OPatch findet nicht das java.exe. Erst wenn die Option -jre angegeben wird, lässt es sich starten. Die zweite Schwierigkeit ist, dass Parameter keine Leerzeichen beinhalten dürfen. Somit kann in dem JAVA_HOME Verzeichnis keine Leerzeichen sein. So etwas wie “C:\Program Files\Java” geht leider nicht.

Mit dem richtigen Pfad und dem richtigen Aufruf sollte es jedoch funktionieren.

$> opatch version -jre %JAVA_HOME%
Invoking OPatch 11.1.0.0.1

OPatch Version: 11.1.0.0.1

OPatch succeeded.

Da zur Installation in das Patch Verzeichnis gewechselt werden muss, muss noch der Pfad auf opatch gesetzt werden.

$> opatch apply -jre %JAVA_HOME%
Invoking OPatch 11.1.0.0.1

Oracle Interim Patch-Installationsprogramm Version 11.1.0.0.1
Copyright (c) 2011, Oracle Corporation.  All rights reserved. Alle Rechte vorbehalten.

Oracle-Standardverzeichnis            : c:\111160\JDev\jdeveloper
Oracle-Standardbestandsverzeichnis  : c:\111160\JDev\jdeveloper\sainventory
OPatch-Version         : 11.1.0.0.1
Produktinformation    : c:\111160\JDev\jdeveloper\product.xml
Speicherort der Log-Datei      : c:\111160\JDev\jdeveloper\cfgtoollogs\opatch\opatch2013-10-30_13-50-50PM.log

Patch history file: c:\111160\JDev\jdeveloper\cfgtoollogs\opatch\opatch_history.txt

ApplySession Interim-Patch ‚17377999‘ wird für OH ‚c:\111160\JDev\jdeveloper‘ angewendet

Running prerequisite checks…

Fahren Sie Oracle-Instanzen herunter, die aus diesem ORACLE_HOME auf dem lokalen System gestartet werden.
(Oracle-Standardverzeichnis = ‚c:\111160\JDev\jdeveloper‘)

Ist das lokale System für das Patching bereit? [y|n]
y
User Responded with: Y
Backup von Dateien und Bestand (nicht für automatisches Rollback) für das Oracle-Standardverzeichnis erfolgt
Backup von Dateien, die von dem Patch ‚17377999‘ für Restore betroffen sind, erfolgt. Dies kann etwas länger dauern…
Backup von Dateien, die von dem Patch ‚17377999‘ für Rollback betroffen sind, erfolgt. Dies kann etwas länger dauern…

Patching von Komponente oracle.jdeveloper, 11.1.1.6.0…
Datei wird in „c:\111160\JDev\jdeveloper\adfv\jlib\oracle-page-templates-ext.jar“ kopiert
Datei wird in „c:\111160\JDev\jdeveloper\adfv\jlib\oracle-page-templates.jar“ kopiert
Datei wird in „c:\111160\JDev\jdeveloper\jlib\oracle-page-templates.jar“ kopiert
ApplySession Interim-Patch ‚17377999‘ wird zu Bestand hinzugefügt

Verifying the update…
Inventory check failed: Patch ID 17377999 is NOT registered in Oracle Home inventory.
Files check OK: Files from Patch ID 17377999 are present in Oracle Home.
ApplySession nicht erfolgreich: ApplySession in Systemänderungsphase nicht erfolgreich… ‚Verification of patch failed: Patch is not found in the Inventory. ‚
OPatch versucht, das System zurückzuschreiben…
Oracle-Standardverzeichnis wird zurückgeschrieben…
OPatch konnte das System zurückschreiben. Überprüfen Sie die Log-Datei und den Zeitstempel jeder Datei, um sicherzustellen, dass sich das System in dem Status vor Anwendung des Patches befindet.
——————————————————————————–
The following warnings have occurred during OPatch execution:
1) OUI-67124:Inventory check failed: Patch ID 17377999 is NOT registered in Oracle Home inventory.
——————————————————————————–

OPatch failed with error code = 73

Die Fehlermeldung hat nichts damit zu tun, dass das Inventory Verzeichnis nicht gefunden wird, oder dass das Oracle Home nicht registriert ist. Es ist einfach das Problem, dass OPatch eine englisch sprachige Umgebung braucht.

Eine Möglichkeit ist es, über es über dem Control Panel, Region und Languages die Sprache zu ändern. Nur dies ändert natürlich das komplette Windows die Sprache. Eine andere Möglichkeit ist es, die Sprache bei OPatch zu setzen. Nur dies ist leider nicht dokumentiert.

OPatch kennt einige Environment Variablen, die es ausliest. Eine Variable ist zum Beispiel die Debug Variable.

$> set OPATCH_DEBUG=TRUE

Diese ist ganz nützlich, um zu sehen, was OPatch alles aufruft. Aber es gibt auch eine Variable, um weitere Java System Properties OPatch mitzugeben.

$> set _JAVA_OPTIONS=-Duser.language=en

Wichtig sind der Unterstrich am Anfang und das S am Ende Zwinkerndes Smiley Der Aufruf vom Apply sieht dann wie folgt aus:

$> opatch apply -jre %JAVA_HOME%
Picked up _JAVA_OPTIONS: -Duser.language=en
Invoking OPatch 11.1.0.0.1

Oracle Interim Patch Installer version 11.1.0.0.1
Copyright (c) 2011, Oracle Corporation.  All rights reserved.

Oracle Home            : c:\111160\JDev\jdeveloper
Oracle Home Inventory  : c:\111160\JDev\jdeveloper\sainventory
OPatch version         : 11.1.0.0.1
Product information    : c:\111160\JDev\jdeveloper\product.xml
Log file location      : c:\111160\JDev\jdeveloper\cfgtoollogs\opatch\opatch2013-10-30_14-08-42PM.log

Patch history file: c:\111160\JDev\jdeveloper\cfgtoollogs\opatch\opatch_history.txt

ApplySession applying interim patch ‚17377999‘ to OH ‚c:\111160\JDev\jdeveloper‘
Interim patch 17377999 is a superset of the patch(es) [  17377999 ] in the Oracle Home
OPatch will rollback the subset patches and apply the given patch.

Running prerequisite checks…

Please shutdown Oracle instances running out of this ORACLE_HOME on the local system.
(Oracle Home = ‚c:\111160\JDev\jdeveloper‘)

Is the local system ready for patching? [y|n]
y
User Responded with: Y
Backing up files and inventory (not for auto-rollback) for the Oracle Home
Backing up files affected by the patch ‚17377999‘ for restore. This might take a while…
Backing up files affected by the patch ‚17377999‘ for restore. This might take a while…
ApplySession rolling back interim patch ‚17377999‘ from OH ‚c:\111160\JDev\jdeveloper‘

Patching component oracle.jdeveloper, 11.1.1.6.0…
Copying file to „c:\111160\JDev\jdeveloper\adfv\jlib\oracle-page-templates-ext.jar“
Copying file to „c:\111160\JDev\jdeveloper\adfv\jlib\oracle-page-templates.jar“
Copying file to „c:\111160\JDev\jdeveloper\jlib\oracle-page-templates.jar“
RollbackSession removing interim patch ‚17377999‘ from inventory

OPatch back to application of the patch ‚17377999‘ after auto-rollback.

Backing up files affected by the patch ‚17377999‘ for rollback. This might take a while…

Patching component oracle.jdeveloper, 11.1.1.6.0…
Copying file to „c:\111160\JDev\jdeveloper\adfv\jlib\oracle-page-templates-ext.jar“
Copying file to „c:\111160\JDev\jdeveloper\adfv\jlib\oracle-page-templates.jar“
Copying file to „c:\111160\JDev\jdeveloper\jlib\oracle-page-templates.jar“
ApplySession adding interim patch ‚17377999‘ to inventory

Verifying the update…
Inventory check OK: Patch ID 17377999 is registered in Oracle Home inventory with proper meta-data.
Files check OK: Files from Patch ID 17377999 are present in Oracle Home.

The local system has been patched and can be restarted.

——————————————————————————–
The following warnings have occurred during OPatch execution:
1) OUI-67620:Interim patch 17377999 is a superset of the patch(es) [  17377999 ] in the Oracle Home
——————————————————————————–
OPatch Session completed with warnings.

OPatch completed with warnings.

Damit sind die Hindernisse des OPatch beim JDeveloper umgangen. Viel Spaß beim Testen Zwinkerndes Smiley

Ein wichtiger Punkt sei jedoch noch gesagt. Patche und Patche sind natürlich unterschiedlich. Beim JDeveloper sollte man bei den Patches immer zweimal hinsehen. Wie oben erwähnt war unser Patch für zwei Oracle Home Verzeichnisse zusammengestellt, für das jdeveloper und das oracle_common Verzeichnis. Man sollte annehmen, dass die Installation für den JDeveloper nur einmal durchgeführt werden muss, für das jedeveloper Verzeichnis. Dies hängt jedoch sehr vom Patch ab. In unserem Beispiel muss der Patch auch in das oracle_common des JDeveloper eingespielt werden. Analog anderen Oracle Installation hat auch JDeveloper ein oracle_common Verzeichnis. Hier werden die ADF Runtime Bibliotheken installiert. Diese sind spätestens beim Testen mit dem Integrated WebLogic Server notwendig.

Veröffentlicht unter ADF, Java, JDeveloper, Technik | Kommentar hinterlassen

JRockit Fatal Error: Bad replacement opcode (59)

Manche Fehler können wirklich nerven. “Bad replacement opcode” hat irgendwie nichts mit Java zu tun. Und das schon beim Aufruf von “java -version”. Wo soll man da suchen? Man fühlt sich an die Zeit erinnert, in der es nur eine Fehlermeldung gab: “syntax error”. Kein Hinweis, was falsch war, wo der Fehler auftrat oder wie er behoben werden kann. Auch eine Fehlernummer fehlt, mit der man eventuell die Chance hat – dank Google – nach Forum Einträgen zu suchen. Ursache von meinem “nervenden” Fehler war folgende Meldung:

# java -version
[ERROR] JRockit Fatal Error: Bad replacement opcode (59)
[ERROR] Could not patch code @0x7fffe3a8d063 [java/nio/charset/Charset.forName(Ljava/lang/String;)Ljava/nio/charset/Charset;]
[JRockit] JVM State dumped to /root/Desktop/jrockit.4957.dump.
Aborted

Der Fehler trat in einer VirtualBox Image auf, Betriebssystem SUSE Linux Enterprise Server 11. Die verwendete JRockit Version war die R28.2.7-7-155314-1.6.0_45. Andere Programme liefen ohne Probleme, selbst die SUN JDK Java Version funktionierte. Kein Hinweis auf ein Problem bei Unix Installation, keine Prozesse, die die Maschine lahm legen. Die Suche im Internet ergab kein Erfolg, auch bei Oracle Metalink kein Tipp oder Vorschlag.

Die Analyse der Dump Datei, die JRockit schreibt, liefert auch nur wenig:

StackOverFlow: 0 StackOverFlowErrors have occured
OutOfMemory  : 0 OutOfMemoryErrors have occured
C Heap       : Good; no memory allocations have failed

Also wo kann der Fehler liegen? Laut Dump ist kein Fehler aufgetreten!

Einen Schritt weiter kommt man, wenn die Unix System Aufrufe aufgelistet werden. In der Ausgaben von strace steht folgendes:

[WARN ][codegc ] Could not acquire 128KB of code memory.
[WARN ][codegc ] 256KB committed previously.

Das Problem liegt somit doch beim Bereitstellen von Memory, bevor JRockit die Chance hat, das erste Java Statement auszuführen.

Um sicher zu gehen ist der nächste Schritt, beim Aufruf von Java den Memory anzugeben. Die Angabe des Minimums war noch kein Erfolg, doch beim Maximum lief JRockit wieder:

# java -Xmx100m -version
java version „1.6.0_45“
Java(TM) SE Runtime Environment (build 1.6.0_45-b06)
Oracle JRockit(R) (build R28.2.7-7-155314-1.6.0_45-20130329-0641-linux-x86_64, compiled mode)

Damit lässt sich der Fehler jedoch noch so richtig erklären. Bei weiterer Suche fiel dann in der strace Ausgabe noch folgendes auf:

sysinfo({uptime=312, loads=[41600, 32320, 16032] totalram=2993602560, freeram=2485215232, sharedram=0, bufferram=12627968, totalswap=0, freeswap=0, procs=220, mem_unit=1}) = 0

Und damit war dann klar: der Swap Bereich ist nicht vorhanden. Eine Kontrolle in Linux zeigte es:

# more /proc/swaps
Filename                Type        Size    Used    Priority

Die Swap Partition war nicht gemountet. JRockit benötigt einen Swap Bereich. Ohne einen Swap Memory scheint die Berechnung des maximalen Memory schief zu gehen. Nachdem die Swap Partition wieder gemountet war, lief alles wieder Zwinkerndes Smiley

Die “Bad replacement opcode” Fehlermeldung eine Allerweltsfehlermeldung. JRockit hat ein Problem grundlegende Systembefehle auszuführen. Dies kann ein Zugriff auf ein Device sein oder zum Beispiel der fehlender Swap Bereich. Eine Analyse muss somit immer erfolgen.

Veröffentlicht unter Java, JRockit, Technik | Kommentar hinterlassen

Geheime Einsichten in JRockit – Übersicht aller Flags

Genauso wie die Hotspot JVM hat auch die JRockit JVM eine Vielzahl von verschiedenen Flags. Leider findet man jedoch nirgends eine Dokumentation, die alle Flags beinhaltet. Viele Flags – gerade zur Diagnose – fehlen bei den Beschreibungen. Abhilfe schafft ein Flag, das alle anzeigt.

Die JRockit JVM ist dafür bekannt, dass in der Regel nur wenig eingestellt werden muss. So verwundert es nicht, dass JRockit wesentlich weniger Flags hat als die Hotspot JVM. Dennoch ist die Anzahl noch groß.

Die Ausgabe alle Flags erfolgt über das X-Flag printflags.

$>java -Xprintflags -version
Global:
        UnlockDiagnosticVMOptions = false (default, writeable)
                – Enable processing of flags relating to field diagnostics
        UnlockInternalVMOptions = false (default)
                – Enable processing of internal, unsupported flags
Class:
        FailOverToOldVerifier = true (default, writeable)
                – Fail over to old verifier when split verifier fails
        UseVerifierClassCache = true (default)
                – Try to cache java.lang.Class lookups for old verifier.

Leider wird die Versionsnummer nicht mehr ausgegeben. Die Tests wurden mit folgender JRockit Version durchgeführt.

$>java -version
java version „1.6.0_37“
Java(TM) SE Runtime Environment (build 1.6.0_37-b06)
Oracle JRockit(R) (build R28.2.5-20-152429-1.6.0_37-20120927-1915-windows-x86_64, compiled mode)

Die genaue Version ist wichtig, da – genauso wie bei der HotSpot JVM – sich die Flags von Version zu Version ändern können.

Die Übersicht der Flags liefert 148 verschiedene Flags, die eingestellt werden können. Die ersten zwei Flags UnlockDiagnosticVMOptions und UnlockInternalVMOptions sind wichtig, da darüber weitere Flags aktiviert werden können.

Um die Flags zur Diagnose nutzen zu können, muss UnlockDiagnosticVMOptions angegeben werden. Wichtig: dieses Flag muss zuerst kommen. Wird es nach dem printflags angegeben, wird das Flag ignoriert.

$>java -XX:+UnlockDiagnosticVMOptions  -Xprintflags -version
Global:
        UnlockDiagnosticVMOptions = true (set from command line, writeable)
                – Enable processing of flags relating to field diagnostics
        UnlockInternalVMOptions = false (default)
                – Enable processing of internal, unsupported flags
Class:
        FailOverToOldVerifier = true (default, writeable)
                – Fail over to old verifier when split verifier fails

Anstelle von 148 sind es nun 184 Flags, die angezeigt werden. Also 36 neue Flags, die genutzt werden können. Leider ist in der Übersicht nicht erkennbar, welches Flag für die Diagnose – also auch nur mit dem UnlockDiagnosticVMOptions funktioniert – und welche Flags normale Flags sind. Dies muss mit vergleichen selber herausgefunden werden.

Die folgenden Flags erscheinen zusätzlich mit dem diagnostic Flag:

– AddCodeInfo
– AllocClearType
– AllowInfiniteLazyUnlockingTransfers
– AlwaysSpinOnReacquire
– CodeBlockSegmentMode
– DumpProblematicThreadLoopCount
– FastTimeMaxDrift
– HSActiveSamplePeriod
– HSPassiveSamplePeriod
– HeapRootLogSize
– InitialClassBlockMemory
– LazyUnlockingClassBanThreshold
– LazyUnlockingClassBanWindowSize
– LazyUnlockingRevertNotifyInterval
– LazyUnlockingTransferClassBanThreshold
– LazyUnlockingTransferClassBanWindowSize
– LogCompilerMemUsageThreshold
– MaxClassBlockMemory
– MaxDeadThreadsBeforeGC
– MaxLazyUnlockinTransferClassBanWindowSize
– MaxLazyUnlockingTransfers
– MaxOptMemUsage
– MinDeadThreadsSinceGC
– NativeLockContendedPollCount
– NativeLockContendedSpinCount
– NativeLockMaxQueueLength
– NumLazyLockTransferClassBanWindows
– OptFile
– OptHistoryBufferSize
– OptMemTraceLevel
– OptSizeThreshold
– RememberLazyUnlockingHistory
– RequiredCodeGenStack
– SetDebuggerThreadNames
– StdinPipeReadWorkaroundPollPeriod
– UseStdinPipeReadWorkaround

In der Regel werden die internen Flags nur aúf Anweisung vom Support verwendet, dennoch sollten sie hier nicht fehlen. Mit dem zweiten Flag UnlockInternalVMOptions werden weitere 7 interne Flags angezeigt. Auch hier erscheint in der Liste kein Hinweis, welche von den Flags zu den internen gehören.

Werden die Übersichten verglichen, kommen folgende internen Flags heraus:

– CGBreakOn
– DumpFromAlternateStack
– HeapHoleAtOffset
– HeapHoleAtOffsetSize
– OldOptFile
– StopOnDumpProblematicThread
– VTuneMode

Da oft die Beschreibung der Flags fehlt, ist es schwierig diese sinnvoll einzusetzen, leider. Aber es ist schon sehr interessant, wieviele Flags es bei JRockit möglich sind. Zwinkerndes Smiley

Viel Spaß beim Testen Zwinkerndes Smiley

 

Veröffentlicht unter Java, JRockit, Technik | Kommentar hinterlassen