Discussion :

[zegreg]

Bonjour,

je poste ici, mais peut-être que ça devrait être dans J2EE/EJB (?) ...

Voilà mon problème...
Je me retrouve dans un contexte d'un EJB qui fait un locate d'une resource de cette manière :

ClassLoader loader = Thread.currentThread().getContextClassLoader();
return loader.getResource(fileName);

La recherche de la resource se fait bien, mais visiblement ne fonctionne pas toujours... Donc en gros, sur ma machine en local, pas de problème, même sur d'autres machines... Mais sur d'autres environnements cela ne fonctionne pas et cela me renvoie null...

Qu'est-ce qui peut faire que d'un environnement à l'autre le locate ne fonctionne pas? (Config serveur d'application ? Windows/Linux?) Je précise que le déploiement se fait de la même manière sur toutes ces machines...

Merci d'avance

Greg

[thibaut]

Le classpath est différent ???

[zegreg]

Au niveau du manifest de l'EJB c'est identique. Et pour le classpath du serveur d'application on essaie en général de ne pas trop y toucher...

Sinon au niveau du deploiement cela fait une structure comme suit :

Appli

- classes

- lib

- le jar de l'ejb

- resource

- laresource

Est-ce qu'il a du mal avec la structure? Mais bon cela n'explique pas pq ca marche sur certains environnements et pas d'autres...

[manblaizo]

Salut,
Le problème que tu as est principalement dû aux "EJB Programming Restrictions" qui constituent un certain nombre de restrictions dont le principal but est d'assurer la portabilité des enterprise beans. Je ne sais pas quelle version des EJB tu utilises, mais pour ce qui est de EJB 2.1 par exemple, tu pourrais consulter le chapitre 25, paragraphe 25.1.2 de la spécification. Il y est entre autres écrit :
The enterprise bean must not attempt to create a class loader; obtain the current class loader; set the context class loader; set security manager; create a new security manager; stop the JVM; or change the input, output, and error streams.
These functions are reserved for the EJB container. Allowing the enterprise bean to use these functions could compromise security and decrease the container’s ability to properly manage the runtime environment.
Il y a également des restrictions quant à l'utilisation des threads dans les EJB. En gros, c'est pour ne pas empiéter sur ce qu'est notamment le travail du conteneur, et effectivement dans de telles circonstances, le comportement peut varier d'un conteneur à un autre. C'est ce qui expliquerait par exemple pourquoi ton code (qui crée un class loader) fonctionne sur certaines configurations et pas sur d'autres, c'est bien parce qu'il n'est pas portable.
En espérant t'avoir aidé.

[zegreg]

Merci de ta réponse.

Y a-t-il d'autres moyen alors de faire un "locate" dynamique d'une resource à partir d'un EJB? En utilisant pas de classloader... Ou bien faudra-t-il coder le path en "dur" (enfin en relatif du moins...). Je sais que Spring a ce genre de classes pour ses fichiers de config, mais peut-être que cela existe de façon générique?

[manblaizo]

Hum, je n'ai jamais essayé, mais je crois avoir lu quelque part qu'on pouvait associer le répertoire du fichier à un nom JNDI et puis faire un lookup dans l'EJB... Par contre, en réfléchissant encore un peu au problème je me dis que pour ne pas trop compliquer les choses, on pourrait très bien exploiter encore ton idée de départ, en faisant dans le code de l'EJB :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
this.getClass().getResourceAsStream("/filename");
ou
this.getClass().getResource("/filename")

Bien évidemment, il faudrait que le fichier se trouve dans le classpath, en le mettant par exemple à la racine de ton jar.
Cordialement.