To register a resource to JNDI at deployment time is vendor-specific.  Its a
same J2EE specs does not allow us to do this declaratively...  (perhaps
future spec?)

Hence your two choice is totally dependent on how dependent you are on your
current vendor!  If you are fully committed to your current app server, then
do some research on your open-source container regarding how you can
declaratively add resources to JNDI at deployment time.  If this is not
possible with your current vendor, or you value vendor-portability, then you
are stuck with the first option until J2EE specs change!

Gene Chuang
www.kiko.com

-----Original Message-----
From: Vincent Harcq
To: [EMAIL PROTECTED]
Sent: 7/17/01 11:25 PM
Subject: resource-ref and custom classes / DAO

Hi,
I want a bean (a bmp) to refer to a Class (a dao) that I want to be
specified at deployment time.  This dao implements a well known
interface(**).
For example I have a CustomerBMPBean that can refer to a
CustomerOracleDAO
or a CustomerSybaseDAO.
But I do not want to have only spec-compliant "resources" (JDBC,JCA,...
is
not enough for me)
Then I use this Class in my bean (for ejbLoad, ...).

Is it best practice to

 - have a env-entry String to a Class name on wich I will newInstance(),
...
Something like
        ejbs/customer/comp/env/dao/myonlydao=com.abc.CustomerDAO[String]
or

 - have a resource-ref of type (**) which is (container-specifically)
mapped
to a Container global JNDI name.  And deploy my Class(es) (dao's) into a
specific part of JNDI namespace of the container.
Something like
        global/dao/customerdao=com.abc.CustomerDAO[Class]
        ejbs/customer/comp/env/dao/myonlydao=customerdao

I would prefer the second solution as I will be able to control what I
put
in the global JNDI namespace, but I am not sure I go against what
resource-ref is specified.
I am also not sure how much control on container's global JNDI namespace
I
have on any ejb containers I can found on the market.  I am using the
more
OPEN one, don't ask which one it is, you already know ;)
Finally the second solution makes all assumption on the Class at
container
level and not at deployment level which is (I "feel" that - I am not
sure)
better for management.


Thanks for any advices.
Vincent.

========================================================================
===
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".

Reply via email to