> The way you ask that seems to imply that there's something inherently
wrong with such a requirement,
I asked because its best to write code that's oblivious to its outside
environment; if we can find a way so your class can work inside or outside
the container, so much better!
I do not recomment using DriverManager.getConnection() if you are using JDBC
2.0 or later. The proper way is to use DataSource. In an ejb container,
DataSource is nicely bound to JNDI by your container already, so the
question is how do you get the DataSource for outside a container.
Well, this depends on exactly what kind of JDBC driver your using from
outside the container; if it's 2.0 or later, it should provide its own
DataSource implementation. You should NOT have to implement your own
ConnectionPoolFactory. Using JDBC 2.0 or later, you should always use
DataSource.getConnection(), and always call Connection.close(); the
underlying implementation will handle connection pooling and transaction
pinning.
Gene
-----Original Message-----
From: A mailing list for Enterprise JavaBeans development
[mailto:[EMAIL PROTECTED]]On Behalf Of Dave Glasser
Sent: Thursday, March 08, 2001 5:57 PM
To: [EMAIL PROTECTED]
Subject: Re: Determining if code is running in EJB container
On Wed, 7 Mar 2001 23:57:45 -0800, Gene Chuang <[EMAIL PROTECTED]>
wrote:
>I think a better question to ask first is WHY do you need to know if a
class
>of yours is running in a container?
The way you ask that seems to imply that there's something inherently
wrong with such a requirement, so I'll explain. I have lots and lots
of database I/O code that does object-relational mapping. I need to
run this code in both EJB and non-EJB applications. To get a JDBC
Connection in an EJB container, I do a JNDI lookup on a DataSource,
which gives me the connection, and when I'm done with it, to place it
back in the container's connection pool, I call its close() method. If
I'm in a non-EJB application, I use the standard
DriverManager.getConnection() call to create a connection, a homemade
ConnectionPool class to pool it, and when I'm done with it, I place it
back in the pool rather than calling its close() method. Since I don't
want to have this code repeated throughout all of my DB I/O classes, I
hide the creation and pooling of connections inside a
ConnectionFactory class. This is the class that needs to determine
whether or not it's running inside an EJB container, so it knows how
to create the Connections. In my JDBC code, to get a Connection, I
call ConnectionFactory.getConnection() and when I'm done with it I
pass it back to the ConnectionFactory.releaseConnection(Connection)
method, without knowing or caring where it came from or what happens
when I'm done with it. The ConnectionFactory class serves its purpose
beautifully, and using a -DNO_EJB switch on the command line is no
particular burden, it's just that I was wondering if there was a way
my ConnectionFactory class could tell where it was running without
relying on that switch -- something like a standard system property
that would always be present in an EJB container but would not be
present outside of one. Something just a little more elegant and
transparent than the command line switch.
Some responders suggested trying a new InitialContext().lookup(), and
if it failed, the code could assume it was running outside of an EJB
container. This would probably work in most cases, but it wouldn't be
guaranteed to always work. There might just be a jndi.properties file
lurking in the classpath pointing to a live JNDI service. Others
suggested having a static boolean flag in the ConnectionFactory switch
itself, that would be set in a non-EJB application's main() method.
This would always work, and anyone coding the main() method would
certainly know that the process they were kicking off wouldn't ever be
running in an EJB container, but I'm looking for a runtime way to set
the flag, that wouldn't rely on the actions of users (like the
-DNO_EJB switch) or coders (like explicitly setting the flag in code.)
I'd like the ConnectionFactory to work like magic -- wherever it
happens to be running, it will work the way it's supposed to. I've
been spoiled by Java's fantastic abilities to discover information
about its runtime environment -- through things like the reflection
API -- but maybe this is one instance where I'll have to give it a
little help.
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
