2012-05-31 1 views
1

Je poste ici parce que je m'interroge sur la structure d'un projet futur. Je souhaiterais faire une application Java EE en suivant le même modèle que les logiciels majeurs tels que Jenkins/Hudson, qui fournissent un .war/ear déployable et qui intègre leur propre base de données et la gestion des plugins. L'objectif final est que le téléchargement d'utilisateur et déployer la guerre/oreille « prête à l'emploi »Java EE Structure d'application avec plugins et base de données intégrée

Mes questions sont les suivantes:

  • Je veux utiliser EJB, comment dois structurer je mon projet en mon IDE? core-project + guerre-projet? Quand je veux utiliser un style HSQL ou Derby de base de données, les tutoriels que j'ai trouvés indiquent que je dois ajouter du jar/xml dans mon conteneur, ce qui va à l'encontre de l'idée "prêt à l'emploi".

  • Dernière question, et non des moindres, un plugin qui va prendre la forme d'un pot, comment peut-il être utilisé par mon application? Quelques idées/tutoriels sur cette gestion de plugins dans mon cas sont les bienvenus.

Ce projet est à des fins éducatives.

Répondre

2

En Java EE, il existe plus ou moins deux écoles qui préconisent différentes approches.

La première école, l'école traditionnelle, préconise que les applications Java EE soient toujours incomplètes, par ex. ayant des "dépendances non résolues". Une chaîne de personnes (rôles), de l'application packager au déployeur, prépare graduellement et itérativement l'application pour qu'elle puisse être exécutée. Cette école évite d'avoir des définitions de sources de données, des files d'attente de sécurité (principalement l'authentification) et des files d'attente JMS (même si ces dernières sont complètement internes à l'application) dans une archive d'application. Selon certains membres de cette première école, les applications qui en contiennent ne sont plus des applications Java EE (voir par exemple https://community.jboss.org/thread/164554)

Mais il existe aussi une autre école, qui pense qu'il existe des cas d'utilisation où tous ces éléments se trouvent dans une L'archive Java EE est en fait le meilleur moyen. Le fait que @DataSourceDefinition ait été ajouté à la spécification en est une indication, et Java EE 7 standardisera l'intégration de types de ressources supplémentaires (comme les files d'attente JMS).

Ces deux postes de blog décrit un exemple Java EE qui utilisent une base de données intégrée:

Dans de nombreux serveurs d'applications, l'idée de sources de données normalisées embarqués est un peu d'une réflexion après coup, et n'est probablement pas couvert par le TCK. En résumé, le soutien est actuellement comme suit:

Questions connexes