Reprise du message précédent :

mouarf, j'en sais rien, j'ai meme pas fait gaffe, juste que comme je voulais l'imprimer, et qu'en ligne, y'avait que la version en 23 fichiers, et que j'ai vu sur le forum qu'ils suggeraient d'utiliser le docbook du cvs...

Il y a un fichier HTML qui reprend tout les chapitres en une page dans la distribution.
Par contre la doc n'est pas très à jour par rapportà toute les possibilités de JBPM.

oué bah c ce fichier que j'ai regénéré.
et en effet, ça manque notamment d'info sur les timers, ou alors j'ai loupé un truc. t'as trouvé plus d'infos ou ? tu l'utilises?

Je n'ai pas encore cherché à utiliser les timers.
Par contre dans le répertoire des sources il y a les tests unitaires junit et notamment un ensemble d'exemples de Pattern classique utilisé dans le design de Processus.
De plus on y trouve surtout de vrais implémentations de custom Node, alors que ce n'est quasiment pas documenté.

tu m'expliques vite fait un use-case dans la vrai vie d'avoir une implementation custom d'un Node ? jusque là je vois pas trop (vu qu'y'a les actions..)

Les "nodes" (fork, join etc..) sont des étapes permettent d'implémenter un routage selon des règles prédéfinies et d'invoquer une Action autour de ce "node". L'Action c'est plutot le métier que tu vas exécuter lorsque t'es dans une étape. Pour garder cette volonté de "chain of responsability" je ne pense pas que cela soit une bonne idéee d'écrire des regles de routage dans une action.

"un use-case dans la vrai vie" siouplé

Un exemple simple qui n'est pas directement disponible automatiquement avec JBPM.
Un site en ligne qui accepte les paiements dans toute les devises.
Dans ton process tu as un noeud fork car à cette étape tu souhaites en parallele interroger differents "applis" asynchrones pour récupérer le cours actuel de la devise du client. Maintenant dès que tu recevras la première réponse, tu peux continuer ton process sans attendre la réponse des autres "applis".
Bon ce n'est pas hyper "real life" mais ça donne une idée.

euh un noeud join va pas faire ça ?

Le comportement du noeud join par defaut est d'attendre que tout les branches parallele soit parcouru avant de passer  à l'étape suivante.
Mais cela est facilement contournable en plaçant une Action au niveau du noeud join pour déclencher la suite de l'execution du process uniquement la première fois que le noeud join est atteint pour cet instance de processus.
C'est assez facilement programmable, mais comme je disais precedemment cela casse un peu le modèle Action qui sont dédié au métier et des "Nodes" dédié au routage de l'exécution du processus.
Tandis qu'en implémentant cette logique d'execution dans un "custom node", le modèle du processus demeure très fonctionnelle.

ha oui tiens, il me semblait avoir vu un parametre pour les join pour determiner s'il devait attendre toutes les branches ou avancer des que l'une d'elles rejoignait le join, ...
merci

A ressortir les jours de troll http://www-128.ibm.com/developerwo [...] 09275.html

HAY JAI UNE VRAIE QUAISTION JAVA
 
SPOSSIBLE DE FAIRE UN FOREACH SUR UNE HASHMAP ?
 
MERSSI

oui, sur le keySet /o\

tu peusx aussi iterer sur les valeurs ( Map.values() ) et sur les Map.Entry ( Map.entries() ) qui ne sont rien de plus qu'un wrapper (key,value)

jdirais bien que jtrouve bizarre qu'on puisse pas directement patater
 
for(Entry entry : mahashMap)  
 
mais jsens que je vais encore me faire incendier

ben tu peux

Heuh nan il me dit que hashmap n'est pas iterable ?

ha ben oui, pardon
for (Map.Entry entry : taHashMap.entries())

OUAIS BIN VALA QUOI, CE DIABLE DE LANGAGE BOURGEOIS OBLIGE LE PEUPLE A UN TRAVAIL EXTENUANT EN LE FAISANT TAPER PLUS QUE DE RAISON

on s'en bat les couilles.

fais du groovy si tu veux scripter en java

regarder ce suppot de satan tenter de faire diversion face a mes justes accusations

Bon, les hibernatiens, j'ai une question professionnelle :  
 

 
Comme vous le voyez, j'encapsule mes list avec un adapter, comme le fait la classe java.util.Collection, cette classe rajoute un controle de cardinalité (min max) à toute liste.
 
(merci de ne pas quoter ce code en cas de réponse)
Sachant que mes accesseurs déclarent un accès de List, qu'es-ce qui empêcherais d'utiliser cette classe comme POJO dans un mécanisme de persistence comme hibernate ?

rien
 
au cas ou ça aurait un rapport: avec hibernate tu dois gerer toi meme les deux cotés d'une relation (i.e si tu ajoutes un Eleve dans College, en admettant que t'aies une n-n, tu devrais aussi ajouter le College dans la liste qui va bien dans Eleve)

mes adapteurs sont de la choucroute interne, qui servent juste à faire de la validation sur les accesseurs de la liste. Il y a rien de visible pour celui qui regarde pas la source de la classe. C'est un peu le principe de l'IOP. Au final, je n'ai qu'une seule implémentation de la liste en mémoire, l'adapteur fait la validation et délègue ensuite.
 
(et oui, mes assocs sont bidirectionnelles).

iop ?

IOC plutot en fait non ?

ha ben écoute, je sais pas, c'est toi qui sait de quoi tu parles

il a craché dans ton iop ?

genre, je sais de quoi je parle

Salut les kids, c'est votre oncle robert qui vous parle
 
Vous le savez, en J1.5 on a droit a des génériques, ce qui est bien.
Ce qui est est moins bien, c'est que les generiques, ca fiche des sales tronche a vos types.
 
Imaginons un truc genre  
 

 
Bon la faut pas etre grand prete pour voir que c'est moche
surtout que :
 

 
et la on a un truc particulierement gratiné. Mes aiguisés instinct de codeur d'elite c++ me soufflent fortement de faire un typedef, seulement en java, yapa.
 
Donc, je me dis, feintons a grand coup d'inner class bidon
 

 
ca simplifie la vie,c 'est top, par contre eclipse me sort des  :
 

 
Bon, je pige le message d'avertissement, mais y se trouve que je veux pas serializer mon bordel, ni me prendre la tete sur des SerialVersionUID crétin dont je me fous. D'ou la question : comment que vous faites, vous ?
 
 
 
 
 
 
 

ben on utilise pas eclipse
a priori c'est juste un warning, tu dois pouvoir le desactiver nan ?
 
j'avais deja entendu parle de ca, IDEA ne fait pas chier son monde avec les serialVersionUID en tout cas

ué bon, pour ce que je fais il me suffit
 

 
bah surement, mais bon, jdemandais a tout hasard si y'avait une autre feinte(tm)
 

tu peux générer le SUID automatiquement (cliquer sur la puce du warning te propose de le faire), ce qui te vire le warning...mais c vrai que ce warning par défaut est chiant : il ne devrait être mis que dans la mesure où tu implémente Serialize...c vrai que si qqn pouvait m'expliquer l'intéret

y'en a pas, eclipse à été developpé par des mongols.

C'est pas parce qu'il dérive d'HashMap, qui elle implémente Serializable ?

 
Il ne devrait être mis que dans les classes que l'on sérialize effectivement surtout ...

ué enfin ca c'est ptet pas toujours visible a la compilation

tu écris le détecteur toî-même alors.