HOAB

Le problème :

SimpleDateFormat ne me retourne pas la date correcte :

        try {

            SimpleDateFormat sdf = new SimpleDateFormat("dd/MMM/YYYY:HH:mm:ss", Locale.US);
            Date date = new Date();
            String formatted = sdf.format(date);
            System.out.println(formatted); // 19/Jun/2013:13:31:16
            System.out.println(sdf.parse(formatted)); // Sun Dec 30 13:32:15 CET 2012
        } catch (ParseException e) {
            e.printStackTrace();
        }

Pas cohérent !

Solution :

Ce petit test est un bon moyen de vérifier votre formatter SimpleDateFormat.

1) vérifier la locale. C'est courant d'avoir une date à parser "01/Jun/2013" et de ne pas préciser la locale. Du coup SimpleDateFormat prend votre locale par défaut, souvent FR, et esssaiera de trouver le mot Juin, mais ça vous le verrez assez : erreur de parse, etc....

2)... et ça, la bêtise : il ne faut pas utiliser YYYY mais yyyy. cf documentation (nouveau depuis Java 7)

Au moins je suis pas tout seul : ici, surtout là

Donc :

SimpleDateFormat sdf = new SimpleDateFormat("dd/MMM/yyyy:HH:mm:ss", Locale.US);

Le problème :

C'est galère d'installer Oracle XE sur windows 7 64 bits.

Parfois ça marche, parfois ça marche pas.

Solution 1 (non testée) :

Installer Oracle complet, disponible pour utilisation personnelle en version 64 bits.

Solution 2 :

Une erreur se produit à l'installation (fichier introuvable : KEY_XE.reg). D'après ces sites : ici et là, il faut, pendant l'installation, copier le fichier en question dans le répertoire temporaire de l'installation. Le 2ème site propose un petit .bat (key_oracle.bat) pour l'installer dans tous les répertoires temporaires, (l'installation silencieuse n'a pas marché chez moi, mais c'est basé sur des délais, donc variable suivant les environnements), à exécuter après avoir fait tous les choix, au début de l'installation proprement dite.

Plusieurs problèmes peuvent se poser après l'installation :

• pas de base créée (répertoire C:\oraclexe\app\oracle\oradata\XE vide).

  • là c'est mort
  • en général c'est le problème du KEY_XE.reg, mais je ne suis pas sur
  • peut-être que "sys" comme mot de passe pose problème (?!?)

• le TNS XE n'est plus reconnu (ORA-12514:No TNS Listener)

  • a priori cela se produit quand on arrête les services OracleServiceXE ou OracleXETNSListener et qu'on les redémarre,
  • ajouter la description du SID XE dans le fichier <ORACLE_HOME>/network/admin/listener.ora

    (SID_DESC =
      (SID_NAME = XE)
      (ORACLE_HOME = c:\oraclexe\app\oracle\product\11.2.0\server)
    )

• sur expdp :ORA-12638.

  • solution ici
  • modifier le fichier <oracle home>/network/admin/sqlnet.ora

SQLNET.AUTHENTICATION_SERVICES= (NTS)

en

SQLNET.AUTHENTICATION_SERVICES= (NONE)

• le port 8080 est utilisé

select dbms_xdb.gethttpport as "HTTP-Port"
            , dbms_xdb.getftpport as "FTP-Port" from dual;
begin
     dbms_xdb.sethttpport('80');
     dbms_xdb.setftpport('2100');
end;
/

Trucs à savoir

• le service HTTP est démarré par le service OracleXE
• se logguer en "/ as sysdba" est compliqué (il faut que votre user soit dans un groupe ActiveDirectory précis) : à oublier
• ne pas oublier le mot de passe SYSTEM / SYS indiqué lors de l'installation c'est la clé de tout, et comme on ne peut pas utiliser le sysdba c'est impossible à changer
• seul deux services sont nécessaires pour la base : OracleServiceXE ou OracleXETNSListener. Et pas besoin de les mettre en démarrage automatique

Le problème :

Un script PHP lit un fichier sur le disque et le renvoie à l'utilisateur, cependant le fichier est corrompu. Rapidement l'analyse montre des caractères en plus, merci wikipedia :

EF BB BF is the UTF-8 encoding Byte Order Mark (BOM).

Qui les envoie ?

Solution :

Premièrement vérifier que le fichier sur le disque n'est pas corrompu en le téléchargeant via FTP (mode binaire bien sur).

Ensuite un peu de recherche :

1. Il semble donc que ces caractères soient au début d'un fichier PHP exécuté. Normal après tout, on demande un fichier au serveur (ici un script PHP), le serveur commence par fournir le contenu du fichier jusqu'à ce que le module PHP s'en mêle... ou s'emmêle...
2. Pas 36 méthodes :
   • Regarder le fichier PHP appelé dans le flux HTTP
   • Editer ce fichier et vérifier l'encoding avec un éditeur (via notepad++ par exemple)
   • Au besoin, ouvrir les fichiers inclus (require / require_once).

Trucs pratiques :

• l'outil mode développeur de Firefox en activant "la journalisation des réponses et requêtes"
• Notepad++ (avec le module deprecated mais qui marche toujours : HEX-Editor)
• L'encoding BOM est :
  • 77u/ dans le développeur
  • EF BB BF dans le module HEX-Editor
  • xD0 xCF quand on édite le fichier comme une brute

Le problème :

Un EJB est appelé, mais ne vois pas ses attributs remplis par le container : les attributs normalement remplis par @Inject et @EJB ont une valeur null.

Malgré les vérifications habituelles, je n'avais toujours pas d'attributs injectés et du coup des NullPointerException à la pelle.

Solution :

Vérifier les éléments suivants à vérifier sur la classe appelée :

1. présence du @Stateless/@Singleton/@Stateful sur la classe
2. classe non finale
3. classe appelante instanciée par le container
   • Soit via @Inject / @EJB elle-même
   • Soit suivant la méthode du container :
     1. pour l'auto-injection OpenEJB/TomEE,
     2. soit suite à un @Startup, une servlet, @Path, etc...
4. si vous êtes en EJB 3.0, présence du META-INF/beans.xml
5. méthode appelée publique non finale

C'était ce dernier cas qui m'a donné du fil à retordre. Tout était bon et pourtant lors de l'appel d'une méthode particulière, l'objet pourtant instancié par le container ne voyais pas ses attributs injectés. Le fait d'avoir une méthode finale empêche le container d'injecter ses outils autour de la méthode.

Le problème :

Dans l'arborescence OVH mutualisé, le répertoire de base pour le domaine principal est "www".

En créant un sous domaine, on le redirige (par défaut) vers
"www/<repertoire sous domaine>".

/
/www
/www/sousdomaine

On se retrouve alors avec un répertoire www qui contient un site complet dont un sous-répertoire qui contient le site du sous-domaine.
Ce n'est pas simple à gérer au final pour la maintenance : sauvegarde, update...

On aimerait plutôt avoir :

/
/www/domaine
/www/sousdomaine

Solution 1 : Redirection

Pleins d'articles trouvés via Google, mais entre les hébergements pro, dédiés, etc...

Voici une solution qui marche : mettre dans le fichier .htaccess du répertoire "www":

RewriteEngine On
RewriteCond %{HTTP_HOST} ^(www\.)?<domaine-principal>\.<tld>$ [NC]
RewriteCond %{REQUEST_URI} !^/sous-repertoire
RewriteRule ^(.*)$ /sous-repertoire/$1 [L]

Mais ce n'est pas idéal, certains logiciels (dont pluXml) doivent activer leur propre réécriture.

Solution 2 : Ne pas créer de sous-répertoire dans www :)

En fait le manager OVH propose par défaut la forme suivante : www/<répertoire sous-domaine>, mais elle n'est pas obligatoire.

Enlevez le slash, et créez votre répertoire au même niveau que le www, exemple :

/
/www
/www-sousdomaine