Discussion :

[stephane.combes]

Bonjour,

J'ai un serveur Glassfish configuré avec un pool de connections vers un base de données MySQL d'une part. D'autre part j'ai une application avec des fenêtres en Swing qui accédent à cette même base de données. Du coups je voudrais bien utiliser le pool de Glassfish plutôt que tout me faire à la mimine.

Dans mon serveur Glassfish v3.1 j'ai créé :

• un pool de connection (jProductBaseMySQLPool) vers mon serveur MySQL.
• une ressource JDBC (jProductBaseResource) qui utilise le pool précédent.

Maintenant je fais un projet java SE sous Eclipse avec comme main :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
 
	public static void main(String[] args) {
		try {
			InitialContext ctx = new InitialContext();
			javax.sql.DataSource ds = (javax.sql.DataSource) ctx.lookup("jProductBaseResource");
			Connection c = ds.getConnection();
			PreparedStatement  stmt = c.prepareStatement("SELECT * FROM productType");
			ResultSet rs = stmt.executeQuery();
 
			while (rs.next()) {
				System.out.println("\nProductType : ");
				System.out.println("\tidProductType : "
						+ rs.getInt("idProductType"));
				System.out.println("\ttimestamp : " + rs.getInt("timestamp"));
				System.out.println("\tstate : " + rs.getInt("state"));
				System.out.println("\tname : " + rs.getInt("name"));
			}
			c.close();
			ctx.close();
		} catch (SQLException e) {
			// TODO Auto-generated catch block
			e.printStackTrace();
		} catch (NamingException e) {
			// TODO Auto-generated catch block
			e.printStackTrace();
		}

Qui me renvois l'erreur suivante :

Code :

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

1
2
3
4
5
6
7
 
javax.naming.NoInitialContextException: Need to specify class name in environment or system property, or as an applet parameter, or in an application resource file:  java.naming.factory.initial
	at javax.naming.spi.NamingManager.getInitialContext(Unknown Source)
	at javax.naming.InitialContext.getDefaultInitCtx(Unknown Source)
	at javax.naming.InitialContext.getURLOrDefaultInitCtx(Unknown Source)
	at javax.naming.InitialContext.lookup(Unknown Source)
	at Main.main(Main.java:17)

Précision : la ligne 17 c'est celle qui contient ctx.lookup...


J'erre sur le web depuis ce matin sans succés. Je suis parti de l'exemple fournis sur : ici mais je ne vois pas où ca pêche.


Si vous avez des pistes ou tutos concernant cette problèmatique je suis preneur.

Merci.


S. Combes

[tsegismont]

Je comprends pas vraiment l'idée de récupérer le pool de connexions JDBC de Glassfish dans ton application Swing.

Si ton problème c'est juste d'avoir un pool de connexions JDBC robuste, il y a des solutions :

http://commons.apache.org/dbcp/

ou

http://www.mchange.com/projects/c3p0/

[stephane.combes]

Bonjour,

Je comprends pas vraiment l'idée de récupérer le pool de connexions JDBC de Glassfish dans ton application Swing.

En fait sur mon serveur Glassfish je vais avoir une application qui utilisera une librairie commune avec mon appli Swing. Dans cette librairie j'ai mes couches service, métier et dao (qui gère actuellement la connexion à la bdd "manuellement").
Mon appli Swing n'est qu'une façon de présenter les données, elle ne contient que la couche présentation.

Je voudrais donc gérer une seule façon de me connecter à ma bdd, que ce soit avec mon appli Swing ou mon appli web. Je vois pour cela 2 solutions :

• utiliser le pool de Glassfish
• utiliser un autre pool (comme ceux que tu as cités)

Glassfish proposant déjà le pool autant l'utiliser

Voila, je ne sais pas si mes explications sont suffisamment claires. Aussi, si vous avez besoin de plus de détails pour apporter une réponse pertienente je me ferais un plaisir de vous les fournir

S. Combes

[fxrobin]

soit tu fais "à l'ancienne" avec un pool de connexions DBCP comme recommandé plus haut, soit tu "attaques" des EJB Session ou encore des WebServices qui seront deployés sur le serveur GlassFish à partir de ton application Swing distante. Ces EJB ont bienûr accès directement au pool déclaré dans GlassFish.

Ca te permet d'avoir la partie "métier" et la persistance sur le Serveur. Le client Swing n'étant vue que comme une interface graphique.

[stephane.combes]

Merci pour les pistes

Je vais voir du côté des EJB et des WebServices. Par contre je ne mettrais que la partie persistance car mes clients Swing doivent continuer à fonctionner en cas de perte du serveur, c'est d'ailleurs pour ça qu'ils sont en Swing

Je vous tiendrez au courant d'ici quelques semaines car je suis actuellement sur un autre projet.

[fxrobin]

oula, une application "conenctée / déconnectée" est encore un autre problème.
Il te faudra une base "locale" embarquée (genre HyperSonic) pour persister le travail des utilisateurs quand l'accès distant est absent ...

et pour le coup les EJB Session, ça ne vas pas ou alors il faut que tu puisses basculer d'une implémentation distante à une implémentation locale et inversement quand la connectivité est présente ou non.

Bref, ce n'est plus du tout le même problème que d'accéder au pool de connexions GlassFish

Regarde Funambol (en 2005 j'avais pu faire qqs essais concluants) pour cette problématique : http://sourceforge.net/projects/funambol/ ou encore : http://forge.ow2.org/projects/sync4j

ou encore SyncML : http://developers.sun.com/mobility/m...ticles/syncml/

et enfin : http://stackoverflow.com/questions/2...ynchronization

[stephane.combes]

Pas de panique

C'est juste qu'en mode déconnecté les données de la base ne sont pas accessibles. L'utilisateur peut continuer à faire des saisies qui sont enregistrées dans des fichiers XML que le poste transmet au serveur dés que possible (en mode connecté c'est pareils). Les aides à la saisie ne sont pas dispo et l'utilisateur et averti par des messages qu'il doit bien vérifier ces saisies.

Sur le serveur j'ai un module qui se charge de vérifier et enregistrer les fichiers XML dans la base de données.

[fxrobin]

tiens nous au courant.
Les EJB Sessions c'est du mode connecté sur RMI-IIOP.
Les WebServices, c'est sur HTTP donc "fire & forget"

Mais peux faire du WebService a base de EJB Session Stateless ce qui a pas mal de vertus, surtout en terme de transactionnel et de montée en charge ...

Dans ton cas, j'utiliserais donc WebService avec EJB Stateless.