Dienstag, 6. September 2011

BPMN-SOA-Governance Workshop: Password expired beim Start der SOA-Suite

Der Workshop ist jetzt schon ein paar Monate her. Startet man jetzt die SOA-Suite erneut (Desktop-Link 'Start SOA' oder 'Start WLS') bekommt man eine Fehlermeldung 'password expired'.

Abhilfe schaffen die folgenden Schritte:

  • Auf dem Desktop mit rechtem Mausklick ein Terminal öffnen
  • Im Terminalfenster:

    . oraenv [RETURN]
    [RETURN]
    sqlplus / as sysdba
  • In SQLPLUS dann folgendes eingeben:

    ALTER PROFILE DEFAULT LIMIT
    FAILED_LOGIN_ATTEMPTS UNLIMITED
    PASSWORD_LIFE_TIME UNLIMITED;

    alter user dev_mds identified by Oracle123;
    alter user dev_soainfra identified by Oracle123;
    alter user dev_ORABAM  identified by Oracle123;
    alter user dev_ORASDPM  identified by Oracle123;
Im Anschluss bitte das Fenster mit der SOA-Suite, welche auf den 'password expired'-Fehler gelaufen ist schliessen und neu starten, dann funktioniert alles wieder.

---8<-----------------------------------------------------------------------------------------

Update: für SOA 12c die folgenden user ändern:

alter user DEV_IAU_APPEND identified by oracle;
alter user DEV_IAU identified by oracle;
alter user DEV_OPSS identified by oracle;
alter user DEV_MDS identified by oracle;
alter user DEV_STB identified by oracle;
alter user DEV_SOAINFRA identified by oracle;
alter user DEV_ESS identified by oracle;
alter user DEV_WLS identified by oracle;
alter user DEV_UMS identified by oracle;
alter user DEV_OER identified by oracle;
alter user DEV_MFT identified by oracle;
alter user DEV_IAU_VIEWER identified by oracle;

 

Freitag, 12. August 2011

Java Magazine jetzt als elektronische Publikation

Technologisch an der Front zu sein, und die Informationen dazu per Post auf bedruckten toten Bäumen zu bekommen - das passt einfach nicht zusammen. So dachte wohl auch Oracle, denn jetzt erscheint das Java Magazine als kostenlose digitale Publikation, wahlweise interaktiv im Web oder zum Download als PDF.


Weitere Informationen und die erste Ausgabe finden sich auf OTN.

Montag, 8. August 2011

BI-Publisher für OER im WLS installieren

Der Oracle BI-Publisher 10.1.3.4.1 kommt standardmässig noch mit einem eigenen oc4j. Nutzt man bereits das Oracle Enterprise Repository (OER) 11.1.1.x, möchte man den BI-Publisher aber mit auf dem Weblogic-Server des OER betreiben, um nicht zwei unterschiedliche JEE-Container für ein Produkt betreiben zu müssen.

Der BI-Publisher kann wie folgt manuell im WLS installiert werden:

1. Download BI-Publisher
Der BI-Publisher 10.1.3.4.1 ist auf OTN. erhältlich. Das zip-File wird in ein beliebiges temporäres Verzeichnis entpackt, unter Linux/Unix wird auch gleich noch das tar-File entpackt.

2. BI-Publisher installieren
  • Ein Verzeichnis xmlpserver wird erstellt im applications-Verzeichnis der OER-Domain, wie z.B.

    /home/oracle/Oracle/Middleware/user_projects/applications/oer_domain/applications/xmlpserver
  • Aus dem entpackten zip-File im Temp-Verzeichnis wird der Inhalt der Datei

    bipublisher.10.1.3.4.1/manual/generic/xmlpserver.war

    entpackt (nicht die Datei kopiert!) in das neu erzeugte Verzeichnis xmlpserver
  • Im OER Homeverzeichnis befindet sich die Datei BIP-Oracle.zip unter

    $OER_HOME/core/tools/solutions/reports


    In diesem Archiv befindet sich der Ordner XMLP. Dieser wird in das gleiche Verzeichnis kopiert wie xmlpserver, also

    /home/oracle/Oracle/Middleware/user_projects/applications/oer_domain/applications/XMLP
  • Die Datei xmlpserver/WEB-INF/xmlp-server-config.xml wird angepasst, so dass diese auf den Ordner XMP verweist, z.B.

    <?xml version="1.0" encoding="UTF-8"?>
    <xmlpConfig xmlns="http://xmlns.oracle.com/oxp/xmlp">
      <resource>
        <file path="/home/oracle/Oracle/Middleware/user_projects/applications/bpm_domain/applications/XMLP"/>
      </resource>
    </xmlpConfig>
  • Die Fonts aus dem temporären Verzeichnis unter manual/fonts müssen in das fonts-Verzeichnis der benutzten JRE kopiert werden, z.B. nach

    /home/oracle/Oracle/Middleware/jdk160_24/jre/lib/fonts
  • Die xmlpserver-Anwendung wird über die WLS-Console deployed und gestartet.

  • Auf der Deployments-Seite klickt man ggf. auf 'Lock &amp; Edit' und dann rechts auf einen 'Install'-Button


  • Hier wird zum Verzeichnis xmlpserver navigiert -> Next


  • 'Install this deployment as an application' wird hier ausgewählt -> Next

  • Auswahl 'I will make the deployment accessible from the following location' -> Finish
    Ggf. 'Activate Changes', danach links wieder auf 'Deployments klicken.


  • Die Anwendung wird gestartet durch Setzen des Hakens und Start/Servicing all requests. Danach mit 'Yes' bestätigen und der Status wechselt auf 'Active'.


  • Getestet werden kann die Installation über die entsprechende URL, z.B.

    http://oel5r5:7101/xmlpserver/servlet/report

    Benutzername und Password sind beide 'Administrator'
3. Oracle Enterprise Repository für BI-Publisher konfigurieren


  • Im BI-Publisher Web-Frontend wird im Bereich Admin die JDBC-Connection ausgewählt

  • Hier die Data Source 'OER' auswählen

  • Dann die Verbindungsinformationen anpassen und per 'Test Connection' überprüfen. Beenden mit 'Apply'

  • Jetzt noch im Bereich Admin unter 'Users' das Password von oer setzen
  • Diese Konfiguration muss jetzt noch dem OER bekannt gemacht werden. Hierzu werden im OER auf dem Admin-Reiter unter 'System Settings' die folgenden Parameter entsprechend gesetzt:
    - Enable Reports = True
    - Report Server URL = http://oel5r5:7101/xmlpserver/OER
    - Report Server Endpoint URL = http://oel5r5:7101/xmlpserver/services/PublicReportService
    - Report Server Username = oer
    - Report Server Password = wie oben gesetzt

  • Im Reports-Bereich des OER kann die Integration mit dem BI-Publisher überprüft werden. Tauchen hier im oberen Bereich rote Fehlermeldungen auf, ist bei den letzten Schritten etwas falsch gelaufen und diese sollten überprüft werden. 

Sofern alles richtig gelaufen ist, können die Reports ausprobiert werden, wie hier z.B. der 'Policy Status Report'.


Freitag, 5. August 2011

Enterprise Repository: Arbeiten mit Policies

Mit Policies lässt sich das Modell im Repository weiter verfeinern. Policies können Assets angehängt werden und beschreiben weitere Aspekte dazu. Um Policies zu nutzen, muss diese Funktionalität zunächst im Repository aktividert werden.


Hierzu wird auf der Admin-Seite unter Sytem Settings der Parameter 'Enable Policies' auf True gesetzt. Im nächsten Schritt wird das Policy Management Solution Pack installiert. Dazu wird ebenfalls auf der Admin Seite unter 'Import Export' der Import / Export Client gestartet. Wichtig: der Browser muss Zugriff auf das Verzeichnis haben, in dem das OER installiert wurde.


Das Pack befindet sich im OER Installationsverzeichnis unter 
/repository111/core/tools/solutions/11.1.1.5.0-Policy-Management-Solution-Pack.zip
Sucht man unter Assets jetzt nach Type 'POL - Policy' bekommt man jetzt die Policies angezeigt.


Jetzt lassen sich eigene Policies anlegen. Hierzu wird auf der Seite 'Assets' via 'Edit / Manage Assets' der Asset Editor aufgerufen. Unter File / New lässt sich dort eine neue Policy wie jedes andere Asset auch anlegen.


Als Typ muss hier 'POL - Policy' ausgewählt werden. Nach dem Bestätigen mit 'OK' kann die Policy editiert werden. Auf dem Reiter 'Overview' lassen sich jetzt über den Button 'Add' neben 'Policy Assertions' die Anforderungen für diese Policy definieren.


Die Policy kann hier entsprechend beschrieben werden, beenden mit 'OK'. Danach müssen noch im Asset-Editor die Änderungen mit File / Save gespeichert werden.
Damit einem Asset-Type diese Policy auch zugewiesen werden kann, muss dieser Typ dafür zunächst konfiguriert werden. Dieses erfolgt wieder aus dem Asset-Editor, der Type Manager wird über Actions / Manage Type aufgerufen.


Zum Beispiel gibt es für die die Application hier noch keine Assigned Policies. Diese lassen sich hinzufügen über den 'Add-Button' rechts neben 'Elements'.


Hier wähl man die 'Applied Asset Policies' und beendet mit 'OK', daraufhin wird noch ein Namen vergeben wie z.B. 'Applied Policies'. Die Asset Policies sind jetzt im Editor noch versteckt (Hidden). Um dies zu ändern, wechselt man vom 'Editor'- auf den 'Viewer'-Tab.


Dort wählt man unter 'Hidden Elements' die 'Applied Policies' und klickt rechts auf den Button 'Display In Group' und wählt dort z.B. 'Overview'.
Nach dem Speichern im Type-Manager stehen die Policies jetzt allen Assets vom Typ Application zur Verfügung. Hierzu wird ein Asset vom Typ Application im OER Web-Client gesucht und ausgewählt. Falls keines vorhanden ist, kann kurz eines angelegt werden. Eine Anleitung hierzu findet sich u.a. im BPM&SOA-Governance Workshop.


Hier ist jetzt ein neuer Button 'Apply Policies' aufgetaucht, der vor dem Setzen der entsprechenden System-Einstellung noch nicht vorhanden war. Hierüber lassen sich jetzt die gewünschten Policies zuweisen.


Über 'Search' kann man hier alle verfügbaren Policies anzeigen lassen, über die Pfeil-Buttons (>>) können die Policies zugewiesen werden. Abgeschlossen wird mit 'Save', es kommt noch ein Fenster mit einer Zusammenfassung welches mit 'Close' geschlossen wird.



Zurück auf der Hauptseite werden die zugewiesenen Policies jetzt beim Asset angezeigt, ein Symbol mit Ausrufezeichen weist auf die Policies hin.
Für die weitere Darstellung stellt man am besten auf die Tabbed-Ansicht um (dritter runder Button von links).


Im Tab 'Taxonomy' werden die zugewiesenen Policies Dargestellt. Ein Klick auf eine der Policies stellt die Details dazu dar.


Das Icon mit dem gelben Ausrufezeichen zeigt an, dass die Policies zwar zugewiesen, aber nicht überprüft wurden. Grundsätzlich kann dies natürlich auch über ein externes Tool geschehen, welches bestimmte Policies überprüft und entsprechend den Status setzt. Sie lassen sich aber auch manuell setzen, wozu wieder der Asset Editor genutzt wird.


Hier wird dann das entsprechende Asset und die gewünschte Policy ausgewählt. Über den Klick auf 'Details' lässt sich die Policy dann bearbeiten.


Hier wird die betreffende Assertion ausgewählt und mit 'Edit' bearbeitet. Im daraufhin auftauchenden Dialog kann dann das Ergebnis der Prüfung eingegeben werden. Wenn der Dialog mit OK verlassen wird, ist das Ergebnis noch nicht sichtbar, erst wenn im Asset Editor mit File/Save gespeichert wird, ist die Änderung aktiv.


Nach einen Neuladen in der Suchseite ist die Änderung dann auch dort sichtbar. Die Policy zur Barrierefreiheit wird als erfüllt angezeigt, die anderen Polices sind weiterhin auf gelb. Deshalb ist das Icon oben in der Trefferliste auch noch gelb.

Über die Einhaltung der Policies lassen sich jetzt z.B. auch Reports erstellen, ich werde in einem späteren Posting das Setup dafür beschreiben.

Dienstag, 2. August 2011

Oracle Enterprise Linux 5.5 in VirtualBox 4.1: root-Partition vergrössern

Will man die SOA-Suite in einer virtuellen Umgebung patchen, wie z.B. das VBox-Image aus dem BPM & SOA-Governance Training, kann man in das Problem laufen, dass einem der virtuelle Platz auf dem root-Volume ausgeht, da während das Patchens der Platz für die SOA-Suite doppelt benötigt wird. Um das Volume zu vergrössern sind die folgenden Schritte nötig:

Zunächst muss die Grösse für das Virtual Disk Image (vdi) erhöht werden.

e:\VBox\Machines\SOA-11114-Klein>dir
...
02.08.2011  16:11   

02.08.2011  16:11    26.469.335.040 SOA-11114-Klein-disk1.vdi
02.08.2011  16:11            10.243 SOA-11114-Klein.vbox
2 File(s) 26.469.345.283 bytes 
2 Dir(s)  20.660.883.456 bytes free 

Die Größe für das VDI lässt sich mit VBoxManage erhöhen via 

e:\VBox\Machines\SOA-11114-Klein>VBoxManage modifyhd SOA-11114-Klein-disk1.vdi -
-resize 40000
0%...10%...20%...30%...40%...50%...60%...70%...80%...90%...100% 

Hierbei wird die Datei nicht wirklich vergrößert, sondern nur die maximale Größe neu gesetzt, wie ein Blick auf die Datei zeigt.

e:\VBox\Machines\SOA-11114-Klein>dir
Volume in drive E is DriveBay
Volume Serial Number is ACDD-ABAA

Directory of e:\VBox\Machines\SOA-11114-Klein

02.08.2011  16:11              .
02.08.2011  16:11             ..
02.08.2011  16:16    26.470.383.616 SOA-11114-Klein-disk1.vdi
02.08.2011  16:11            10.243 SOA-11114-Klein.vbox

2 File(s) 26.470.393.859 bytes 
2 Dir(s)  20.659.834.880 bytes free 

Das Betriebssystem in der VBox hat davon natürlich nichts mitbekommen. Als nächstes muss daher die zu ändernde VM hochgefahren werden. Dann kann man als root per fdisk die Partitionierung anzeigen lassen:

[root@oel5r5 ~]# fdisk -l
Disk /dev/sda: 41.9 GB, 41943040000 bytes
255 heads, 63 sectors/track, 5099 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes


Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *           1          13      104391   83  Linux
/dev/sda2              14        4000    32025577+  8e  Linux LVM


Disk /dev/dm-0: 29.6 GB, 29662117888 bytes
255 heads, 63 sectors/track, 3606 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

Hier kann man sehen, dass die Platte /dev/sda über 5099 Zylinder verfügt, die Partition /dev/sda2 aber bereits 4000 endet. Per fdisk kann das Ende von /dev/sda2 auf 5099 erhöht werden. Wichtig ist, die Hierzu wird fdisk mit der zu partitionierenden Platte aufgerufen:


fdisk /dev/sda

Über das Kommando p (print the partition table) kann man sich die Partitionierung noch einmal ansehen. Dann muss die zweite Partition /dev/sda2 gelöscht werden mit dem Kommando d:


Command (m for help): d
Partition number (1-4): 2

Als nächstes muss die Partition wieder neu angelegt werden mit dem Kommando n und den Parametern p (primary partition) und 2 (zweite Partition):


Command (m for help): n
Command action
e   extended
p   primary partition (1-4)
p
Partition number (1-4): 2
First cylinder (14-5099, default 14):
Using default value 14
Last cylinder or +size or +sizeM or +sizeK (14-5099, default 5099):
Using default value 5099

Für die Werte für first und last cylinder sind die defaults richtig gesetzt und können so übernommen werden. Schaut man sich mit p die Partitionierung an, sieht man dass die Partition-Id noch nicht richtig gesetzt ist.


Command (m for help): p


Disk /dev/sda: 41.9 GB, 41943040000 bytes
255 heads, 63 sectors/track, 5099 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes


Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *           1          13      104391   83  Linux
/dev/sda2              14        5099    40853295   83  Linux

Diese kann mit dem Kommando t wieder auf den ursprünglichen Wert (hier: 8e) gesetzt werden


Command (m for help): t


Partition number (1-4): 2
Hex code (type L to list codes): 8e
Changed system type of partition 2 to 8e (Linux LVM)
Command (m for help): p


Disk /dev/sda: 41.9 GB, 41943040000 bytes
255 heads, 63 sectors/track, 5099 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes


Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *           1          13      104391   83  Linux
/dev/sda2              14        5099    40853295   8e  Linux LVM

Ein Blick in die Partitionierungstabelle zeigt, dass jetzt alles korrekt ist. Um die Werte zu speichern wird fdisk mit dem Kommando w verlassen.


Command (m for help): w
The partition table has been altered!
Calling ioctl() to re-read partition table.


WARNING: Re-reading the partition table failed with error 16: Device or resource busy.
The kernel still uses the old table.
The new table will be used at the next reboot.
Syncing disks.

Wie von fdisk vorgeschlagen wird die VM jetzt rebootet. Danach muss dem Logical Volume Manager (lvm) die Grössenänderung des physical volumes mitgeteilt werden. Dies geht über


[root@oel5r5 ~]# pvresize /dev/sda2


/dev/cdrom: open failed: No medium found
Physical volume "/dev/sda2" changed
1 physical volume(s) resized / 0 physical volume(s) not resized

Die Fehlermeldung zu /dev/cdrom kann ignoriert werden, wichtig ist '1 physical volume(s) resized'. Der Rest kann dann auch über das grafische Frontend erledigt werden, bei Oracle Enterprise Linux über System/Administration/Logical Volume Management.



Betrachtet man dort die Physical View /dev/sda, Partition 2 sieht man rechts jetzt Unused Space. Um diesen zu nutzen, wählt man unter Logical View LogVol00 und klickt dort den Button 'Edit Properties'.


Hier reicht es einfach, den Schieber für die Größe ganz nach rechts zu ziehen oder alternativ den Button 'Use remaining' zu benutzen und mit OK den Dialog zu beenden. Kommt an dieser Stelle die Fehlermeldung "Logical volume is not mounted but is in use. Please close all applications using this device (eg iscsi)", dann fehlen dem OEL Patches. Hier muss einfach das System mit einem Update-Server verbunden werden und alles installiert werden was vorgeschlagen wird, stand heute funktioniert dann alles.
Danach kann der lvm geschlossen werden und der zusätzliche Speicherplatz steht dem OEL in der VM zur Verfügung.

An dieser Stelle vielen Dank an meinen Kollegen Dirk Wriedt für die Unterstützung.

Mittwoch, 27. Juli 2011

Upgrade SOA/BPM-Suite 11.1.1.4 nach 11.1.1.5

1. Upgrade WLS 10.3.4 -> 10.3.5

Für das Upgrade muss zunächst der WebLogic Server von 10.3.4 auf 10.3.5 upgraded werden. Hierzu benötigt man den Patch von support.oracle.com. Die Patch-Nummern sind
  • 12395517 für Linux 32-Bit
  • 12395560 für Windows 32-Bit
Für alle anderen Plattformen einfach suchen nach Produkt='Oracle WebLogic Server', Release=10.3.5 und die gewünschte Plattform eingeben. Der WLS Patch Installer wird einfach mit den default-Einstellungen durchgeklickt.

2. SOA-Suite 11.1.1.5 Upgrade installieren

Als nächstes wird die SOA-Suite 11.1.1.5 benötigt, erhältlich unter http://www.oracle.com/technetwork/middleware/soasuite/downloads/index.html.

Den Installer für die SOA-Suite startet man dann nach dem Entpacken wie bei einer neuen Installation via .../Disk1/runInstaller. Die Dokumentation dazu findet man unter http://download.oracle.com/docs/cd/E17904_01/doc.1111/e16793/patch_set_installer.htm#insertedID0.


Der Installer erkennt die vorhandene Installation und bietet das Upgrade an, hier mit 'Yes' bestätigen.

3. Repository upgraden

Der nächste Schritt ist das Upgrade des Repositories mit dem Patch Set Assistant, der sich im Oracle_Home der SOA befindet unter z.B. Oracle_SOA1/bin/psa (s. Dokumentation: http://download.oracle.com/docs/cd/E17904_01/doc.1111/e16793/patch_set_assistant.htm#BABEBGEJ). Dieser muss für die Schemata DEV_MDS und DEV_SOAINFRA (Namen ggf. anpassen) analog dem folgenden Beispiel ausgeführt werden.


[oracle@oel5r5 bin]$ ./psa -dbConnectString //localhost:1521/orcl -dbaUserName sys -schemaUserName DEV_SOAINFRA
Oracle Fusion Middleware Patch Set Assistant 11.1.1.5.0

Enter the database administrator password for "sys":
Enter the schema password for schema user "DEV_SOAINFRA":
Log file is located at: /home/oracle/Oracle/Middleware/Oracle_SOA1/upgrade/logs/psa2011-08-03-14-10-17PM.log
Updating the Oracle Fusion Middleware Metadata Schema to release 11.1.1.5.0.
Updating schema for component Oracle SOA.
The command completed successfully

Das Ergebnis kann wie in der Doku beschrieben überprüft werden, oder einfach mit dem folgenden Statement:


SQL>  SELECT version, status, owner FROM schema_version_registry;

VERSION                        STATUS      OWNER
------------------------------ ----------- ------------------------------
11.1.1.4.0                     VALID       DEV_ORABAM
11.1.1.5.0                     VALID       DEV_MDS
11.1.1.2.0                     VALID       DEV_ORASDPM
11.1.1.5.0                     VALID       DEV_SOAINFRA

Zum Schluss noch gemäß Dokumentation die Packages neu compilieren und auf invalid objects prüfen.

SQL> conn / as sysdba
Connected.
SQL> @?/rdbms/admin/utlrp.sql

- - - Haufenweise Zeilen gelöscht - - -

ERRORS DURING RECOMPILATION
---------------------------
0

PL/SQL procedure successfully completed.

PL/SQL procedure successfully completed.

SQL> SELECT owner, object_name FROM all_objects WHERE status='INVALID';

no rows selected


4. Post Patching Tasks

Weiter streng nach Dokumentation müssen alle betreffenden Domains aktualisiert werden wie im folgenden Beispiel:


cd oracle_common/common/bin
./wlst.sh

wls:/offline>upgradeJRF('/home/oracle/Oracle/Middleware/user_projects/domains/bpm_domain')
upgradeJRF: skip, JRF is up-to-date.

Der nächste Schritt ist soa-upgrade.py, der Aufruf führte bei mir allerdings zu folgendem Ergebnis:

cd /home/oracle/Oracle/Middleware/Oracle_SOA1/bin

../common/bin/wlst.sh soa-upgrade.py --username weblogic --password Oracle123 --wlsHost oel5r5 --adminServerListenPort 7001 --targetList AdminServer

... seitenweise gelöscht ...

Current Status of your Deployment:
Deployment command type: deploy
Deployment State       : failed
Deployment Message     : weblogic.deploy.event.DeploymentVetoException: Cannot undeploy library Extension-Name: oracle.soa.worklist.webapp, Specification-Version: 11.1.1, Implementation-Version: 11.1.1 from server AdminServer, because the following deployed applications reference it: HT-01-simple-Form.war, UrlaubsAntragGenehmigen_UI.war, HT-04-Rules-Form.war, HT-02-Simple-Form.war, UrlaubsAntragErstellen_UI.war, HT-03-List-Form.war
No stack trace available.

... noch mehr gelöscht ...

WLSTException: Error occured while performing deploy : Target exception thrown while deploying application: Error occured while performing deploy : Deployment Failed. : Error occured while performing deploy : Deployment Failed.
Use dumpStack() to view the full stacktrace


Die Worklist-Application konnte nicht neu deployed werden, weil noch HumanTask-Anwendungen deployed waren die davon abhängen. Diese liessen sich auch nicht mehr über das Enterprise Manager Fusion Middleware Control undeployen.
In meinem Fall hatte sich während der Script-Ausführung die Datenbank-Verbindung zur Repository-DB irgendwie verknotet, so dass das Undeploy fehlschlug. Die schnelle Lösung war hier ein Neustart mit anschließendem manuellen Undeploy der Anwendungen.

Beim zweiten Versuch lief das Script dann auch fehlerfrei durch:

.Completed the deployment of Application with status completed
Current Status of your Deployment:
Deployment command type: deploy
Deployment State       : completed
Deployment Message     : no message

Fertig!


Mittwoch, 8. Juni 2011

JDeveloper 11.1.2.0 ist da


Kurz nach dem Release 11.1.1.5 wurde jetzt die 11.1.2.0 freigegeben. Eine Liste der neuen Features findet sich unter


Besonders auffällig ist gleich beim Start die Umstellung auf das neue JDeveloper Extension Framework, basierend auf OSGi. Die Startzeit hat sich dadurch massiv verbessert. Zum Vergleich: auf meinem System benötigt der JDeveloper 11.1.1.5 zum Start 1:24 min., der 11.1.2.0 nur noch 11 sek.

Einziger Wehrmutstropfen: Es ist ein reines Java-Release, das Tooling für SOA, BPMN und Webcenter fehlt hier noch, aber diese Veröffentlichungsstrategie ist ja bereits von vorherigen Releases bekannt. Das neue Release ist auf jeden Fall ein grosser Schritt nach vorne.