Reprise du message précédent :

Je ne savais pas qu'il installait un driver, désolé d'avoir raté cette étape.
 
Tant pis Merci pour votre aide !  

Sans doute déjà passé, mais ce blog est excellent: http://mechanical-sympathy.blogspot.co.uk/
 
Rare qu'on apprenne des trucs pratiquement à chaque post dans un blog.

J'ai un projet ou weblogic est le serveur pour héberger nottament des ejb, et le client est du client lourd qui accède à ces services ejb.
 
L'appli côté serveur utilise spring.
Il y a un objet singleton qui wrappe en gros un contexte spring, et qui l'instancie si il n'a pas déjà été instancié.
Donc le contexte spring n'est instancié que lors du premier appel à un service.
C'est moche, car ça créé une dépendance pas terrible, qui empêche d'utiliser différents contextes spring pour du test junit, et on voit certains problèmes potentiels que à la première connection, plutot qu'au démarage du serveur.
 
Donc comme autre solution, je vois par exemple une déclaration dans le web.xml, cependant dans le principe on a essentiellement des ejbs, donc je ne peux m'empêcher de me demander comment on ferait sans web.xml.
 
J'ai aussi entendu une solution à base de resource adapter, mais ça me parait un peu compliqué par rapport au besoin de base qui est simplement d'instancier le contexte lorsque l'ear est deployé.
 
Il y a peut être encore plus trivial

Le plus trivial, c'est le listener dans web.xml.
Mais la vrai question est de savoir pourquoi vous melanger Spring et EJB et est-ce vraiment necessaire?

 
je voulais dire déclaration dans un web.xml
actuellement il y a un war, mais le web.xml est autogéréné par le générateur de webservice de weblogic, donc non éditable.
Est ce qu'on peut mettre plusieurs wars dans un EAR ?
 

 
Spring est prévu pour être mélangeable avec d'autres technologie, donc ça ne me parait pas être une vraie question.
 
Si ça ne tenait qu'a moi et que j'avais des ressources illimitées pour le faire, je tenterais de virer les EJB.
Mais dans un projet d'entreprise tu n'obtiens pas de crédit pour changer un truc qui marche très bien.
Même si c'est naze et vieux.
Il faudrait vraiment que ça nous bloque ou que personne ne connaisse.
Ou bien que ça soit migrable très très rapidement.
 
A priori la politique est de passer vers de l'open source si c'est possible, comme tomcat, mais avec des ejb c'est mort, donc là il y aurait moyen d'obtenir une bonne raison.
Sauf que je pense que ça ne sera fait que si on a pas le choix, parceque le boss s'en branle d'avoir un truc vieux lourd et naze.

Concernant les EJBs (2.0) qui m'a soulé récement, c'est qu'on ne peut pas utiliser d'annotations sur les classes ejb bean, parceque weblogic fait de l'aop qui génère de nouvelles classes a partir de la classe originale, et il ignore les annotations.
 
Du coup on ne peut ni faire d'aop spring ni par annotation, ni même par xml.
 
et on l'a bien comme ça  
 
reste plus qu'a faire un délégate et le peupler avec un truc deg dans le ejbcreate

Euh, oui mais non.
 
1) Moi je parle bien de déclarer le listener de Spring dans le web.xml de ton war. Maintenant, si tu ne peux pas éditer ton web.xml, ca semble un peu mort (mais faudra qu'on m'explique pourquoi vous laisser cela aux mains poisseuses de Weblo...)
 
2) On peut bien sur mettre plusieurs WAR dans un EAR, c'est même LE gros avantage des EAR. Par contre, si les librairies sont partagées, les contextes ne le seront pas (du moins la plupart, et surtout pas ceux de Spring), donc à moins que tes EJB soient totalement indépendant de tes beans Spring et que tu puissent les déporter comme webservices internes, c'est mort.
 
3) Spring est prévu pour être mélangeable, oui, mais si il y a bien une technologies qui se mélange moins bien que les autres, c'est les EJB. Quand tu commences a mixer EJB et Spring, tu te retrouves avec des contexts d'application différents, et c'est souvent la merde pour la gestion des lifecycles. D'où ma réflexion précédente.
 
4) Avec TomEE, tu te retrouve avec un serveur Tomcat compliant WebProfile, et donc tu peux utiliser les EJB 3.1 avec CDI et tous les trucs sympas
 
5) Si tu es bloqué aux EJB 2.0, fuis!

1/ Sérieusement tu bosses dans quel genre d'entreprise ?
 
2/ non, les springs bean sont des services appellés par les ejb
les ejb servent juste pour du remote, et la sécurité du remote
 
3/ oui mais là c'est juste pour du remote
il y a même pas de gestion de transaction inter ejb
c'est du state less sans ejb
 
4/ Oui mais pour ça il faudra passer à autre chose que weblogic 9, t'inquiète j'ai regardé
Sauf que là les webservices sont générés par une librairie weblo automatiquement, à partir de certains ejb, et ce truc n'est plus compatible avec les versions suivantes.
 
Je suis le premier à vouloir le virer, mais honnêtement je connais peu de boites où les boss prennent ce genre de risques.
Les types une fois qu'ils sont passés interne, ils préfèrent gérer pépère en pantoufles.
Et pourquoi ils feraient autrement ?
Il s'en branlent, ils sont passé interne justement pour ça. lol
 
5/ Encore ça va c'est juste en remote, pas en entity.
J'ai pas que ce projet.
Déjà j'ai réussit à intégrer des annotations, de l'aspect, et délégué le business codé direct dans les ejbs dans des services springs.
Mais pour dégager tous les ejb, les webservices et migrer a weblo 10, sachant qu'il faut quasiment tout faire en même temps, je crois que le gros tas de gravats à franchir est vraiment trop dissuasif

On cherche à optimiser des EJB3. Pour bencher les temps d'exécution, @AroundInvoke ou il existe des trucs plus sioux ?

Hors lib externe, auquel cas mon choix se porterait certainement sur Metrics.

Edit : un truc configurable, histoire de garder le code mais désactiver les mesures en prod, ça serait le top.
Redit : au cas où vous soyer un gros fan d'une API particulière pour faire ça, balancez le nom quand même

un truc comme perf4j couplé avec togglz?

 
Perf4J j'aime pas, ou disons que je lui préfère Metrics. Je ne connaissais pas Togglz, ça a l'air chouette, particulièrement au niveau des Activation Strategies. Tu l'utilises (monitoring ou autre d'ailleurs) ?

Oui, je l'ai utilise. C'est assez pratique lorsque tu veux faire des migrations sans downtime. Tu deploies ta nouvelle version avec features desactivees, tu migres les donnees en background et ensuite, tu choisis de reactiver soit en bloc soit pour les utilisateurs qui ont deja leurs donnees migrees.
 
PS: Merci pour Metrics, j'avais perdu celui-la de vue.

Je suis plus étanche, mais ça sent la fausse bonne idée à plein nez.
 
J'ai une vue partielle qui est partagée par tous les utilisateurs, qui change peu et qui est longue à générer. Genre un compteur d'inscrits, c'est pas ça mais ça colle à mon ratio lecture / modification.
 
La partie longue à générer n'est pas côté métier ou persistance (donc pas de cache d'entités), mais bien au niveau de la vue : c'est le formatage des données pour les besoins de l'affichage qui prend des cycles (parcours de plusieurs liste avec création d'autres, mais pas que).
 
Du coup, je réfléchi à mettre en cache les données de cette vue partielle, et plutôt que de partir sur une API de cache applicatif, je pensais que vu le besoin vraiment faiblard, un simple champ statique avec mes valeurs conviendrait (avec un mécanisme d'invalidation qui va bien évidemment), champ qui serait donc dans la classe de mon partiel.
 
C'est tout con et ça marche, mais j'ai l'intuition que je passe à côté d'une énormité, j'ai des relents de singleton et de variable globale.

Salut les gens,

Je cherche une lib JDBC connection pool pour du JSE vers Oracle (gros volumes d'insert en // )
J'ai du c3p0 sous la main et j'ai trouvé BoneCP (up-to-date ?) ou encore DBPool (up-to-date apparemment).

z'avez mieux sous le coude ?

Java 6: Tomcat Jdbc Pool
Java 7: HikariCP

pour le 7, je jette donc un oeil sur HikariCP
(rien à voir, mais j'adore le design de sa page et en particulier la font )

edit> à creuser, mais ça m'a bluffé: https://github.com/brettwooldridge/ [...] abbit-Hole

Merci pour le pointeur sur HikariCP
Des retours d'expérience?

Pas en prod, non, je suis toujours coincé sur java 6 pour mon projet actuel
Mais en première investigation, ca dépottait plutôt pas mal.

Je voudrais faire du dispatch d'appels méthode, c'est à dire que si une méthode est appelée sur un objet et n'est pas présente, que ça appelle cette même méthode sur un objet membre.
 

public class Partial {
    public String getBar() { return "bar"; }
}

public class Container {
    private Partial partial;
    public String getFoo() { return "foo"; }
}

new Container().getFoo(); // 'foo'
new Container().getBar(); // 'bar'

 
C'est possible ça ? Il me manque peut-être juste les mots clé, je suis pas sûr que ça s'apparente vraiment à du proxy. Ça me parait tendu de faire ça sans que ça ne saute à la phase de compilation, du coup pour le moment le seul truc (crade) que je vois c'est de mapper les appels à une méthode de signature équivalente dans le container.

public class Partial {
    public String getBar() { return "bar"; }
}
 
public class Container {
    private Partial partial;
    public String getFoo() { return "foo"; }
}
 
new Container().getFoo(); // 'foo'
new Container().getBar(); // 'bar'

Proxy + InvocationHandler.

 
OK, c'est à ça que je pensais. Maintenant, en partant sur cette solution, j'y vois deux contraintes (il y a certainement pelleté d'obvious ou d'incompréhension) :
 

• ça m'oblige à extraire une interface de Container et d'y mentionner toutes les méthodes à mapper ;
• l'InvocationHandler gère le dispatch en fonction du nom de la méthode (comparaison par string (?), donc error prone), ou teste sa présence dans les objets contenus et contenant, et s'arrêter au premier match.

Si j'ai tout saisi, c'est pas la mort mais j'aurais aimé un truc qui gère tout ce merdier pour moi. Avec cette solution, je trouve qu'il n'y a pas moins d'overhead que si j'encapsulais les appels, du style  
 

public class Container {
   private Partial partial;
   public String getFoo() { return "foo"; }
   public String getBar() { return this.partial.getBar(); }
}

 
Je rate un truc ?

Sinon, y a lombok avec @Delegate

bon, les jeunes, native2ascii c'est encore utile en 2014, ou y'a plus moyen qu'un connard foute tout en l'air (je sais pas si/comment Git gère unicode, par example, ni l'état des outils sous windows)

public class Container {
   private Partial partial;
   public String getFoo() { return "foo"; }
   public String getBar() { return this.partial.getBar(); }
}

tu peux faire du proxy de classes concrètes avec cglib, et des libs genre ProxyToys rendent ça un poil plus simple/lisible

Oui, comme dit moinmoin faut utiliser CGLIB si tu veux proxifier un type concret.

IIRC l'InvocationHandler tu l'implémentes comme tu veux, c'est l'équivalent d'un method_missing en ruby ou d'un __getattr__ en Python.

 
hélàs oui, c'est encore nécessaire  

 
Ça colle, mais je suis pas chaud pour un si petit besoin (rapport au plugin nécessaire sur l'IDE et au fait qu'une API comme celle-ci n'est pertinente que si tu en fait un coding style).
 

 

Je regarde tout tout ça, merci les hommes
 

 
On utilise encore régulièrement DBCP et quand je vois les infos dans leurs benchs, je me dis que c'est de la perf gagnée pour pas cher.
Surtout sur du batch.

Hmm des raisons plus précises? Le seul truc auquel j'ai pu penser c'était les commits accidentels qui étaient bien trop facile avec svn (piske ça commit tout sous le chemin courant) par rapport à git ou faut qd même vouloir pour commiter accidentellement...

 
Ben pour des fichiers de bundles dans des langues exotiques, par exemple ?
On doit pas parler de la même chose, parceque je vois pas le rapport avec les commits

Ach, pardon. Les fichiers en question n'ont pas besoin d'être ASCII-encodés à tout prix, le système fonctionne avec du UTF8 par exemple. Seulement si t'as un guignol qque part sur une plateforme moisie qui comprend pas l'utf8, la vie des fichiers en question est compromise. Ça nous est arrivé plusieurs fois sur svn donc on a forcé native2ascii. Le risque semble moins élevé avec git. Bon cela dit faudrait ptet tjs un mécanisme pour s'assurer qu'on ajoute que du utf8 du coup...

bon, autre chose: http://robertjchristian.github.io/fs2/ c'est une blague en fait ? L'API est à moitié torchée (notamment FS2Factory/FS2Configuration qui ressemble à une bonne idée de loin, mais qui de près ne marche juste pas; enfin si, mais faut tout sous-classer, y'a des trucs qui sentent le faux use-case mal pensé)
 
Puis l'idée d'utiliser des URI partout, c'est choli, sauf que de toutes façons on peut rien en faire en dehors de cette API, y'a pas de ProtocolHandler avec)
 
Mais surtout... la page du projet semble sous-entendre qu'il existe des providers pour une chiadée de système de stockage, mais en réalité y'a que "mem" et "file", les autres c'est du vent !?

tout est en 'to be implemented'... et Mongo est dans la roadmap.
et pas de mouvement depuis 1 an sur le git hub...

Urgh, ouais j'ai vu ça après. Du vent, quoi...
Y'a autre chose dans le genre? Commons-vfs, j'ai les même préjugés que tous les commons, mais je vais checker qd même...

J'ai une map indexée sur une clé composite.
 
Est-ce qu'il existe une structure de données, API, algo ou whatever pour accéder aux éléments dont la clé satisfait un des critères sans pour autant me taper un parcours en O(n) ?
 
Genre

class Key {
    Integer foo;
    String bar;
    // equals, hashcode...
}
 
Map<Key, Object>.get(String banana) // Me renvoi un set des éléments dont bar = banana

class Key {
    Integer foo;
    String bar;
    // equals, hashcode...
}
 
Map<Key, Object>.get(String banana) // Me renvoi un set des éléments dont bar = banana

Un arbre correspondant au problème doit te permettre une recherche en O(log(n)). Sauf que t'auras besoin d'un arbre par critère (cf index de db)

Tu as les Table de Guava qui font partiellement ça, tant que tu n'as que deux éléments à ta clef.

Si on doit maintenir autant de structures que de critères, quel est l'intérêt de l'arbre par rapport à la map classique ? J'encapsule n map chacune indexée sur un critère et ça passe avec une complexité plus basse non ? J'ai un nombre d'éléments maîtrisé, pas de souci avec le hashcode et pas besoin de parcours.  
 

 
Oui, et Apache MultiKeyMap aussi, je regarde ce que ça donne. C'est justement pour interagir avec un cache Guava, je voudrais invalider des entrées (dont la clé est composite) selon l'un des critères.

Une hashmap ne permet que des égalités, un btree permet des ranges et n'a pas besoin d'une fonction de hachage.