William,
If the goal is to obtain read-only properties, what is the harm even if
there are multiple JVMs? The EJB 1.2 specification seems odd considering
your beans use base Java classes with all of their static fields.
Ron
> From: William Ferguson <[EMAIL PROTECTED]>
> Reply-To: A mailing list for Enterprise JavaBeans development
> <[EMAIL PROTECTED]>
> Date: Mon, 29 May 2000 10:58:18 +1000
> To: [EMAIL PROTECTED]
> Subject: Re: Configurable parameters in EJBs
>
> Nicolas,
>
> solution 1, sounds fine to me, but solution 2 appears to violate the
> first part of section 18.1.2 of the EJB 1.2 specificiation.
>
> -- An enterprise Bean must not read/write static fields.
>
> I suspect that solution 2 would only work if the container uses a single
> JVM to execute all the instances of the bean.
>
> William Ferguson
>
>
>> -----Original Message-----
>> From: A mailing list for Enterprise JavaBeans development
>> [mailto:[EMAIL PROTECTED]]On Behalf Of Nicholas Whitehead
>> Sent: Monday, 29 May 2000 0:27
>> To: [EMAIL PROTECTED]
>> Subject: Re: Configurable parameters in EJBs
>>
>>
>> Interesting question. We thought a lot about this and
>> we came up with a couple of solutions that allowed us
>> to easily change runtime parameters without invoking
>> file io in the EJB beans.
>>
>> In both solutions, the runtime rpoperties are in a
>> .properties file that is used to initialize the app
>> server at startup time. (In this case, it is WebLogic,
>> but I am sure it applies to mist others as well.
>>
>> 1. In your application server startrup, read the
>> runtime values from the properties files and place
>> them in the JNDI tree where they can be retrieved at
>> runtime in your beans.
>>
>> 2. We created a base class for all EJB Beans. The base
>> class has a static hashtable (and accessor methods)
>> which the app server startup class loads witht eh
>> values from the properties file.
>>
>>
>> In all honesty, we have not used #2 yet, because the
>> number and size of our runtime parameters have been
>> small enough that we felt comfortable putting them in
>> JNDI, but conceptualy, I feel comfortable with #2
>> which should work consistently except possibly in
>> clustered environments.
>>
>> //Nicholas
>>
>>
>>
>>
>>
>>
>>
>> --- Shiv Kumar <[EMAIL PROTECTED]> wrote:
>>> Hi all
>>>
>>> I have a couple of beans which talk to an external
>>> server (say, a directory
>>> server). The EJBs need to know the server's IP
>>> address and port in order to
>>> talk. They pick these values from the environment
>>> entries in ejb-jar.xml. I have
>>> the same values in both the EJB's deployment
>>> descriptors. Whenever I want to
>>> connect to another server running on a different
>>> machine, I should change the
>>> env entries in both the deployment descriptors. As a
>>> bean developer I know which
>>> beans need these values and I can change them.
>>>
>>> But when I deliver my product to the customer, he
>>> should be careful enough to
>>> change the env entries in all the EJBs to point to
>>> the right server. Otherwise
>>> the product will not run properly. Changing these
>>> entries is also a pain. First,
>>> he should unjar the ejb jar file. Change the entries
>>> in ejb-jar.xml file
>>> (without introducing any syntax errors), then jar it
>>> back and deploy it on the
>>> app server.
>>>
>>> It would be much easier if the customer can edit a
>>> plain text file (.properties
>>> file, for example) and all the EJBs pick the
>>> server's IP and port from this
>>> file. In this case the configurable values are
>>> available in one single place
>>> and there are less chances of making mistakes. Also,
>>> if more EJBs need these
>>> values I still dont have to change anything.
>>>
>>> Im sure people who have developed large EJB based
>>> system should have faced this
>>> problem. How did you tackle this?
>>>
>>> Thanks in advance.
>>> --
>>> shiv
>>> [EMAIL PROTECTED]
>>>
>>>
>>>
>>> __________________________________________________
>>> Do You Yahoo!?
>>> Talk to your friends online with Yahoo! Messenger.
>>> http://im.yahoo.com
>>>
>>>
>> ==============================================================
>> =============
>>> 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".
>>>
>>
>>
>> =====
>>
>>
>> __________________________________________________
>> Do You Yahoo!?
>> Kick off your party with Yahoo! Invites.
>> http://invites.yahoo.com/
>>
>> ==============================================================
>> =============
>> 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".
>
>
===========================================================================
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".
