JSF dans jetty-équinoxe, Impossible de trouver des classes Bean dans d'autres bundles

Question

J'ai des problèmes lors de l'exécution de JSF dans un environnement OSGi. J'utilise jetty web container et equinox pour fournir la fonctionnalité OSGi. La structure de mon application est la suivante: Le premier ensemble contient toutes les bibliothèques JSF, web.xml et config.xml. Il semble que ce qui suit:

bundle1 
----src/main/java 
-------de/package 
----------Activator.java 
----------JSFResolver.java 
----src/main/resource 
------ WebContent 
----------META-INF 
-------------face-config.xml 
-------------web.xhtml 
----------start.xhtml 
-----------include.xhtml 
----libs (containing all JSF required Jars) 

La structure du second faisceau est comme suit:

bundle2 
---src/main/java 
------de/package 
----------Bean.java 
---src/main/resource 
------META-INF 
---------face-config.xml 
------WebContent 
---------index.xhtml 

Lors de l'exécution de l'application de l'équinoxe, le bundle1 est le faisceau principal où toutes les requêtes du navigateur sont envoyées à. Dans le deuxième paquet, le fichier index.xhtml peut être récupéré par le premier paquet sur demande. Le index.xhtml dans le paquet 2 obtient ses valeurs et propriétés du 'Bean.java' dans le paquet 2. Le problème vient quand je demande le 'index.xhtml', la classe Bean.java est introuvable. Je pense que c'est parce que le chargeur de classe de bundle1 ne peut pas le trouver, il n'en a aucune connaissance. Donc, je voudrais demander si quelqu'un sait comment résoudre ce problème. Si oui, aidez-moi, j'ai essayé toutes les possibilités que j'avais.

Est-il possible d'avoir JSF exécuté sur plusieurs paquets en utilisant le même FaceletsContex? Puis-je avoir des fichiers faces-config.xml séparés dans chaque bundle, qui peuvent tous être connectés à d'autres faces-config.xml dans d'autres bundles? Quelqu'un peut-il s'il vous plaît me fournir une solution. Exemple de code aiderait.

Answer 1

Si quelqu'un est intéressé par la réponse, dans ce cas, faces-config.xml ne sert à rien. J'ai donc dû utiliser le fichier plug-in.xml pour enregistrer tous mes beans dans tous les projets plug-in. J'ai créé un point d'extension dans le plug-in principal, auquel d'autres plug-ins pouvaient enregistrer leurs Beans en tant qu'extension. J'ai dû remplacer la classe managedBean de JSF pour qu'elle soit capable de lire les propriétés du bean depuis le point d'extension plutôt que depuis le faces-config.xml. Ainsi, pendant l'exécution, l'application lit toutes les extensions enregistrées dans le point d'extension managedBeans, puis crée toutes les instances de bean requises à partir de tous les plug-ins. Par conséquent, l'erreur ne sera plus là. Si quelqu'un veut implémenter JSF dans une telle structure, sachez que presque toutes les fonctionnalités de faces-config.xml devront être déplacées dans le plug-in.xml des plug-ins, ceci inclut également les règles de navigation . Il faut faire beaucoup de personnalisations mais à la fin, vous obtenez une belle application JSF modulaire fonctionnant sur équinoxe, sans avoir à l'incorporer dans un fichier .WAR .. ce qui semble être très avantageux.