Quels haricots vont dans le contexte d'application contre le contexte Web au printemps?

Question

La séparation entre contexte d'application et contexte web (et les problèmes de chargeur de classe qui en découlent) sont une source constante de problèmes pour moi. J'utilise Spring dans mon premier projet, migrant d'une application Web basée sur JSP mal écrite à Spring.

Je veux juste savoir si cette configuration est logique:

• Je les contrôleurs, les objets de forme, et tels que définis à l'aide des annotations et scannés dans le contexte de l'application Web. J'ai déplacé les DAO (objets d'accès aux données) dans le contexte de l'application après les avoir initialement dans le contexte de l'application web - parce que je devais les utiliser pour obtenir l'utilisateur/mot de passe pour la sécurité printanière. .
• Sécurité de ressort si elle est définie (selon les documents) dans le contexte de l'application, ce qui nécessite DAO pour l'accompagner.

Maintenant, je suis en cours d'exécution sur les questions de classloader où je passe un objet à JDO/DataNucleus et il est créé par l'application classloader, mais les OTI font tous partie du contexte d'application, ainsi que le composant obtient son propre classloader et ne peut pas faire correspondre les mêmes objets.

Méthode simple de DAO:

@Override 
public boolean userExists(String username) { 
    Query query = pm.newQuery(User.class); 
    query.setFilter("username == :usernameParam"); 
    query.setResult("count(username)"); 
    query.setResultClass(Long.class); 
    System.out.println(username); 
    Long result = (Long)query.execute(username); 

    return (result!=null && result>0); 
} 

javax.jdo.JDOUserException: La requête retourne un seul champ, mais il est pas d'un type cohérent que la ResultClass (java.lang. long): Il est java.lang.Long

Je demande parce que ce n'est pas le premier numéro de classloader (et je ne crains pas la dernière) pour faire apparaître en raison de la façon sprin g est configuré en ce moment, donc je me demande si je fais mal les choses. Ou peut-être existe-t-il des configurations qui traitent de ces types de problèmes de chargeur de classe que je ne connais pas encore?

Answer 1

Le classloader ne doit rien avoir à faire avec le contexte Spring. Le contexte d'application Web est un conteneur de ressort qui contient généralement des contrôleurs et des résolveurs de vue. Le contexte de l'application contient le dao. Le contexte de l'application Web a le contexte de l'application en tant que parent, de sorte qu'il peut accéder aux beans dao et service et non vice versa. Cependant les deux contextes font partie de la même guerre et devraient être chargés par le même chargeur de classe.

En regardant votre exception, je pense, il ne semble pas avoir quelque chose à voir avec Spring.