Re: debugging model classes tied to Tomcat datasources
> I'll bet the only thing your code does with a JNDI string is perform the lookup and get a Datasource. You could implement multiple constructors allowing your code to be initialized w/ a JNDI string, DataSource object, or url/username/password. The code utilizing the model classes would simply create them using which ever constructor it has data for. --David David, Sorry for the late reply (this darn this called "life" keeps butting in). This approach is working for me; thanks for offering it. Charles & Mark, thank for your responses as well. Sincerely, Eric - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: debugging model classes tied to Tomcat datasources
Martin Gainty wrote: > http://tomcat.apache.org/tomcat-5.5-doc/jndi-resources-howto.html > is a JNDI 'emulator' Huh? Care to explain what you mean by that remark? > i heard chilisoft was implementing JNDI for Tomcat but EOL'ed when Glassfish > came out > I wonder if anyone can resurrect? What was/is missing from Tomcat's JNDI implementation that makes you think that is necessary? Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: debugging model classes tied to Tomcat datasources
http://tomcat.apache.org/tomcat-5.5-doc/jndi-resources-howto.html
is a JNDI 'emulator'
i heard chilisoft was implementing JNDI for Tomcat but EOL'ed when Glassfish
came out
I wonder if anyone can resurrect?
thanks
Martin
__
Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité
Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger
sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung
oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem
Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung.
Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung
fuer den Inhalt uebernehmen.
Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le
destinataire prévu, nous te demandons avec bonté que pour satisfaire informez
l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est
interdite. Ce message sert à l'information seulement et n'aura pas n'importe
quel effet légalement obligatoire. Étant donné que les email peuvent facilement
être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité
pour le contenu fourni.
> Date: Sun, 27 Sep 2009 15:27:35 -0400
> From: mark.shif...@yale.edu
> Subject: Re: debugging model classes tied to Tomcat datasources
> To: users@tomcat.apache.org
>
> Martin Gainty wrote:
> > Mark
> >
> > have you been able to implement JNDI (standalone) in TC?
> >
> No, I never tried.
>
> > i see craig's comment on implementing JNDI in
> > org.apache.catalina.Container.java
> > * Resources - JNDI directory context enabling access to static
> > * resources, enabling custom linkages to existing server components
> > when
> > * Catalina is embedded in a larger server.
> > *
> > i *thought* Catalina would need to be 'embedded' into A J2EE AppServer
> > (such as Glassfish)
> > to implement JNDI functionality?
> >
> > thanks,
> > Martin Gainty
> > __
> > Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité
> >
> > Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene
> > Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte
> > Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht
> > dient lediglich dem Austausch von Informationen und entfaltet keine
> > rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von
> > E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen.
> > Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le
> > destinataire prévu, nous te demandons avec bonté que pour satisfaire
> > informez l'expéditeur. N'importe quelle diffusion non autorisée ou la copie
> > de ceci est interdite. Ce message sert à l'information seulement et n'aura
> > pas n'importe quel effet légalement obligatoire. Étant donné que les email
> > peuvent facilement être sujets à la manipulation, nous ne pouvons accepter
> > aucune responsabilité pour le contenu fourni.
> >
> >
> >
> >
> >
> >> Date: Sun, 27 Sep 2009 12:38:11 -0400
> >> From: mark.shif...@yale.edu
> >> Subject: Re: debugging model classes tied to Tomcat datasources
> >> To: users@tomcat.apache.org
> >>
> >> Hi:
> >> This is what I do for testing. I made a class for creating a jndi
> >> directory and I create this in my main, then I can get a datasource from
> >> the jndi directory just like I do it when running tomcat.
> >>
> >> jndi.properties
> >> java.naming.factory.initial=org.apache.naming.java.javaURLContextFactory
> >> java.naming.factory.url.pkgs=org.apache.naming
> >> java.naming.provider.url=java
> >>
> >>
> >> public static void create_JNDI(){
> >> //jndi.properties must be on the classpath to make the
> >> initial context
> >> //you can either add the environment manually vida infra
> >> or have a jndi.properties file
> >> /* Hashtable env = new Hashtable();
> >>
> >> env.put(Context.INITIAL_CONTEXT_FACTORY,"org.apache.naming.java.javaURLContextFactory");
> >> env.put(Context.URL_PKG_PREFIXES,"org.apache.naming");
> >> env.put(Context.PROVIDER_URL,"java");
> >> Context initial = new In
Re: debugging model classes tied to Tomcat datasources
Martin Gainty wrote:
Mark
have you been able to implement JNDI (standalone) in TC?
No, I never tried.
i see craig's comment on implementing JNDI in org.apache.catalina.Container.java
* Resources - JNDI directory context enabling access to static
* resources, enabling custom linkages to existing server components when
* Catalina is embedded in a larger server.
*
i *thought* Catalina would need to be 'embedded' into A J2EE AppServer (such as
Glassfish)
to implement JNDI functionality?
thanks,
Martin Gainty
__
Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité
Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen.
Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le
destinataire prévu, nous te demandons avec bonté que pour satisfaire informez
l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est
interdite. Ce message sert à l'information seulement et n'aura pas n'importe
quel effet légalement obligatoire. Étant donné que les email peuvent facilement
être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité
pour le contenu fourni.
Date: Sun, 27 Sep 2009 12:38:11 -0400
From: mark.shif...@yale.edu
Subject: Re: debugging model classes tied to Tomcat datasources
To: users@tomcat.apache.org
Hi:
This is what I do for testing. I made a class for creating a jndi
directory and I create this in my main, then I can get a datasource from
the jndi directory just like I do it when running tomcat.
jndi.properties
java.naming.factory.initial=org.apache.naming.java.javaURLContextFactory
java.naming.factory.url.pkgs=org.apache.naming
java.naming.provider.url=java
public static void create_JNDI(){
//jndi.properties must be on the classpath to make the
initial context
//you can either add the environment manually vida infra
or have a jndi.properties file
/* Hashtable env = new Hashtable();
env.put(Context.INITIAL_CONTEXT_FACTORY,"org.apache.naming.java.javaURLContextFactory");
env.put(Context.URL_PKG_PREFIXES,"org.apache.naming");
env.put(Context.PROVIDER_URL,"java");
Context initial = new InitialContext(env);*/
try {
Context initial = new InitialContext();
Context javaCompEnv = initial.
createSubcontext(new
CompositeName().add("java:")).
createSubcontext("comp").
createSubcontext("env");
Context jdbc = javaCompEnv.createSubcontext("jdbc");
DataSource dataSource = setupDataSource();
jdbc.bind("mydatasourcet", dataSource);
} catch (NamingException e) {
throw new RuntimeException(e);
}
}
private static DataSource setupDataSource() {
// BasicDataSource is from DBCP commons or it is repackaged by tomcat as
//org.apache.tomcat.dbcp.dbcp.BasicDataSource
BasicDataSource ds = new BasicDataSource(); //this is from DBCP
commons
ds.setDriverClassName("yourdrivergoeshere");
ds.setUsername("user");
ds.setPassword("pwxxx");
ds.setUrl("yourjdbcurlgoeshere");
ds.setMaxActive(4);
ds.setMaxIdle(4);
return ds;
}
mas
Eric P wrote:
Hi,
(Tomcat newb alert)
I've got a simple database servlet application that has a few model
classes on the back end.
I have the model classes pretty well genericized so that they could
(almost) be utilized outside of Tomcat by another app, but they do
utilize the Tomcat data sources I've set up (via an InitialContext
data source lookup). So this makes it impossible (?) to execute the
model classes outside of Tomcat.
Does anyone have any suggestions about how they would approach this
problem so that they could debug and/or utilize these model classes
that rely on database access?
Thanks for reading. I'm open to any/all ideas.
Eric P.
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
---
RE: debugging model classes tied to Tomcat datasources
Mark
have you been able to implement JNDI (standalone) in TC?
i see craig's comment on implementing JNDI in org.apache.catalina.Container.java
* Resources - JNDI directory context enabling access to static
* resources, enabling custom linkages to existing server components when
* Catalina is embedded in a larger server.
*
i *thought* Catalina would need to be 'embedded' into A J2EE AppServer (such as
Glassfish)
to implement JNDI functionality?
thanks,
Martin Gainty
__
Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité
Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger
sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung
oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem
Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung.
Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung
fuer den Inhalt uebernehmen.
Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le
destinataire prévu, nous te demandons avec bonté que pour satisfaire informez
l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est
interdite. Ce message sert à l'information seulement et n'aura pas n'importe
quel effet légalement obligatoire. Étant donné que les email peuvent facilement
être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité
pour le contenu fourni.
> Date: Sun, 27 Sep 2009 12:38:11 -0400
> From: mark.shif...@yale.edu
> Subject: Re: debugging model classes tied to Tomcat datasources
> To: users@tomcat.apache.org
>
> Hi:
> This is what I do for testing. I made a class for creating a jndi
> directory and I create this in my main, then I can get a datasource from
> the jndi directory just like I do it when running tomcat.
>
> jndi.properties
> java.naming.factory.initial=org.apache.naming.java.javaURLContextFactory
> java.naming.factory.url.pkgs=org.apache.naming
> java.naming.provider.url=java
>
>
> public static void create_JNDI(){
> //jndi.properties must be on the classpath to make the
> initial context
> //you can either add the environment manually vida infra
> or have a jndi.properties file
> /* Hashtable env = new Hashtable();
>
> env.put(Context.INITIAL_CONTEXT_FACTORY,"org.apache.naming.java.javaURLContextFactory");
> env.put(Context.URL_PKG_PREFIXES,"org.apache.naming");
> env.put(Context.PROVIDER_URL,"java");
> Context initial = new InitialContext(env);*/
> try {
> Context initial = new InitialContext();
> Context javaCompEnv = initial.
> createSubcontext(new
> CompositeName().add("java:")).
> createSubcontext("comp").
> createSubcontext("env");
> Context jdbc = javaCompEnv.createSubcontext("jdbc");
>
> DataSource dataSource = setupDataSource();
> jdbc.bind("mydatasourcet", dataSource);
> } catch (NamingException e) {
> throw new RuntimeException(e);
> }
>
> }
>
> private static DataSource setupDataSource() {
> // BasicDataSource is from DBCP commons or it is repackaged by tomcat as
> //org.apache.tomcat.dbcp.dbcp.BasicDataSource
> BasicDataSource ds = new BasicDataSource(); //this is from DBCP
> commons
> ds.setDriverClassName("yourdrivergoeshere");
> ds.setUsername("user");
> ds.setPassword("pwxxx");
> ds.setUrl("yourjdbcurlgoeshere");
> ds.setMaxActive(4);
> ds.setMaxIdle(4);
> return ds;
> }
> mas
>
> Eric P wrote:
> > Hi,
> >
> > (Tomcat newb alert)
> >
> > I've got a simple database servlet application that has a few model
> > classes on the back end.
> >
> > I have the model classes pretty well genericized so that they could
> > (almost) be utilized outside of Tomcat by another app, but they do
> > utilize the Tomcat data sources I've set up (via an InitialContext
> > data source lookup). So this makes it impossible (?) to execute the
> > model classes outside of Tomcat.
> >
> > Does anyone have any suggestions about how they would approach this
> > problem so that they could debug and/or utilize these mo
Re: debugging model classes tied to Tomcat datasources
Hi:
This is what I do for testing. I made a class for creating a jndi
directory and I create this in my main, then I can get a datasource from
the jndi directory just like I do it when running tomcat.
jndi.properties
java.naming.factory.initial=org.apache.naming.java.javaURLContextFactory
java.naming.factory.url.pkgs=org.apache.naming
java.naming.provider.url=java
public static void create_JNDI(){
//jndi.properties must be on the classpath to make the
initial context
//you can either add the environment manually vida infra
or have a jndi.properties file
/* Hashtable env = new Hashtable();
env.put(Context.INITIAL_CONTEXT_FACTORY,"org.apache.naming.java.javaURLContextFactory");
env.put(Context.URL_PKG_PREFIXES,"org.apache.naming");
env.put(Context.PROVIDER_URL,"java");
Context initial = new InitialContext(env);*/
try {
Context initial = new InitialContext();
Context javaCompEnv = initial.
createSubcontext(new
CompositeName().add("java:")).
createSubcontext("comp").
createSubcontext("env");
Context jdbc = javaCompEnv.createSubcontext("jdbc");
DataSource dataSource = setupDataSource();
jdbc.bind("mydatasourcet", dataSource);
} catch (NamingException e) {
throw new RuntimeException(e);
}
}
private static DataSource setupDataSource() {
// BasicDataSource is from DBCP commons or it is repackaged by tomcat as
//org.apache.tomcat.dbcp.dbcp.BasicDataSource
BasicDataSource ds = new BasicDataSource(); //this is from DBCP
commons
ds.setDriverClassName("yourdrivergoeshere");
ds.setUsername("user");
ds.setPassword("pwxxx");
ds.setUrl("yourjdbcurlgoeshere");
ds.setMaxActive(4);
ds.setMaxIdle(4);
return ds;
}
mas
Eric P wrote:
Hi,
(Tomcat newb alert)
I've got a simple database servlet application that has a few model
classes on the back end.
I have the model classes pretty well genericized so that they could
(almost) be utilized outside of Tomcat by another app, but they do
utilize the Tomcat data sources I've set up (via an InitialContext
data source lookup). So this makes it impossible (?) to execute the
model classes outside of Tomcat.
Does anyone have any suggestions about how they would approach this
problem so that they could debug and/or utilize these model classes
that rely on database access?
Thanks for reading. I'm open to any/all ideas.
Eric P.
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: debugging model classes tied to Tomcat datasources
Eric P wrote: > Hi, > > (Tomcat newb alert) > > I've got a simple database servlet application that has a few model > classes on the back end. > > I have the model classes pretty well genericized so that they could > (almost) be utilized outside of Tomcat by another app, but they do > utilize the Tomcat data sources I've set up (via an InitialContext > data source lookup). So this makes it impossible (?) to execute the > model classes outside of Tomcat. > > Does anyone have any suggestions about how they would approach this > problem so that they could debug and/or utilize these model classes > that rely on database access? > > Thanks for reading. I'm open to any/all ideas. > Eric P. > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > I'll bet the only thing your code does with a JNDI string is perform the lookup and get a Datasource. You could implement multiple constructors allowing your code to be initialized w/ a JNDI string, DataSource object, or url/username/password. The code utilizing the model classes would simply create them using which ever constructor it has data for. --David - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: debugging model classes tied to Tomcat datasources
> From: Eric P [mailto:eric.maill...@gmail.com] > Subject: debugging model classes tied to Tomcat datasources > > they do utilize the Tomcat data sources I've set up (via > an InitialContext data source lookup). So this makes it > impossible (?) to execute the model classes outside of Tomcat. Tomcat merely populates the JNDI directory with information from the elements. Since JNDI is not unique to Tomcat (it's one of the Java standards), you can use it in any Java program. You might want to read more about the topic here: http://java.sun.com/products/jndi/ - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
debugging model classes tied to Tomcat datasources
Hi, (Tomcat newb alert) I've got a simple database servlet application that has a few model classes on the back end. I have the model classes pretty well genericized so that they could (almost) be utilized outside of Tomcat by another app, but they do utilize the Tomcat data sources I've set up (via an InitialContext data source lookup). So this makes it impossible (?) to execute the model classes outside of Tomcat. Does anyone have any suggestions about how they would approach this problem so that they could debug and/or utilize these model classes that rely on database access? Thanks for reading. I'm open to any/all ideas. Eric P. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
