Discussion :

[Loko]

Bonjour

Je souhaite développer du code java générique qui sera disponible dans toutes mes routes (plusieurs centaines), via des cProcessor.

Je voudrais tout bêtement envoyer des mails, mais par exemple si j'écris "import javax.mail.*" dans un bean il ressort en surligné rouge et le studio me dit qu'il est introuvable.
Si je tape "import org.apache.camel.*" il ne le trouve pas non plus ... mais cela compile et cela fonctionne quand même (par contre c'est moins pratique à développer car on a pas l'autocomplétion/suggestion).

--> comment savoir la liste des librairies disponibles en dev java dans les beans ?
--> comment en ajouter ?

Pour l'exemple des mails, je vois bien pourtant un fichier "javax.mail_1.4.0.v201005080615.jar" dans Studio/plugins (?). Evidemment, la solution d'ajouter la librairie directement dans la route via un cConfig ne convient pas, on ne pourra pas modifier plusieurs centaines de routes à chaque fois que l'on voudra modifier ce code "générique".

NB : j'utilise Talend Open Studio for ESB 6.3, mais j'imagine que ce problème est générique à toutes les déclinaisons Talend.

Merci
Loko

[supergeoffrey]

De ma vision de TOS
ça doit marché pareil avec l'esb, je pense.


Les jars ajoutés aux exécutables sont définis dans les composants de Talend.
C'est à dire lorsque tu ajoutes un composant dans un job (ou route de syndication dans l'esb), Talend est capable de faire référence à ton jar.

Dans le cas de tes routines, tu fais références à des jars qui ne sont pas chargés par tes composants, donc quand tu les Exécute, tu dois faire face soit à des erreurs de compilation, soit à des ClassNotFoundException

Dans les jobs classiques TOS (existe aussi en ESB) , tu pourrais ajouter des tLibraryLoad dans un job fils appelé dans un tRunJob pour résoudre tes problème de dépendances.

[Loko]

Bonjour

Dans le cas de tes routines, tu fais références à des jars qui ne sont pas chargés par tes composants, donc quand tu les Exécute, tu dois faire face soit à des erreurs de compilation, soit à des ClassNotFoundException

C'est un peu plus compliqué que cela, je pense. Car bcp de librairies sont disponibles par défaut sans avoir besoin de les ajouter via des composants dans les jobs ou les routes. Tu peux les voir par autocomplétion dans une routine ou un bean quand tu commences à taper "import ...", on trouvera une liste avec par exemple java.util, org.apache, etc ... Ce que je voudrais c'est comprendre où il prend ces librairies pour en ajouter d'autres, sans passer par un composant lourd à maintenir.

Dans les jobs classiques TOS (existe aussi en ESB) , tu pourrais ajouter des tLibraryLoad dans un job fils appelé dans un tRunJob pour résoudre tes problème de dépendances.

Possible, mais pas bon en terme de performances, surtout sur un mix route/job.

[Loko]

Je viens de trouver, pour ceux à qui cela pourrait servir : clic droit sur le bean dans la vue Repository puis "edit bean librairies".