Cédric Chantepie a écrit 88 commentaires

Les premières données OpenData pour Le Mans Métropole sont à présent accessibles. Les informations géographiques (voirie, quartiers, …) sont les premières à bénéficier de cette ouverture : http://data.lemans.fr .

C'est normal, ce n'est pas dans Apache ou IIS ou encore JK2 qu'il faut alors configurer les DirectoryIndex mais dans Tomcat. En effet puisque JK2 est là pour transmettre les requêtes HTTP à destination de JSP ou de servlets depuis le serveur Web classique (IIS/Apache) vers Tomcat c'est bien au final Tomcat qui "interprête" la requête du client, y compris les requêtes pour des dossiers.

Effectivement c'est pas mal du tout, l'édition du project.xml est un peu fastidieuse mais je pense que c'est un outil qui a de l'avenir afin d'avoir une vision claire d'un projet. Dès que j'alimente mon compte paypal je fais une donation promis...

Je ne suis pas sûr de ce que tu comptes obtenir en terme de sécurité par cette manipulation ? Les appels à des JSP sont tout aussi sécurisables que les appels à des servlets.

Pour précompiler, il est possible d'utiliser des tasks ant qui font appels aux fichiers JSP déployés dans tomcat afin de les compiler (ou au pire un petit script avec wget). En revanche il faut garder les JSPs, au moins dans le war explosé (dossier Webapp).

Sinon tu peux copiers les .java générer dans le dossier work de tomcat qui correspondent à tes fichiers JSPs et sont en fait du codes Java pour des servlets, les compilers toi même et éffectuer des servlet-mapping. Honnêtement je trouver la bidouille de peu d'intérêt surtout que la maintenance ultérieure est grandement complexifiée.

Je suis tout à fait d'accord avec tgl : site Web "dynamique" versus application avec interface Web.

L'orthographe n'est pas un caractère génétique, heureusement, c'est une question d'attention. Tout le monde fait des fautes, moi le premier, ça n'empêche pas qu'il faille faire un minimum d'efforts.
Encore au moins 6 fautes en 2 lignes : s/t'es conseille/tes conseils/;s/ortographe/orthographe/;s/je pourait/je pourrais/;s/sachez justes/sachez juste/;s/mes gène/mes gènes/.

Quant à SVN, il faut savoir qu'il n'est pas obligatoire de s'en servir avec apache. SVN peut être lancé en daemon (svnserve), et si on souhaite alors avoir un accès sécurisé, il est possible d'utilisé SSH. Soit avec SVN ouvert uniquement en local et accès par un tunnel SSH, soit avec les url de type svn+ssh://.

Comme dit précédemment, essaies de faire attention aux fautes ça rendra tes participations plus agréable à lire. J'ai noté au moins 6 fautes, pour 1 phrase et 2 lignes ça fait pas mal (s/enfaite/En fait/;s/je voulait/je voulais/;s/un peut plus/un peu plus/;s/j'ai jamais utiliser/je n'ai jamais utilisé/;s/des programme/des programmes/;s/au paravant/auparavant/).

Pour répondre à la question, les deux systèmes cités, CVS et SVN, me semble les plus répandus en terme de SCM. CVS est effectivement plus ancien mais il marche encore très bien, et est bien documenté. Quant à SVN même s'il est plus récent, grâce à son adoption par des entités importantes (IBM, apache ...), il est stable (même si j'ai eu des "merges" plus embêtant avec SVN, c'est peut être de ma faute).

Professionnellement j'utilise les deux systèmes, les anciens projets restent sous CVS et les nouveaux sont mis sous SVN. Vu la plus grande activité de développement de SVN je pense qu'il a plus d'avenir actuellement.

Il me semble que itoa n'est pas un fonction C ANSI, ce qui expliquerait son absence.

Ce n'est pas par défaut sous darwin

Je dirais qui faut peut être vérifié si le SSHD est lancé puisque le scp et le sftp sont basés dessus :
# /etc/init.d/sshd status (ou quelque chose du genre)

En général make utilise un fichier Makefile et les fichiers Makefile.in sont générés par automake puis enfin un Makefile est obtenu par un configure (autoconf).

Si tu as bien un Makefile.in il reste la dernière étape à savoir obtenir le Makefile instancié en fonction de tes choix par le script configure.

En suite, dans le même répertoire que le fichier Makefile généré il suffit de taper :

# make

ou si tu souhaites absolument préciser le fichier :

# make -f Makefile

Vérifie avec un telnet localhost 1099 que le port du JNP Invoker est ouvert, il se peut bien que par défaut ça ne soit pas le cas.

Si ce n'est pas le cas, regardes dans jboss/server/[conf]/conf/jboss-service.xml si -1 ne serait pas spécifié en tant que port.

Si le telnet accède bien au JNP Invoker, tente un petit programme de test en créant un java.util.Properties équivalant au jndi.properties à passer à un javax.naming.InitialContext.

Tu as mis le PROVIDER_URL comment ? A mon avis c'est un soucis de jndi.properties.
Il faut que le service ENC (JNDI pour le J2EE) soit utilisable et pour ça il faut dire à la JVM qui est il.
Personnellement pour attaquer des EJB déployés dans JBoss depuis une application standalone j'ai le fichier jndi.properties suivant :

### JBossNS client properties for connection from the localhost
java.naming.factory.initial=org.jnp.interfaces.NamingContextFactory
java.naming.provider.url=jnp://localhost:1099/
java.naming.factory.url.pkgs=org.jboss.naming:org.jnp.interfaces
# The jnp protocol socket factory class
jnp.socketFactory=org.jnp.interfaces.TimedSocketFactory
# The TimedSocketFactory connection timeout in milliseconds(0 == blocking)
jnp.timeout=0
# The TimedSocketFactory read timeout in milliseconds(0 == blocking)
jnp.sotimeout=0

Il faut alors que ce fichier soit trouvé dans le classpath (dans le JAR contenant le client EJB par exemple).

P.S.: Il est tout à fait normal que ça marche dans la JVM de JBoss car il se charge alors de mettre les propriétés JNDI dans le JVM comme il convient.

Comme je l'ai expliqué dans la deuxième solution, c'est possible en utilisant assert.

Ce n'est pas un question de compilation, swipl est un interprêteur, c'est une question de différencier l'appel et la définition des prédicats/faits.

Je ne vois pas en quoi éditer son fichier à côté puis le charger fait une usine à gaz, mais enfin...

#swipl
[...]
?- assert(aime(moi, musique)).
Yes
?- aime(X, musique).
moi ;
No

Je ne connais pas gprolog mais son comportement doit être semblable à swipl.
Soit tu édites ton code avec le logiciel de ton choix (emacs, vi...) puis charge le fichier .pro dans swipl en ligne de commande :

# swipl -s mon_fichier.pro
Welcome to SWI-Prolog (Multi-threaded, Version 5.4.7)

?- aime(moi, musique)
[...]

Soit tu souhaites ajouter des prédicats ou fait à la volée dans l'interprêteur (swipl) il te faut passer par assert :

# swipl
Welcome to SWI-Prolog (Multi-threaded, Version 5.4.7)

?- assert(aime(moi, musique))

Dans le deuxième cas il te faudra utiliser retract si tu veux enlever des faits.

Je te conseille la première méthode.

Les fréquences de l'écran sont correctement spécifiées selon les specs. J'ai également précisé la RAM de la radeon.
Lorsque j'essaie de forcer au dessus le X ne se lance pas du tout (crash) : je ne vois pas de message correspondant dans le log.

Dans /dev/input/ je n'ai que mouse0 est mice, mice pointant sur mouse0, pas de mouse1.

Oui elle est bien branché, elle s'allume, j'ai essayé différents port usb... rien...

En farfouillant sur les url je ne trouve pas de démo en ligne, peut être ai je mal vu. Si quelque pouvait publier l'adresse si une démo existe ca serait sympa.

Personnellement j'ai testé hypersonic (hsql) et Derby -- anciennement cloudscape -- pour un projet nécessitant un sgbd embedded.

Je préfère largement Derby qui offre un bien meilleurs support SQL (à l'image de DB2) et permet de faire du managment de base par les url jdbc avec des paramètre style ?create=true ou ?shutdown=true

Une trace d'exception et le code que tu utilises serait utile pour comprendre le problème et tenter de te donner une explication.

Si tu utilises alsa au niveau son (alsa-drivers sous gentoo) et que ta carte mère a un chip son en plus de la carte son elle même, essaies de jouer avec la séléction de micro (mic1 / mic2...) sous alsamixer (commande alsamixer sous en console). J'avais ce soucis également pr skype et en choisissant le bon mic ca marche nickel.
Pas besoin de changer le noyau car alsa est en module.

Peut être faudrait il passer explicitement le sessionId, le cookie n'étant peut être pas présent. Vérifie que le sessionId ds le JSP est le même que ds la servlet.

A priori il n'y a pas de package gentoo francisé directement pour firefox mais en installant le language pack fr dans le profile utilisateur même en cas d'update de firefox le pack restera et pourra être updaté depuis firefox

les EJB et le relationnal/object mapping c'est peut être pas la peine (ni le SOAP d'ailleurs) mais avec de jolies taglibs :-)

Sinon ca te dis quelque un truc au mans qui commence par un N ? ;-)