On Thu, 8 Mar 2001 21:38:34 -0500, Tim Endres <[EMAIL PROTECTED]>
wrote:
>
>[...snip...]
>
>> 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.
>
>I disagree. The way to do this is to define a specific environment setting
>in your EJB deployment that is available via InitialContext.lookup(). That
>lookup will fail, regardless of other JNDI contexts, if you are not running
>within your EJB app server.
That's correct, but that would still rely on a user's actions in order
to work. The person deploying the beans that use the DB I/O classes
that call the ConnectionFactory would have to know what that
particular environment setting was and that it needed to be set. If
that didn't happen then the ConnectionFactory would attempt to use the
standard JDBC methods to acquire a connection. That would probably
(hopefully) fail because it would look for a properties file from
which to read the driver class name, database URL, etc., and, assuming
the container wasn't using a SecurityManager to block file I/O, the
properties file would probably not be present on the production
server. At any rate, if the ConnectionFactory has to rely on some user
action to work properly, I'd prefer that it only rely on the user's
actions for non-EJB (and non-mission-critical) applications. That's
why I think I'm going to have to stick with the -DNO_EJB command line
switch for now.
===========================================================================
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".
