I think that you would be pushing the specs by doing that! I think that
the access to the JNDI is there to let you connect to other resources (eg.
database) rather than home interfaces.
At 04:37 PM 10/11/00 -0400, you wrote:
>Could table 3, which says that jndi access to java:comp/env is available in
>ejbCreate, support the home interface lookup, but not it's use? I.e. the
>returned home interface could be saved and used later, but a hi.create()
>would not be valid in ejbCreate()?
>
>
>At 12:07 PM 10/11/00 -0600, you wrote:
>>At 01:20 PM 10/11/00 -0400, you wrote:
>> >Sorry for the newbie question...
>> >
>> >In the business methods in my stateless session beans I've always done what
>> >seems like the usual pattern - lookup and narrow entity bean home
>> >interfaces in the method that uses them. However, to save some time, I'd
>> >like to do these lookups in the SLSB's ejbCreate method and save them in
>> >instance variables.
>> >
>> >I've rtfm, along with RMH, and can't see a reason why this wouldn't work,
>> >both with Orion and portably. Have I missed something?
>>
>>Yes. Table 3 of EJB1.1 spec doesn't say that enterprise bean access is
>>available from the ejbCreate method of a stateless session bean. (Hence it
>>isn't.)
>
>> >Better yet, can these be put into a class field and only looked once,
>> >rather than every bean instance. For example
>> >
>> >private static BeanHome beanhome = null;
>> >...
>> >ejbCreate()
>> > {
>> > ...
>> > if(beanhome == null)
>> > {
>> > beanhome = (lookup/narrow beanhome... )
>> > }
>> > ...
>> > }
>> >
>>
>>I don't see why not, so long as you don't try to populate them from
>>ejbCreate. Why not use a getBeanHome() method which acts as a cache? ie
>>
>>private static BeanHome beanhome = null;
>>private BeanHome getBeanHome(){
>> if( beanhome==null ) .....set the variable
>> return beanhome;
>>}
>>
>>I believe that there could conceivably be more than one instance of this
>>static variable in a distributed application (multiple VM's) but
>>nevertheless I don't see a problem with this solution.
>
>Thanks!
>
>>Nick
>
>
>Kirk Yarina
>[EMAIL PROTECTED]
>
