11
votes

GraphicImage ne rendant pas StreamedContent dans les principaux pourvers

J'utilise StreamedContent pour rendre un octet envoyé de JSF puis renvoyez-le en tant que contenu diffusé comme suit: xxx

où l'image est la matrice d'octet de l'image stockée dans la base de données

haricot de support: xxx

mais je ne reçois pas l'image dans la page JSF. J'ai reçu ce message dans le journal du serveur:

AVERTISSEMENT: JSF1091: Aucun type MIME n'a pu être trouvé pour le fichier dynamiccontent. Pour résoudre ce problème, ajoutez un mappage de type MIME sur les applications web.xml.

et: xxx

pouvez-vous m'aider ici, je Je ne trouve aucune information utile concernant ce numéro

PS:

IM en utilisant les bibliothèques suivantes:

Mojarra 2.1.3

PrimeFaces 3.1 .1

Poisson-verre 3.1


4 commentaires

Dupliqué possible de Problèmes d'affichage de la base de données Image de blOB


Questions liées / en double: Stackoverflow.com/ Questions / 8207325 / ... , Stackoverflow.com/Questtions/10073905/... , Stackoverflow.com/questions/10944673/... , Stackoverflow.com/Questions/8304967/...


@Ballusc, mais cet article est plus âgé que certaines des questions "liées" que vous avez mentionnées !!!


L'âge du poste n'a pas d'importance. Le lien en double indique simplement la réponse canonique qui explique et résout le problème en profondeur pour laquelle vous n'avez pas besoin de cliquer sur le site.


3 Réponses :


3
votes

En général, ce n'est pas une bonne idée de créer le StreamedContent dans le getter pour graphiqueImage. L'image sera récupérée dans une demande séparée du reste du contenu, ce qui signifie que les variables en fonction des itérateurs ne fonctionneront pas. Cela signifie que dans l'appel pertinent à byTestostreamedContent, le tableau des octets sera null / vide. Si vous mettez des points d'arrêt à l'intérieur de la méthode, vous verrez probablement que dans le dernier appel, il n'y a pas de données en octets.

Vous devez vous assurer que l'image est générée pendant que vous avez toujours accès à tout le contenu nécessaire, puis rangez-le de manière à ce que vous vous retrouvez récupérer à nouveau dans BYTESTOSTOSTREAMEDContent. Que cela résoudra ou non le problème et que vous travaillez réellement pour vous, il est difficile de dire sans voir le reste du code. Je commencerais en essayant de supprimer l'argument de l'array d'octet et de renvoyer une image statique pour confirmer que c'est le problème.


2 commentaires

Les octets proviennent de la base de données en premier lieu et sont passés à JSF. Ensuite, à partir de JSF, j'envoie une demande d'afficher comme contenu en continu pour afficher l'image. Cependant, j'ai essayé de lire le fichier en tant qu'intrudeam de l'application SourceFiles et de créer un ajout à StreamedContent, mais il n'a pas encore rendu. Enfin, j'ai essayé d'obtenir le fichier directement à partir de la source statique comme suit: Et cette fois, il rendit avec succès avec succès. Qu'est-ce que tu penses?


Si vous utilisez quelque chose comme InputStream est = nouveau fichierInputtream ("C: \ images \ citrontree.jpg"); N'aide pas, je n'ai vraiment aucune idée de ce qui ne va pas. Je suis surtout préoccupé par le paramètre Car.Image ne fonctionne pas comme vous le pensez.



4
votes

C'est un problème étrange et je ne pense pas que l'ajout du type MIME à web.xml le réparera. Il est répertorié à la fois comme un bogue dans les principaux pourvers avec une cible pour 3.2

http://code.google.com/p/primefaces/issues/detail?id=3546 p>

et il est également répertorié comme un bug ouvert dans Mojarra 2.1.1. Il existe un correctif soumis pour ce bogue, mais on dirait que vous devrez appliquer manuellement le code à la source Mojarra 2.1.1 et la construire. On pourrait penser que cela serait fixé à 2.1.3 Cependant, Glassfish pourrait avoir sa propre implémentation de Mojarra prédudcaire qui est toujours à une version de bienfaisance et que votre application peut l'utiliser à la place. P>

http://java.net/jira/browse/javaserverfaces-2103 p>

Modifier: strong> p>

Vous pouvez simplement transmettre l'octet [] directement sous forme d'argument de la méthode comme celle-là. Ce que vous pouvez faire si vous pouvez passer l'identifiant de la voiture en tant que param, puis récupérer cette voiture et récupérer les octets de l'entité de la voiture. La raison en est que le graphiqueImage (code> rend-il en réalité en tant que balise HTML IMG code> IMG CODE> dans une requête HTTP distincte à partir de la demande de la page JSF. Téléchargez et installez le plugin Firebug pour Firefox et vous le verrez que la page est demandée, puis les demandes suivantes se produisent pour les images après la récupération de la page. En raison de cette vue ci-dessus et que les haricots de la liste ci-vis et de demande ne peuvent être accessibles de cette manière, mais un paramètre de requête peut toujours être transmis avec les informations nécessaires à la récupération des octets de la voiture pour l'image. P>

public StreamedContent getBytesToStreamedContent() {
  String id = FacesContext.getCurrentInstance().getExternalContext().getRequestParameterMap().get("item_id");
  //Now get the car with the id
}


3 commentaires

Alors, quelles sont mes options pour présenter mon tableau d'octets comme image sur la page JSF?


@fareed Voir la modification à ma réponse ci-dessus. Je pense que vous pouvez peut-être utiliser le graphiqueImage incorrectement.


J'ai essayé ce que tu as suggéré ici mais j'ai le même résultat. J'ai également essayé d'obtenir l'image en passant une chaîne définie directement à partir du haricot de support et je reçois la même chose, son ne pas rendu. Vraiment coincé avec celui-ci



11
votes

trouvé où le problème était. Le problème n'était pas dans le graphiqueImage. C'est parce que la balise graphiqueImage est chargée de manière dynamique (problème similaire lors de l'essai de la chargement de DataTable). Les images dynamiques ne peuvent pas être rendues directement dans DataTable ou DataGrid. (La solution de contournement est d'attribuer un param et d'apporter les images de l'ID).

Cependant, la solution est ici


0 commentaires