Freitag, 11. Mai 2018

Forms 12c, Reports und Weblogic in Docker - diesmal mit Windows 10

Heute möchte ich meine Reihe mit der Oracle Middleware und Docker fortsetzen. Doch diesmal wähle ich Windows 10 Professional als Host aus, denn dafür ist Docker mittlerweile auch verfügbar.

Wichtig ist, nach der Installation von Docker im Menü auf die Linux Container zu wechseln, statt mit den Windows Containern zu arbeiten.


Wenn das kleine Walfisch-Icon (Docker) dann weiß ist und sich nicht mehr bewegt, ist Docker erfolgreich gestartet.





Zusätzlich kann man auch in der DOS-Box fragen, ob der Befehl docker nun verfügbar ist.


Am Anfang des Probierens habe ich mich gefragt, wie komme ich denn nun beim Weblogic Docker Images gebaut, welches normalerweise mit

sh buildDockerImage.sh -v 12.2.1.3 gestartet wird. Klassische Linux Befehle in einer Windows DOS-Box wie soll das gehen? Im Endeffekt gar nicht, denn ich habe die Docker Images von Linux exportiert und dann im Anschluß in Windows importiert. Das geht so:

## auf Linux:
docker save  -o /mnt/hgfs/D/formsreports12.2.1.3.tar localhost/oracle/myformsreports:12.2.1.3

## auf Windows:
docker load --input D:/formsreports12.2.1.3.tar
und ein docker images zeigt sie dann auch erfolgreich an.


Die nächste Transformation fand in den Environment-Variablen statt:
## auf Linux:
  export DC_ORCL_PORT=1521
  export DC_ORCL_OEM_PORT=5500
  export DC_ORCL_SID=frdb
  export DC_ORCL_PDB=frpdb
  export DC_ORCL_SYSPWD=Oracle12c
  export DC_ORCL_HOST=${DC_HOSTNAME}

## auf Windows:
 SET DC_DESIRED_HOSTNAME=myformsserver
 SET DC_ORCL_PORT=1521
 SET DC_ORCL_OEM_PORT=5500
 SET DC_ORCL_APEX_PORT=8080
 SET DC_ORCL_SID=ORCLCDB
 SET DC_ORCL_PDB=ORCLPDB1
 SET DC_ORCL_SYSPWD=oracle
 SET DC_ORCL_HOST=%DC_DESIRED_HOSTNAME%

zusätzlich habe ich mir einen festen Hostnamen ausgedacht, der auch in den Properties konfiguriert ist. In dem Zusammenhang sei gesagt, dass das Mounten von Volumes auf Windows mit dem späteren Docker Container nicht funktioniert hat, was sicherlich an irgendwelchen Rechten liegt. So werden also im Gegensatz zum Linux Host die späteren Domain-Informationen alle innerhalb des Docker Containers gespeichert. Dies ist natürlich vom Zugriff her nicht so komfortabel wie auf dem Linux Host, wo er Volume-Mount keine Probleme gemacht hat.

Im File für docker-compose habe ich auch einige Anpassungen vorgenommen, dort wird z.B. auch direkt der Hostname des neuen Containers auf den gewählten aus dem Properties-File gesetzt und ich habe noch einige weitere Environment-Variablen erzeugt, die später den Umgang mit der Domäne etwas vereinfachen.

Hier der Inhalt meines docker-compose Files:
version: "3.0"

services:
  #
  #  The Oracle DB Definition
  #
  frdb:
    image: oracle/database:12.1.0.2-ee
    network_mode: "bridge"
    ports:
      - "${DC_ORCL_PORT}:1521"
      - "${DC_ORCL_OEM_PORT}:5500"
      - "${DC_ORCL_APEX_PORT}:8080"
    environment:
      - ORACLE_SID=${DC_ORCL_SID}
      - ORACLE_PDB=${DC_ORCL_PDB}
      - ORACLE_PWD=${DC_ORCL_SYSPWD}
    container_name: frdb

  #
  #   The Forms & Reports Servers
  #   
  myfrfmw:
    image: ${DC_REGISTRY_FR}/oracle/${DC_FR_PREFIX}formsreports:${DC_FR_VERSION}
    hostname: ${DC_DESIRED_HOSTNAME}
    network_mode: "bridge"
    container_name: myfrfmw
    command: /bin/bash -c "sleep 5s; /opt/oracle/dockertools/crDomain.sh"
    ports:
      - "${DC_ADMINPORT}:${DC_ADMINPORT}"
      - "${DC_FORMS12C_MS_PORT}:${DC_FORMS12C_MS_PORT}"
      - "${DC_REPORTS12C_MS_PORT}:${DC_REPORTS12C_MS_PORT}"
      - "${DC_OHS_LISTENPORT}:${DC_OHS_LISTENPORT}"
      - "${DC_NM_PORT}:${DC_NM_PORT}"
    environment:
      - SCRIPT_HOME=${DC_SCRIPT_HOME}
      - INT_ORACLE_HOME=${DC_INT_ORACLE_HOME}
      - WL_HOME=${DC_WL_HOME}
      - WLST_HOME=${DC_WLST_HOME}
      - MW=${DC_MW}
      - DOMAIN_BASE=${DC_DOMAIN_BASE}
      - APPLICATION_BASE=${DC_APPLICATION_BASE}
      - APP_VZ=${DC_APP_VZ}
      - FORMS12C=${DC_FORMS12C}
      - FADS12C=${DC_FADS12C}
      - REPORTS12C=${DC_REPORTS12C}
      - WEBTIER12C=${DC_WEBTIER12C}
      - OHS_COMPONENTNAME=${DC_OHS_COMPONENTNAME}
      - OHS_LISTENPORT=${DC_OHS_LISTENPORT}
      - OHS_SSLPORT=${DC_OHS_SSLPORT}
      - TEMPLATE=${DC_TEMPLATE}
      - DOMAIN_NAME=${DC_DOMAIN_NAME}
      - AS_NAME=${DC_AS_NAME}
      - ADM_USER=${DC_ADM_USER}
      - ADM_PWD=${DC_ADM_PWD}
      - ADMINPORT=${DC_ADMINPORT}
      - ADMINPORTSSL=${DC_ADMINPORTSSL}
      - AS_HOST=${DC_AS_HOST}
      - FORMS_MS_NAME=${DC_FORMS_MS_NAME}
      - FORMS12C_MS_PORT=${DC_FORMS12C_MS_PORT}
      - REPORTS_MS_NAME=${DC_REPORTS_MS_NAME}
      - REPORTS12C_MS_PORT=${DC_REPORTS12C_MS_PORT}
      - REPORTS_IN_FORMS=${DC_REPORTS_IN_FORMS}
      - REP_SERVER=${DC_REP_SERVER}
      - REP_SERVER_NAME=${DC_REP_SERVER_NAME}
      - REP_TOOLS_NAME=${DC_REP_TOOLS_NAME}     
      - NM_LISTENADDRESS=${DC_NM_LISTENADDRESS}
      - NM_TYPE=${DC_NM_TYPE}
      - NM_PORT=${DC_NM_PORT}
      - NM_USERNAME=${DC_NM_USERNAME}
      - NM_PWD=${DC_NM_PWD}
      - DBUSER=${DC_DBUSER}
      - DBPWD=${DC_DBPWD}
      - DBROLE=${DC_DBROLE}
      - COMPONENTPWD=${DC_COMPONENTPWD}
      - SCHEMA_PREFIX=${DC_SCHEMA_PREFIX}
      - DB_HOST=${DC_DB_HOST}
      - DB_PORT=${DC_DB_PORT}
      - DB_SERVICE=${DC_DB_SERVICE}
      - DB_OMF=${DC_DB_OMF}
      - DB_USER_PW=${DC_DB_USER_PW}
      - PWDFILE=${DC_PWDFILE}
      - TNS_ADMIN=${DC_DOMAIN_BASE}/${DC_DOMAIN_NAME}/config/fmwconfig
      - FORMS_INSTANCE=${DC_DOMAIN_BASE}/${DC_DOMAIN_NAME}/config/fmwconfig/components/FORMS/instances/forms1/bin  
      - FORMS_WEBCFG=${DC_DOMAIN_BASE}/${DC_DOMAIN_NAME}/config/fmwconfig/servers/WLS_FORMS/applications/formsapp_12.2.1/config
      - DOMAIN_DIR=${DC_DOMAIN_BASE}/${DC_DOMAIN_NAME}
      - DOMAIN_DIR_BIN=${DC_DOMAIN_BASE}/${DC_DOMAIN_NAME}/bin  
      - NLS_LANG=AMERICAN_AMERICA.AL32UTF8      
      - FORMS_WEBUTIL=${DC_DOMAIN_BASE}/${DC_DOMAIN_NAME}/config/fmwconfig/components/FORMS/instances/forms1/server   

Gestartet wird zunächst wieder einmal die Datenbank-Instanz, die als Repository dienen soll und im Anschluß dann der Weblogic-Server, der zunächst automatisch die Forms/Reports-Domäne erzeugt.

docker-compose -f myfrfmw-docker-compose.yml up -d myfrfmw
docker logs myfrfmw -f

Alles in allem nicht wirklich schwer das Prozedere und mit etwas Transfer-Arbeit verbunden. Natürlich gut und hilfreich, dass Docker den Ex- und Import von Images anbietet; auch plattformübergreifend.

Bis bald
Holger

Dienstag, 1. Mai 2018

Form Builder aus Docker auf Windows Host öffnen

Im letzten Post habe ich beschrieben, wie man Forms und Reports per Docker auf einem Linux Host installiert. Dies habe ich mittlerweile auch auf einem Windows Host gemacht, auf dem dann auch Docker installiert ist. Docker läuft momentan nur auf Windows-basierten System mit Windows Server und Windows 10.

Möchte man nun den Form Builder aus diesem Docker Container zum Laufen bringen, ist das nicht ganz so einfach und wird mit einer Fehlermeldung quittiert.


Es ist einfach noch kein X-Window-Server eingerichtet. Dafür habe ich auf dem Windows Host dann den XMing Server installiert, der dafür bestens geeignet ist.

Ebenfalls ist es nötig, dass der X-Server auch benutzt werden darf, sprich das sich Clients auch connecten können. Daher hat mein Windows auf noch eine Cywgin Installation bekommen.

In Cygwin setze ich die DISPLAY Variable wie folgt und gestatte per Xhost den Connect.


Ist dies erledigt, kann es im Docker Container weitergehen. Dort setze ich auch die DISPLAY Variable entsprechend und dann geht der Start des Form Builder auch schon.


Recht einfach, wenn man weiß wie das alles zusammenspielen muß. Anstelle das xhost Befehls kann man das sicher noch optimieren.

Als nächstes folgt hoffentlich bald die Beschreibung der Docker Einrichtung mit Forms/Reports auf Windows.

Bis bald
Holger

Dienstag, 13. Februar 2018

verlängerter Lifetime Support für Forms 12c nun bis 2022

Gestern Abend kam per Twitter eine hoffnungsvolle Botschaft von Oracle in Form von Product Manager Michael Ferrante:

verlängerter Lifetime Support für die Fusion Middleware 12.2, insbesondere Forms 12c nun bis 2022 statt 2020. Extended Support sogar bis 2025, auch gültig für Reports 12c.


Quelle: Oracle

Also noch etwas mehr Zeit um hoffentlich noch spannende und zukunftsträchtige Features zu implementieren.

Freitag, 8. Dezember 2017

Forms 12c, Reports und Weblogic in Docker - nun wirklich lauffähig

Heute möchte ich beschreiben, wie man Forms 12c, Reports und Weblogic in Docker zum Laufen bringt. Das war schon länger ein Wunsch von mir und Dirk Nachbar (http://dirknachbar.blogspot.de) hat dafür großartige Vorarbeit geleistet, unterstützt von Robert Crames (http://robertcrames.blogspot.ch) und Jan-Peter Timmermann (https://jan-peter.me).

Warum denn Docker wird man sich vielleicht fragen? Die einfache Antwort lautet: weil Docker toll ist und man nicht immer wieder eine neue VM mit Forms aufzusetzen braucht. Außerdem sind automatisierte Builds und das Bereitstellen einer Umgebung ohne viele manuelle Aktivitäten einfach besser.

Mein Setup sieht so aus:
  • Laptop mit Windows 7
  • darauf eine VM mit Ubuntu 17.10
  • und in Ubuntu läuft Docker
Die Ubuntu-Maschine und der WLS-Docker Container teilen sich Verzeichnisse, in denen die erstelle WLS-Domäne liegt. So kann direkt von Ubuntu aus die Domäne verändert und konfiguriert werden. Ein paar weitere Vorarbeiten sind noch zu leisten, wie z.B. User oracle und Gruppe oinstall anzulegen. Auf meinem Ubuntu mußten noch die Versionen von docker und docker-compose upgegradet werden, denn die aktuellen Versionen aus dem Software-Repository waren nicht mehr ganz aktuell.


Die Installationsschritte sind im Prinzip genau wie bei einer Installation von Forms/Weblogic auf einem Host. Man braucht im Einzelnen:
  • eine Datenbank für das Repository (entweder Docker oder Host)
  • einen Weblogic im Docker
  • eine Repository Installation
  • eine Forms/Reports Weblogic Domäne

Hier für dieses Beispiel habe ich alles in 2 Docker-Images installiert und bin der Anleitung von Dirk aus seinem Github gefolgt.

1. Aufbau des Datenbank Images (gefordert wird eine Standard oder eine Enterprise Installation für das Repository)
Hierfür habe ich einen Git Clone des offiziellen Oracle Docker Githubs gemacht und mittels ./buildDockerImage.sh -v 12.2.0.1 -e ein Image der Enterprise Edition gebaut.


Nach dem erfolgreichen Erstellen wird dieses Image z.B. hiermit gestartet:
docker run --name oracle12-ee -p 1521:1521 -p 5500:5500 -p 8080:8080 -e ORACLE_PWD=neuesPasswort -v /opt/oracle/oradata:/u01/app/oracle/oradata oracle/database:12.2.0.1-ee

2. Aufbau des Weblogic Images
Dieser Teil beginnt mit dem Git Clone von Dirks Github Repository und hat mehrere Schritte.
Zuerst erfolgt der Build des OracleLinux:latest mit dem Oracle JDK 8u151. Dafür muss man das JDK 8u151 tar.gz in den Ordner OracleJava/java-8 legen und ein
./buildDockerImage.sh machen.

Danach gibt es ein oracle/serverjdk Image. Anschauen kann man sich die vorhandenen Images mit dem Command: docker images


Nun wechselt man ins Verzeichnis OracleFMWInfrastructure/dockerfiles und erstellt ein Weblogic Abbild. Dafür muss man vorher noch bei Oracle die entsprechende Weblogic-Zip-Datei fmw_12.2.1.3.0_infrastructure_Disk1_1of1.zip herunterladen und in OracleFMWInfrastructure/dockerfiles/12.2.1.3 ablegen.
Mit ./buildDockerImage.sh -v 12.2.1.3 wird der Build gestartet und am Ende kommt ein Oracle WebLogic Server Infrastructure 12.2.1.3.0 heraus.


Letzter Abschnitt ist das Erweitern des WLS-Infrastructure Images mit den Forms und Reports Sourcen (Wechsel ins Verzeichnis OracleFormsReports/dockerfiles und Ablage der Installations-Dateien fmw_12.2.1.3.0_fr_linux64.bin und fmw_12.2.1.3.0_fr_linux64-2.zip im Unterordner OracleFormsReports/dockerfiles/12.2.1.3. Mit ./buildDockerImage.sh -v 12.2.1.3 wird der Image-Build gestartet.


Am Ende hat man dann ein Image localhost/oracle/formsreports TAG: 12.2.1.3

3. Jetzt geht es ans Konfigurieren der Domain. Dafür hat Dirk im Verzeichnis OracleFormsReports/samples eine Konfigurationsdatei setenv.sh vorbereitet, die die nötigen Umgebungsvariablen setzt (hier ein Auszug).

Diese Datei muss entsprechend angepasst werden; sehr wichtig sind die Eintragungen im #Repository Connect für den Connect des RCU gegen diese Datenbank. Da bin ich zuerst in eine Falle gelaufen und habe für DC_DB_HOST die falsche IP angegeben, dann hat die Erstellung der Domain nicht funktioniert.
Mit ifconfig auf dem Docker Host gibt es ein Netzwerk namens docker0 und unter der inet stehen sollte eine IP stehen. Diese ist die richtige für den DB Container.

Nun kann mit dem Erzeugen der WLS-Domäne und Start des Admin-Servers begonnen werden (vorher sollte die DB aber gestartet sein). Die Variablen aus setenv.sh werden gemerkt, exportiert und vom docker-compose genutzt.

source ../setenv.sh
docker-compose up -d frfmw; docker logs frfmw -f

Wenn man Ende ein <BEA-000365> <Server state changed to RUNNING.>
steht, ist alles gut verlaufen.

Nun kann im Browser der Enterprise Manager mit der URL http://localhost:7001/em aufgerufen werden.

Hierin können nun die Managed Server MS_FORMS und MS_REPORTS gestartet werden.


Wenn man dann auch noch von der Ubuntu-VM die Ports entsprechend forwarded, kann man im Client im Browser auch die Forms-Testseite aufrufen:
http://localhost:9001/forms/frmservlet


Was kann man noch machen?

Einen zuvor erstellten Reports-Server starten

Da die Konfigurationsdateien der Domain alle in einem Verzeichnis auf dem Docker Host zugänglich sind, kann man sie dort auch bequem bearbeiten und die Änderungen sind persistiert (z.B. default.env, formsweb.cfg, rwserver.conf, httpd.conf und andere).

Man kann auch das neue FADS mit dem Forms 12.2.1.3.0 nutzen, siehe dazu auch ins readme-File von Dirk.

Tja was soll ich sagen, ich bin erstmal sehr begeistert von dieser Variante. Denn nach einem Neustart des Ubuntus kann man die Datenbank und den WLS Admin Server mit 2 einzelnen docker Befehlen wieder starten und die Umgebung ist wieder da. Hier ist es auch von Vorteil, dass die o.g. Herren die ganze Domänen-Erstellung gescriptet haben und man ohne GUI auskommt. Von Oracle gibt es dafür bislang keinen Support, was nicht heißt, dass man es nicht trotzdem machen und versuchen soll.

Viele Grüße
Holger

Donnerstag, 30. November 2017

einen Forms Datenblock mit einer Pipelined Table Function erstellen

Heute wurde ich im Daily Standup im aktuellen Projekt gefragt, ob ich oder einer der Kollegen schon mal einen Forms Datenblock mit einer Pipelined Table Function erstellt habe. Dies habe ich abgefragt und verneint. Und vor kurzem tauchte diese Frage auch schon im Oracle Support Forum auf.

Also habe ich das einfach ausprobiert und kann sagen, es funktioniert. Dieses Vorgehen will ich hier einmal exemplarisch beschreiben. Als Datenquelle dient das gute DB-Schema HR mit den Tabellen Employees und Department.

Zuerst erstelle ich auf der Datenbank ein Package mit einer Pipelined Table Function.


Nach dem Erstellen schaue ich mir einmal das Ergebnis als SQL im SQLDeveloper an für Department 50.


Das funktioniert ja bisher alles ohne Probleme, das Erstellen einer einfachen Forms-Maske dafür ist auch nicht schwer. Erst erstelle ich mir mit dem Wizard basierend auf einer View den Datenblock und das Layout und nachher schalte ich das Ganze auf die Pipelined Table Function in einer Select-From Query um.


Am Ende dann die fertige Maske, die übrigens mit Forms 10g erstell wurde. Es geht also recht einfach, auch neue Features der Datenbank in Forms zu nutzen.


Übrigens kann ich das o.g. Package nicht in Forms erstellen, es muß auf der Datenbank sein. Auch in Forms 12c geht das nicht, da wird die Pipelined Table Function noch nicht von der Engine verstanden. Aber das gehört ja auch eher als API in die Datenbank finde ich.

Ob ich den konstanten Parameter 50 auch noch auf ein referenziertes Item beispielsweise eines anderen Forms-Blocks umbauen kann, habe ich noch nicht probiert. Es scheint aber nicht zu funktionieren, siehe Thread im Forum.

Dort wird als Lösung die Nutzung einer Package-Variable bzw. eines Sys-Kontextes vorgeschlagen:
AND d.deptno = SYS_CONTEXT ('from_clause_context', 'deptno')

Was aber auch geht, ist die Benutzung fester Werte mit Variablen in der Zuweisung.

asQuery_V := 'TABLE(Package.TableFunction('||Variable_1_V||',' ||Variable_2_V||'))';
set_block_property('BLOCK', QUERY_DATA_SOURCE_NAME, asQuery_V);

Viele Grüße
Holger

Samstag, 25. November 2017

Mein persönlicher Rückblick auf die #DOAG2017

Nach 5 jähriger Abstinenz von der DOAG Hauptkonferenz hatte ich endlich wieder das Vergnügen, dieses Jahr vom 20-23.11.2017 dorthin zu können. Die Anreise am Montag verlief leider dank der deutschen Bahn alles andere als glücklich (es gab 90 Minuten Verspätung) und so verpasste ich leider das #ACE Dinner, das Martin Klier angesetzt hatte.


Im Vorfeld schon grob das Veranstaltungsprogramm mit den möglichen Sessions zusammengesucht, war ich ganz gut vorbereitet für den ganzen Marathon an Vorträgen. Dafür aber auch noch ein paar persönliche Gespräche angesetzt, mit ehemaligen Kollegen, mit Forms Gleichgesinnten und besonders mit Michael Ferrante, dem Oracle Forms Product Manager. Mein persönlicher Fokus bestand natürlich hauptsächlich auf Forms, SQL, PL/SQL, APEX, Weblogic und Docker Sessions und meine Erwartungen daran wurden auch erfüllt. Dazu später aber noch mehr.

Der Dienstag stand ganz unter dem Zeichen von Forms Vorträgen, die Kollegen haben mich später gefragt, wo ich denn den ganzen Tag lang war. Meine Antwort: von einer Session zur nächsten. :-) Die Referenten für Forms waren u.a. Mia Urman, Michael Ferrante, Jürgen Menge, Gerd Volberg. Am Abend gab es dann das Forms Community Meeting, das sehr gut besucht war. Dort konnten wir M. Ferrante alle Fragen stellen, die uns run um Oracle Forms beschäftigen. Teilweise sehr interessante Dinge, die hoffentlich noch kommen werden. Eins scheint unumstößlich: selbst Oracle Forms soll es angeblich in die Cloud schaffen.







Das war also der erste Tag, im Rückblick der spannendste für mich von den 3 Veranstaltungstagen. Abends ging es dann mit der DOAG DB Community in der Nürnberger Altstadt zum gemütlichen Ausklang.

Am 2. Tag war ein Tag ohne Forms Vorträge, dafür gibt es ja genug andere Themen. Ganz oft gab es zumindest für mich viele interessante parallele Sessions, da war entscheiden angesagt. Wie immer ein ganz großes Angebot auf der DOAG. Ich meine gehört zu haben, dass die Hälfte aller Einreichungen an Vorträgen abgesagt werden musste.
  • Ausfallsicherheit für den Weblogic Admin Server
  • Goldene Regeln für schlechte Programmierung
  • intelligente Chatbots
  • SQL Magic
  • APEX REST Services in 5.2
  • PL/SQL API 
  • Docker for Dummies
Und schon war der letzte Tag da, der Donnerstag. Das war ein gemischter Tag, den ich mit ein paar Vorträgen und vielen Gesprächen verbracht habe. Highlight des Tages waren u.a. der persönliche Talk mit einem umkomplizierten Michael Ferrante und einem Vortrag von Adam Lukaszewski zum Thema Boost your Forms Development with GIT and Forms API Master. Dabei wurde schon gezeigt, wie man mit Hilfe von Git, dem Forms API Master und dem Mergetool parallel an Forms Objekten entwickeln kann, auch mit mehreren Branches. Das kannte ich so bisher auch noch nicht, denn sonst hieß es ja immer, Mergen von binären Objekten geht nicht.



Was soll ich sagen? Es waren tolle informative Tage in Nürnberg, mit gutem Austausch und neuen Erfahrungen. Neue Türen geöffnet und viele bekannte Gesichter gesehen und gesprochen. Wenn mich jemand fragt, würde ich sagen: es hat sich total gelohnt. Vielen Dank natürlich an die DOAG für die tolle Vorbereitung und Planung und an meinen Arbeitgeber, der mir das ermöglichte. Nächstes Jahr bin ich hoffentlich auch selber wieder mit einem Vortrag dabei. Ganz persönlich fand ich auch die Leute von Oracle sehr angenehm und menschlich. Ein paar Bilder für diesen Beitrag habe ich von anderen Twitteren genommen, ich hoffe das ist ok.

Viele Grüße
Holger

Montag, 3. Juli 2017

Eine kleine aber feine Falle bei boot.properties im Weblogic Server

Diesmal möchte ich über eine kleine aber feine Falle bei der Datei boot.properties im Weblogic Server berichten. Wenn man das Verhalten kennt, wird man darüber sicher schmunzeln.

Im Rahmen der Vorbereitung einer Schulung installieren wir den Weblogic Server inkl. Forms und Reports. Und um den Start zu vereinfachen, gibt es Methoden, eine Datei namens boot.properties zu haben, um ohne Eingabe der Credentials die entsprechenden Managed und Admin Server zu starten.

Das Template für die Datei boot.properties sah so bei uns aus:
Username=weblogic
Password=welcome1 


Sieht doch eigentlich ganz gut aus denkt man. Trotzdem kommt beim Start eines Server das folgende Fenster:


Merkwürdig, genau das wollten wir doch aber vermeiden und uns das Leben erleichtern. Ok, eine Ahnung macht sich im Kopf breit und mal flugs bei Oracle geschaut. Selbst dort ist die Schreibweise lowercase.

Also neuer Versuch mit kleiner Schreibweise:
username=weblogic
password=welcome1



Noch als Zusatzinfo: wir arbeiten auf Windows, da hätte ich nicht mit so einer Eigenart gerechnet. Und wir fragten uns schon, wieso wird die Datei nicht berücksichtigt. Jetzt sind wir wieder etwas schlauer und ich habe direkt zu dem Kollegen gesagt, da wird ein Blog draus.

Viele Grüße
Holger