JDBC: sql binary vers byte[]
bonjour, je dois lire un champ Binary(8) d'une BD et le sauvegarder dans une variable Java. La doc JDBC indique que le transfert depuis un type SQL BINARY vers un type java.lang.Byte est possible, en autant que ce dernier soit un tableau. Est-ce que quelqu'un aurait un exemple ? Note: Je cherche une solution du genre getObject(), sans avoir recours aux accesseurs d'un Resultset (resultset.getXXX()). Merci,
Re: Une idee geniale de Gooooooooooogle
Le sujet relatif aux Web Services étant ouvert; est-ce quelqu'un connait une autre manière pour créer des UDDI privés que UDDI4J ? Merci, At 16:06 2002-04-15 +0100, you wrote: http://www.google.com/apis/ Il faut faire attention en l'utilisant. La licence dit: The Google Web APIs service is made available to you for your personal, non-commercial use only... A+ Yoz (Yagiz) http://www.erkans.com __ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com
Re: conception de classes et utilisation des exceptions
At 14:50 2002-04-26 +0200, you wrote: Le 26 Apr 2002 Didier Bretin a écrit : Que pensez-vous de cette approche ? Est-elle 'logique' avec une conception Java ? Me trompe-je ? :o) Je renvoie par un throw, sans autre forme de procés, toutes les exceptions qui se produisent au sein des méthodes private et protected. Je considère qu'elles font des traitements internes pour d'autres traitements internes, et si quelque chose fontionne mal, ce n'est pas à un niveau interne interne de s'en occuper. Il y a quelques exceptions à ce principe, toutefois, mais c'est assez rare. C'est l'approche que je préconise également. C'est aussi ce que suggère Bruce Eckel dans son livre thinking in Java au chapitre 9: An exceptional condition is a problem that prevents the continuation of the method or scope that youre in. Its important to distinguish an exceptional condition from a normal problem, in which you have enough information in the current context to somehow cope with the difficulty. With an exceptional condition, you cannot continue processing because you dont have the information necessary to deal with the problem in the current context. All you can do is jump out of the current context and relegate that problem to a higher context. This is what happens when you throw an exception. Le traitement réel des exceptions a lieu au niveau des méthodes publiques. En effet, à ce niveau, une entité extérieure attend un service. Si ce service n'a pu se dérouler correctement, le prestataire doit être en mesure d'expliquer pourquoi, et de se remettre dans un état correct. Deux fonctions existent donc : expliquer, et se remettre dans un état correct. Je ne suis pas d'accord. Une exception indique une erreur grave qui implique un branchement vers d'autres instructions ou bien l'arrêt du logiciel afin d'informer l'utilisateur que l'opération a échoué. Tenter de corriger la provenance de l'exception (comme par exemple en incluant les try/catch dans un while) s'avère difficile et peut aussi échouer. C'est en fait la problématique mieux connu sous le nom termination vs resumption et le choix fondamental que les concepteurs de Java ont fait est de supporter le premier. Voici d'ailleurs ce qu'a écrit Bruce Eckel à ce sujet: Termination vs. resumption There are two basic models in exception-handling theory. In termination (which is what Java and C++ support), you assume the error is so critical there's no way to get back to where the exception occurred. Whoever threw the exception decided that there was no way to salvage the situation, and they don't want to come back. The alternative is called resumption. It means that the exception handler is expected to do something to rectify the situation, and then the faulting method is retried, presuming success the second time. If you want resumption, it means you still hope to continue execution after the exception is handled. In this case, your exception is more like a method call - which is how you should set up situations in Java in which you want resumption-like behavior. (That is, don't throw an exception; call a method that fixes the problem.) Alternatively, place your try block inside a while loop that keeps reentering the try block until the result is satisfactory. Historically, programmers using operating systems that supported resumptive exception handling eventually ended up using termination-like code and skipping resumption. So although resumption sounds attractive at first, it seems it isn't quite so useful in practice. The dominant reason is probably the coupling that results: your handler must often be aware of where the exception is thrown from and contain non-generic code specific to the throwing location. This makes the code difficult to write and maintain, especially for large systems where the exception can be generated from many points. Sylvain
Re: [MTX-SPAM-WARN] Gestion des exceptions et i18n
Salut Seb, avant d'aller plus loin, il y a 2 points dans ta spec sur lesquels je souhaite revenir: 1-Quand tu dis j'avais une ExceptionFonctionnelle je récupérais le message associé dans ma partie présentation que je traduisais, veux-tu dire que tu traduis le message associé à l'exception en fonction du choix de langue de l'utilisateur ? 2-Lorsque tu parles de la partie métier et de la partie présentation, est-ce que tu veux dire que la partie métier est constituée de classes Java et que la partie présentation est constituée de JSP ou bien d'un interface graphique genre Swing ? Sylvain At 10:09 2002-06-05 +, you wrote: Salut, J'ai actuellement un petit problème de gestion des exceptions que voici. Mon appli est divisée en plusieurs couches. Pour simplifier il y a la partie métier et la partie présentation. La partie métier renvoie des exceptions. Elles héritent toutes d'une classe ExceptionFonctionnelle. Dans ma partie présentation je voudrais gérer toutes ces exceptions de manière uniforme. Jusqu'à présent, lorsque j'avais une ExceptionFonctionnelle je récupérais le message associé dans ma partie présentation que je traduisais : est-ce une bonne pratique ? J'attaque maintenant les problèmes de paramètres à mettre dans les messages. En effet, une exception particulière peut posséder des paramètres à ajouter au message à afficher, ces paramètres peuvent de plus être eux aussi traduits. Est-ce que quelqu'un à une idée de comment je peux gérer cela ? En fait ma première question est : est ce que c'est la partie métier ou la partie présentation qui définit le message à afficher. Nous considérons pour l'instant que c'est la partie métier qui en fonction du problème fonctionnel rencontré renvoie un message particulier, la partie présentation ne fait que l'afficher, est ce que cela vous semble correct ? Pour continuer dans cette logique, j'avais pensé créer une classe ParametreMessage ou quelque chose dans le genre qui contient le paramètre et un booléen pour dire s'il faut le traduire, grâce à cela, ma partie présentation peut récupérer les paramètres, traduire ceux qui doivent être traduits puis traduire le message, avant de me lancer dans cela je voulais avoir votre avis sur la validité de cette approche. Merci d'avance Seb __ ifrance.com, l'email gratuit le plus complet de l'Internet ! vos emails depuis un navigateur, en POP3, sur Minitel, sur le WAP... http://www.ifrance.com/_reloc/email.emailif
Re: [MTX-SPAM-WARN] Gestion des exceptions et i18n
At 08:42 2002-06-06 +, you wrote: Personnellement, je ne voulais pas mettre l'i18n au niveau des exceptions et j'ai pour cela plusieurs raisons : - Etant donné que j'ai une interface web, c'est au niveau de la requête que je récupère la Locale. Si je veux i18ner directement la classe ExceptionFonctionnelle il faut alors que je passe en paramètre à toutes mes méthodes métier la Locale utilisée ce qui me paraît lourd. - Je considère que le traitement des règles de gestion métier est indépendant de cette Locale et donc c'est pour cela que je voulais traiter l'i18n uniquement au niveau de ma couche de présentation. Ce n'est pas vrai. Tu n'as seulement qu'à passer la Locale à ta classe qui génère les exceptions. De cette façon, quand tu throw une exception dans une de tes méthodes, cette dernière n'a pas à passer la Locale en paramètre. Ton argument sur la lourdeur ne tient donc pas. L'idée c'est que lorsque tu throw une exception toi-même, tu indiques qu'une condition particulière n'est pas remplie et donc que le programme ne peut se poursuivre. Tu ajoute donc une message dans le constructeur de cette exception qui indique que telle condition particulière a été rencontrée. Or ce message est un champ dans la classe des exceptions qui provient de la lecture de ton fichier .PROPERTIES. Donc la traduction est gérée à un autre niveau. Maintenant, que ce message ajouté soit en français, en anglais, en italien, ... ne change absolument rien au fonctionnement, car c'est la job de ton ResourceBundle de toujours pointer sur le fichier .PROPERTIES contenant les textes dans la langue de ta Locale. Finalement, ton JSP vérifie si une exception se trouve dans la requête et si c'est le cas, il affiche de façon triviale le message d'erreur rencontré. Sylvain Pour l'instant je m'en sors en ajoutant une liste d'Objets (mes arguments) à mon exception. Lorsque je traduis, s'il l'un de ces objets est une string je le traduis (la traduction d'une chaîne inconnue retourne cette chaîne). Je ne trouve pas cela formidable mais pour l'instant je n'ai pas trouvé mieux. Seb Le Mercredi 5 Juin 2002 17:42, vous avez écrit : Voici comment tu pourrais le faire (j'assume que lorsque tu parles de gestion des exceptions, tu veux dire la gestion des exceptions que tu génères toi-même) - Pour chaque message d'erreur pertinent à ton application, tu crée une nouvelle clef dans un fichier .PROPERTIES - Tu as autant de fichier .PROPERTIES que tu supportes de language. - Ta classe ExceptionFonctionnelle doit comprendre un champ de type ResourceBundle, que tu initialises avec la source de ton fichier .PROPERTIES. example: private static ResourceBundle resFile = ResourceBundle.getBundle(com.ta_compagnie.context_path.nom_fichier); - Ta classe ExceptionFonctionnelle doit comprendre un champ pour chaque message d'erreur différent. Ce champ doit lire la clef correspondante dans ton fichier .PROPERTIES example: public final static String MAUVAIS_UNAME = resFile.getString(exception.uname.mauvais); -A chaque fois que tu throw une exception, celle-ci sera automatiquement traduite si tu fournis un message d'erreur correspondant à un des messages d'erreur compris dans ta classe ExceptionFonctionnelle dans le constructeur de la nouvelle exception (ouf !) Example: if (machin!=56) throw new ExceptionFonctionnelle(ExceptionFonctionnelle.MAUVAIS_UNAME); -A chaque fois que l'utilisateur change de langue, une méthode dans ExceptionFonctionnelle doit relire les clefs de ton fichier .PROPERTIES en fonction de la langue choisie. De cette façon, tu traites les exceptions uniformément. Si tu veux ajouter des paramètres à traduire, tu ajoutes des champs dans ta classe ExceptionFonctionnelle et aussi les clefs correspondantes dans ton fichier .PROPERTIES. Et oui, c'est juste de designer ton application pour que la partie métier se charge de la gestion des exception et que la partie présentation ne fait que l'afficher, car c'est conforme au paradigme MVC. Sylvain At 15:13 2002-06-05 +, you wrote: 1-Quand tu dis j'avais une ExceptionFonctionnelle je récupérais le message associé dans ma partie présentation que je traduisais, veux-tu dire que tu traduis le message associé à l'exception en fonction du choix de langue de l'utilisateur ? Oui, je traduis le message en fonction de la langue de l'utilisateur. 2-Lorsque tu parles de la partie métier et de la partie présentation, est-ce que tu veux dire que la partie métier est constituée de classes Java et que la partie présentation est constituée de JSP ou bien d'un interface graphique genre Swing ? Ma partie métier correspond à des classes java et ma partie présentation est un framework model2 maison constitué de jsp, servlet et classes java __ ifrance.com, l'email gratuit le
RE : Java WebStart et jdbc
Bonjour, pour ma part, je ne permet pas à mes apps JWS d'accéder directement aux serveurs de BD. Pour ce faire, j'utilise toujours un Servlet qui effectue toutes mes requêtes sql et renvoie ensuite les résultats à mon apps JWS. Cela me permet ainsi d'isoler le code sql du client JWS et de le garder sur le serveur, ce qui facilite la maintenance. De plus, ce procédé à un impact positif sur la sécurité, car je peut me permettre d'empêcher toute requête sql sur le serveur de BD qui ne provient pas de mon Servlet (par exemple, empêcher tout ip qui n'est pas celui de mon Application Server). Sylvain At 18:51 2002-09-23 +0200, you wrote: Bonjour, Je me réponds à moi-même. Même si le driver jdbc est de type 4, il faut (apparemment) faire un certificat et signer tous les .jar. En tous cas, c'est comme cela que j'ai procédé et ça marche. Didier -Message d'origine- De : FRADET [mailto:[EMAIL PROTECTED]] Envoyé : lundi 23 septembre 2002 06:58 À : Liste Java Objet : Java WebStart et jdbc Bonjour, Je suis confronté à un problème avec une application Java Web Start qui établit une connexion à une base de données. L'application sans JWS fonctionne sans problème. Dans mon fichier jnlp, j'ai bien mis les emplacements des .jar : resources j2se version=1.3+/ jar href=lib/toto.jar/ jar href=lib/jtds-0.3.1.jar/ /resources jtds-0.3.1.jar est un driver jdbc de type 4 pour SqlServer. D'après les résultats des messages d'erreurs, la connexion avec la base de données est établie. L'erreur est donc ailleurs. Des pistes peut-être ... Merci d'avance, bonne journée, Didier FRADET
[MTX-SPAM-WARN] Re: Re: Xdebug
Peux tu expliquer comment les bytecodes peuvent être transformés en code exécutable et ainsi exécutés sur le micro d'un client si HotSpot est désactivé ? Il me semblait que c'était le role de Java HotSpot Runtime. At 14:24 2002-11-15 +0200, you wrote: ça désactive HotSpot -Original Message- From: Omar MOUMEN [EMAIL PROTECTED] To: [EMAIL PROTECTED] Date: Fri, 15 Nov 2002 11:50:29 + Subject: Re: Xdebug C'est quoi le mode classic pour le débuggage ? Patrice Godard a écrit : -Original Message- From: Omar MOUMEN [EMAIL PROTECTED] To: [EMAIL PROTECTED] Date: Fri, 15 Nov 2002 10:07:42 + Subject: Re: Xdebug aprés avoir lancé la ligne de commandes sur une machine HP jdk1.2.2 voilà le message d'erreur que j'ai : JPDA is not supported by Hotspot 1.01 VM. Use Classic VM instead. Could not create the Java virtual machine. --- Ah...mon conseil, penser à passer au moins en Java 1.3. Sinon, d'après le message d'erreur, passer en mode classic pour le débuggage. Patrice, pas encore fluent en 1.4.1 :-) -- S'il n'y a pas de solution, il n'y a pas de problème -- -- S'il n'y a pas de solution, il n'y a pas de problème --
