HOAB

History of a bug

datapump (expdp) et virtualbox répertoire partagé

Rédigé par gorki Aucun commentaire

Le problème :

Utiliser expdp (export Oracle) pour dumper une base sur un répertoire partagé VirtualBox

 

Solution :

 

ça ne marche pas.

J'ai testé plusieurs choses :

ça ne marche pas sous l'OS

  • mettre les droits du répertoire partagé à l'utilisateur oracle via chown/chmod. Ce n'est pas possible (même dans les sous-répertoires)

ça marche sous l'OS (je peux créer des répertoires/fichier), ça ne marche pas avec expdp :

  • ajouter l'utilisateur oracle au groupe vboxsf.  (ORA-39070)
  • monter le répertoire partagé pour l'utilisateur oracle (cf ce lien). (ORA-39070)
  • utiliser un répertoire local pour le LOG et le partagé pour le dump (cf ce lien). (ORA-27054)

Au final je dump en local sur ma VM après avoir fait de la place.

Les commandes utiles :

  • pour remonter le disque partager pour un autre user que root
mount -t vboxsf -o uid=1000,gid=1000 <folder name given in VirtualBox> /home/<user>/where/ever/you/want

 

Jinit Jinitiator Java7

Rédigé par gorki Aucun commentaire

Le problème :

Avec les vieilles versions d'Oracle Forms (10g2 - 10.1.2.0.2), un système existait pour remplacer le Java web start (JWS).. le Jinitiator (*fear !*).

Sauf que ce vieux système n'est plus maintenu. Donc rien ne se lance. Comme toujours une recherche donne des indices dont :

- réduire la version de Java

- Modifier Oracle Forms pour ne pas utiliser Jinitiator, c'est possible avec la 10g2 je crois

Mais comme par hasard, tout ça ne marche pas chez moi.

Solution :

Ce n'est pas simple... (testée avec la JVM 32bits 1.7.0_55-b13)

0) Activer la console Java pour tous les lancements, vérifier que vous avez l'erreur

ClassNotFoundException : oracle.forms.engine.Main

1) repérer où l'application Java est téléchargée... (Panneau de configuration -> Java -> Général -> PAramètres des fichiers temporaires -> Empalcement, exemple :

C:\Users\<user>\AppData\LocalLow\Sun\Java\Deployment\cache

2) Recherche l'archive de lancement dans les sous répertoires - un fichier de  1,151 Mo). C'est le fichier frmall_jinit.jar indiqué dans la source de la page de l'applet.

3) Surprise c'est un jar dans un jar ! Voilà pourquoi mon java ne pouvais pas lancer l'appli, une astuce Jinit...

3) Extraire le jar : forms.jar

4) Remplacer le fichier du cache par le fichier extrait forms.jar => Dans mon cas j'ai du remplacer ce fichier (conserver le nom du cache évidemment) :

C:\Users\<user>\AppData\LocalLow\Sun\Java\Deployment\cache\6.0\0\2d74c040-2640a8d0

5) Actualiser la page et hop ! ça affiche quelque chose, mais ça plante encore... Eh oui, il y a une vérification de la version de Java dans la classe HTTPConnexion

oracle.forms.net.HTTPConnexion

6) décompilation, suppression du test, mise à jour du HTTPConnexion.class dans l'archive, recopie dans le cache, relance... easy ou presque.

 

A noter que cette astuce ne devrait pas servir souvent  :

  1. soit vous êtes admin et dans ce cas, modifiez votre configuration Oracle Forms pour utiliser JWS
  2. soit vous êtes un utilisateur courant et vous faites remonter le problème à votre admin
  3. sinon, comme moi, vous êtes utilisateur ponctuel et vous n'avez pas envie de réinstaller une VM XP Java 2 juste pour ça...

 

Cependant ça peut servir pour toutes les applets Java hein, un truc vous embête, modification, remplacement du cache et hop ça roule. C'est déjà utilisé couramment pour modifier les scores des jeux ^^ (java, flash ou autre)...

Personne ne trouve bizarre qu'un mec finisse un niveau en 0.1 seconde ou qu'un score grimpe à 999 999 999 ?!! :)

 

 

Fil RSS des articles de cette catégorie