variables
Hi, Is it safe to have member variables in stateless bean? I want to use the member variable in bean private methods after assigning its value in bean's method? === 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.
Re: variables
Instance fields of EJBs should only be used to hold objects that are request-independent. Technically I may work anyway, since only one thread at a time will have access to an EJB instance. /Johan 6 okt 2005 kl. 21.33 skrev SUBSCRIBE EJB-INTEREST anonymous: Hi, Is it safe to have member variables in stateless bean? I want to use the member variable in bean private methods after assigning its value in bean's method? == = 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.
Re: Static Variables in Session Beans
Fully agree with you Joe Sam. It's really a good thing that you added this point. --- Joe Sam Shirah [EMAIL PROTECTED] wrote: In addition to shailesh sinha's comments: From the EJB 2.0 spec, section 7.8 The term stateless signifies that an instance has no state for a specific client. However, the instance variables of the instance can contain the state across client-invoked method calls. Examples of such states include an open database connection and an object reference to an EJB object. Joe Sam Joe Sam Shirah -http://www.conceptgo.com conceptGO - Consulting/Development/Outsourcing Java Filter Forum: http://www.ibm.com/developerworks/java/ Just the JDBC FAQs: http://www.jguru.com/faq/JDBC Going International? http://www.jguru.com/faq/I18N Que Java400? http://www.jguru.com/faq/Java400 - Original Message - From: K. Charan Kumar [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, December 31, 2003 1:07 AM Subject: Re: Static Variables in Session Beans Shailesh, If you start using static variables in Stateless session beans, meaning to stateless session beans is lost... May be u can use in Stateful session beans...This is what I feel. -Cheers K.Charan Kumar - Original Message - From: shailesh sinha [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, December 31, 2003 11:32 AM Subject: Re: Static Variables in Session Beans Yes staic variable should be used in the Stateless session beans. EJB specs has only one limitation on the static variables that is it should be read only, by using final you are making it sure, So there is no any problem in that. --- sanjeev kasarabada [EMAIL PROTECTED] wrote: Can static final variables be used in Stateless Sesion Beans?? Is there any EJB limitation on that? Your thoughts on this are appreciated. Thanx, Sanjeev === 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. Yahoo! India Matrimony: Find your partner online. Go to http://yahoo.shaadi.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.
Re: Static Variables in Session Beans
Is there ever a need for static fields in a SLSB as long as the app server allows you to configure the size of the bean instance pool (which implies you could set it to 1)? Instance fields of such a SLSB would serve the same purpose as using static fields, wouldn't it? There would be several advantages: - Synchronization is done by app server - No doubts regarding spec compliance - No doubts regarding class loader impact on the actual number of cache instances. /Johan 2004-01-02 kl. 07.06 skrev Joe Sam Shirah: Hi Mark, Anytime you have to use stateful session beans, you have run out of options. I'm not sure how your opinion relates; the topic is stateless session beans. Joe Sam Joe Sam Shirah -http://www.conceptgo.com conceptGO -Consulting/Development/Outsourcing Java Filter Forum: http://www.ibm.com/developerworks/java/ Just the JDBC FAQs: http://www.jguru.com/faq/JDBC Going International?http://www.jguru.com/faq/I18N Que Java400? http://www.jguru.com/faq/Java400 - Original Message - From: Mark Galbreath [EMAIL PROTECTED] To: Joe Sam Shirah [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Wednesday, December 31, 2003 7:25 PM Subject: RE: Static Variables in Session Beans Anytime you have to use stateful session beans, you have run out of options. Mark -Original Message- From: A mailing list for Enterprise JavaBeans development [mailto:[EMAIL PROTECTED] Behalf Of Joe Sam Shirah Sent: Wednesday, December 31, 2003 3:59 PM To: [EMAIL PROTECTED] Subject: Re: Static Variables in Session Beans In addition to shailesh sinha's comments: From the EJB 2.0 spec, section 7.8 The term stateless signifies that an instance has no state for a specific client. However, the instance variables of the instance can contain the state across client-invoked method calls. Examples of such states include an open database connection and an object reference to an EJB object. Joe Sam Joe Sam Shirah -http://www.conceptgo.com conceptGO -Consulting/Development/Outsourcing Java Filter Forum: http://www.ibm.com/developerworks/java/ Just the JDBC FAQs: http://www.jguru.com/faq/JDBC Going International?http://www.jguru.com/faq/I18N Que Java400? http://www.jguru.com/faq/Java400 - Original Message - From: K. Charan Kumar [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, December 31, 2003 1:07 AM Subject: Re: Static Variables in Session Beans Shailesh, If you start using static variables in Stateless session beans, meaning to stateless session beans is lost... May be u can use in Stateful session beans...This is what I feel. -Cheers K.Charan Kumar - Original Message - From: shailesh sinha [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, December 31, 2003 11:32 AM Subject: Re: Static Variables in Session Beans Yes staic variable should be used in the Stateless session beans. EJB specs has only one limitation on the static variables that is it should be read only, by using final you are making it sure, So there is no any problem in that. --- sanjeev kasarabada [EMAIL PROTECTED] wrote: Can static final variables be used in Stateless Sesion Beans?? Is there any EJB limitation on that? Your thoughts on this are appreciated. Thanx, Sanjeev === 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.
Re: Static Variables in Session Beans
Hi Mark, Anytime you have to use stateful session beans, you have run out of options. I'm not sure how your opinion relates; the topic is stateless session beans. Joe Sam Joe Sam Shirah -http://www.conceptgo.com conceptGO -Consulting/Development/Outsourcing Java Filter Forum: http://www.ibm.com/developerworks/java/ Just the JDBC FAQs: http://www.jguru.com/faq/JDBC Going International?http://www.jguru.com/faq/I18N Que Java400? http://www.jguru.com/faq/Java400 - Original Message - From: Mark Galbreath [EMAIL PROTECTED] To: Joe Sam Shirah [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Wednesday, December 31, 2003 7:25 PM Subject: RE: Static Variables in Session Beans Anytime you have to use stateful session beans, you have run out of options. Mark -Original Message- From: A mailing list for Enterprise JavaBeans development [mailto:[EMAIL PROTECTED] Behalf Of Joe Sam Shirah Sent: Wednesday, December 31, 2003 3:59 PM To: [EMAIL PROTECTED] Subject: Re: Static Variables in Session Beans In addition to shailesh sinha's comments: From the EJB 2.0 spec, section 7.8 The term stateless signifies that an instance has no state for a specific client. However, the instance variables of the instance can contain the state across client-invoked method calls. Examples of such states include an open database connection and an object reference to an EJB object. Joe Sam Joe Sam Shirah -http://www.conceptgo.com conceptGO -Consulting/Development/Outsourcing Java Filter Forum: http://www.ibm.com/developerworks/java/ Just the JDBC FAQs: http://www.jguru.com/faq/JDBC Going International?http://www.jguru.com/faq/I18N Que Java400? http://www.jguru.com/faq/Java400 - Original Message - From: K. Charan Kumar [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, December 31, 2003 1:07 AM Subject: Re: Static Variables in Session Beans Shailesh, If you start using static variables in Stateless session beans, meaning to stateless session beans is lost... May be u can use in Stateful session beans...This is what I feel. -Cheers K.Charan Kumar - Original Message - From: shailesh sinha [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, December 31, 2003 11:32 AM Subject: Re: Static Variables in Session Beans Yes staic variable should be used in the Stateless session beans. EJB specs has only one limitation on the static variables that is it should be read only, by using final you are making it sure, So there is no any problem in that. --- sanjeev kasarabada [EMAIL PROTECTED] wrote: Can static final variables be used in Stateless Sesion Beans?? Is there any EJB limitation on that? Your thoughts on this are appreciated. Thanx, Sanjeev === 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.
Re: Static Variables in Session Beans
In addition to shailesh sinha's comments: From the EJB 2.0 spec, section 7.8 The term stateless signifies that an instance has no state for a specific client. However, the instance variables of the instance can contain the state across client-invoked method calls. Examples of such states include an open database connection and an object reference to an EJB object. Joe Sam Joe Sam Shirah -http://www.conceptgo.com conceptGO -Consulting/Development/Outsourcing Java Filter Forum: http://www.ibm.com/developerworks/java/ Just the JDBC FAQs: http://www.jguru.com/faq/JDBC Going International?http://www.jguru.com/faq/I18N Que Java400? http://www.jguru.com/faq/Java400 - Original Message - From: K. Charan Kumar [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, December 31, 2003 1:07 AM Subject: Re: Static Variables in Session Beans Shailesh, If you start using static variables in Stateless session beans, meaning to stateless session beans is lost... May be u can use in Stateful session beans...This is what I feel. -Cheers K.Charan Kumar - Original Message - From: shailesh sinha [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, December 31, 2003 11:32 AM Subject: Re: Static Variables in Session Beans Yes staic variable should be used in the Stateless session beans. EJB specs has only one limitation on the static variables that is it should be read only, by using final you are making it sure, So there is no any problem in that. --- sanjeev kasarabada [EMAIL PROTECTED] wrote: Can static final variables be used in Stateless Sesion Beans?? Is there any EJB limitation on that? Your thoughts on this are appreciated. Thanx, Sanjeev === 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.
Re: Static Variables in Session Beans
Anytime you have to use stateful session beans, you have run out of options. Mark -Original Message- From: A mailing list for Enterprise JavaBeans development [mailto:[EMAIL PROTECTED] Behalf Of Joe Sam Shirah Sent: Wednesday, December 31, 2003 3:59 PM To: [EMAIL PROTECTED] Subject: Re: Static Variables in Session Beans In addition to shailesh sinha's comments: From the EJB 2.0 spec, section 7.8 The term stateless signifies that an instance has no state for a specific client. However, the instance variables of the instance can contain the state across client-invoked method calls. Examples of such states include an open database connection and an object reference to an EJB object. Joe Sam Joe Sam Shirah -http://www.conceptgo.com conceptGO -Consulting/Development/Outsourcing Java Filter Forum: http://www.ibm.com/developerworks/java/ Just the JDBC FAQs: http://www.jguru.com/faq/JDBC Going International?http://www.jguru.com/faq/I18N Que Java400? http://www.jguru.com/faq/Java400 - Original Message - From: K. Charan Kumar [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, December 31, 2003 1:07 AM Subject: Re: Static Variables in Session Beans Shailesh, If you start using static variables in Stateless session beans, meaning to stateless session beans is lost... May be u can use in Stateful session beans...This is what I feel. -Cheers K.Charan Kumar - Original Message - From: shailesh sinha [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, December 31, 2003 11:32 AM Subject: Re: Static Variables in Session Beans Yes staic variable should be used in the Stateless session beans. EJB specs has only one limitation on the static variables that is it should be read only, by using final you are making it sure, So there is no any problem in that. --- sanjeev kasarabada [EMAIL PROTECTED] wrote: Can static final variables be used in Stateless Sesion Beans?? Is there any EJB limitation on that? Your thoughts on this are appreciated. Thanx, Sanjeev === 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.
Static Variables in Session Beans
Can static final variables be used in Stateless Sesion Beans?? Is there any EJB limitation on that? Your thoughts on this are appreciated. Thanx, Sanjeev __ Do you Yahoo!? Find out what made the Top Yahoo! Searches of 2003 http://search.yahoo.com/top2003 === 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.
Re: Static Variables in Session Beans
Yes staic variable should be used in the Stateless session beans. EJB specs has only one limitation on the static variables that is it should be read only, by using final you are making it sure, So there is no any problem in that. --- sanjeev kasarabada [EMAIL PROTECTED] wrote: Can static final variables be used in Stateless Sesion Beans?? Is there any EJB limitation on that? Your thoughts on this are appreciated. Thanx, Sanjeev __ Do you Yahoo!? Find out what made the Top Yahoo! Searches of 2003 http://search.yahoo.com/top2003 === 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. Yahoo! India Matrimony: Find your partner online. Go to http://yahoo.shaadi.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.
Re: Static Variables in Session Beans
Shailesh, If you start using static variables in Stateless session beans, meaning to stateless session beans is lost... May be u can use in Stateful session beans...This is what I feel. -Cheers K.Charan Kumar - Original Message - From: shailesh sinha [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, December 31, 2003 11:32 AM Subject: Re: Static Variables in Session Beans Yes staic variable should be used in the Stateless session beans. EJB specs has only one limitation on the static variables that is it should be read only, by using final you are making it sure, So there is no any problem in that. --- sanjeev kasarabada [EMAIL PROTECTED] wrote: Can static final variables be used in Stateless Sesion Beans?? Is there any EJB limitation on that? Your thoughts on this are appreciated. Thanx, Sanjeev __ Do you Yahoo!? Find out what made the Top Yahoo! Searches of 2003 http://search.yahoo.com/top2003 === 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. Yahoo! India Matrimony: Find your partner online. Go to http://yahoo.shaadi.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.
public member variables in Entity Bean class?
I want to know if we need to declare public member variables in Entity Bean class? What is the rationale behind it? How come it still works when I declare as private member variables? In terms of Java 2 design issues, does it make any difference between J2EE and J2SE? IF we really need to declare public member variables in Entity Bean class, then obviously there are some differences since we are taught to declare private member variables in Java class. Any other design issues differences between J2EE and J2SE? Please discuss... === 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.
Re: Environment Variables
What if I have an EJB that is delegating to some non-EJB class where the non-EJB class reads from a property file? Anthony Catalfano Information Technology Analyst Application Management Services 400 19th Street Moline, IL 61265-1337 phone: (309) 748-5201 fax:(309) 765-4128 -Original Message- From: John Harby [SMTP:[EMAIL PROTECTED]] Sent: Thursday, September 27, 2001 11:34 AM To: [EMAIL PROTECTED] Subject: Re: Environment Variables The danger of doing this sort of thing though is that although your container may allow you to do it today, it may (and probably should) not allow you to do it tommorow. Thus, you risk having to rewrite your code when your container vendor puts out a new release. From: Peter J. Braswell [EMAIL PROTECTED] Reply-To: Peter J. Braswell [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: Environment Variables Date: Thu, 27 Sep 2001 10:39:52 -0400 Steve, I usually use a property file to set runtime parameters and the loadAsResource method call to read the file. People will yell as soon as they read this post and point to not doing file i/o in ejbs as per the spec, but I've done it on numerous containers with no problem. I usually use a property factory to ensure the file is read and properties initialized only once... It works well, clean, simple, etc If you want code, let me know. I'll send it to you off line. cheers, peter -Original Message- From: A mailing list for Enterprise JavaBeans development [mailto:[EMAIL PROTECTED]]On Behalf Of Steve Brown Sent: Thursday, September 27, 2001 8:10 AM To: [EMAIL PROTECTED] Subject: Environment Variables Hi, I would like to set an environment variable for my EJB container that all EJBs can access. I can see how you set env-entry's for individual beans, but how do you set an environment variable that ALL server side components within the EJB container can read? We are using Weblogic 6.0. Thanks, Steve. = == 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. _ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp == = 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.
Re: Environment Variables
It is not literally the class that is doing the work, but more the context. I believe these restrictions would be enforced related more to the context, so if your helper class was loaded from the ejb jar file via the same classloader as the ejb then it would be under the same restrictions. Cheers -Original Message- From: Catalfano Anthony To: [EMAIL PROTECTED] Sent: 10/12/01 3:20 AM Subject: Re: Environment Variables What if I have an EJB that is delegating to some non-EJB class where the non-EJB class reads from a property file? Anthony Catalfano Information Technology Analyst Application Management Services 400 19th Street Moline, IL 61265-1337 phone: (309) 748-5201 fax:(309) 765-4128 -Original Message- From: John Harby [SMTP:[EMAIL PROTECTED]] Sent: Thursday, September 27, 2001 11:34 AM To: [EMAIL PROTECTED] Subject: Re: Environment Variables The danger of doing this sort of thing though is that although your container may allow you to do it today, it may (and probably should) not allow you to do it tommorow. Thus, you risk having to rewrite your code when your container vendor puts out a new release. From: Peter J. Braswell [EMAIL PROTECTED] Reply-To: Peter J. Braswell [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: Environment Variables Date: Thu, 27 Sep 2001 10:39:52 -0400 Steve, I usually use a property file to set runtime parameters and the loadAsResource method call to read the file. People will yell as soon as they read this post and point to not doing file i/o in ejbs as per the spec, but I've done it on numerous containers with no problem. I usually use a property factory to ensure the file is read and properties initialized only once... It works well, clean, simple, etc If you want code, let me know. I'll send it to you off line. cheers, peter -Original Message- From: A mailing list for Enterprise JavaBeans development [mailto:[EMAIL PROTECTED]]On Behalf Of Steve Brown Sent: Thursday, September 27, 2001 8:10 AM To: [EMAIL PROTECTED] Subject: Environment Variables Hi, I would like to set an environment variable for my EJB container that all EJBs can access. I can see how you set env-entry's for individual beans, but how do you set an environment variable that ALL server side components within the EJB container can read? We are using Weblogic 6.0. Thanks, Steve. === == == 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. _ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp == = 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.
Re: Environment Variables
SuperEnvironment is for you. It is an open source program from www.acelet.com --- Rajan [EMAIL PROTECTED] wrote: I have been doing the same thing using startup classes. Load the properties file in startup class and keep in memory. As almost every server supports startup classes so there will be no issues while porting. -Original Message- From: John Harby [mailto:[EMAIL PROTECTED]] Sent: Thursday, September 27, 2001 10:04 PM To: [EMAIL PROTECTED] Subject: Re: Environment Variables The danger of doing this sort of thing though is that although your container may allow you to do it today, it may (and probably should) not allow you to do it tommorow. Thus, you risk having to rewrite your code when your container vendor puts out a new release. From: Peter J. Braswell [EMAIL PROTECTED] Reply-To: Peter J. Braswell [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: Environment Variables Date: Thu, 27 Sep 2001 10:39:52 -0400 Steve, I usually use a property file to set runtime parameters and the loadAsResource method call to read the file. People will yell as soon as they read this post and point to not doing file i/o in ejbs as per the spec, but I've done it on numerous containers with no problem. I usually use a property factory to ensure the file is read and properties initialized only once... It works well, clean, simple, etc If you want code, let me know. I'll send it to you off line. cheers, peter -Original Message- From: A mailing list for Enterprise JavaBeans development [mailto:[EMAIL PROTECTED]]On Behalf Of Steve Brown Sent: Thursday, September 27, 2001 8:10 AM To: [EMAIL PROTECTED] Subject: Environment Variables Hi, I would like to set an environment variable for my EJB container that all EJBs can access. I can see how you set env-entry's for individual beans, but how do you set an environment variable that ALL server side components within the EJB container can read? We are using Weblogic 6.0. Thanks, Steve. === 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. _ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp === 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. __ Do You Yahoo!? NEW from Yahoo! GeoCities - quick and easy web site hosting, just $8.95/month. http://geocities.yahoo.com/ps/info1 === 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.
Re: Using classloader to load files from EJB jar (was: Environment Variables)
Not necessarily true--the container could always synthesize a
ClassLoaderInterceptor that provided whatever functionality the container
felt was necessary to maintain its services.
Ted Neward
{.NET||Java} Course Author Instructor
DevelopMentor (http://www.develop.com)
http://www.javageeks.com/tneward/index.html
-Original Message-
From: A mailing list for Enterprise JavaBeans development
[mailto:[EMAIL PROTECTED]]On Behalf Of John Harby
Sent: Friday, September 28, 2001 10:05 AM
To: [EMAIL PROTECTED]
Subject: Re: [EJB-INT] Using classloader to load files from EJB jar
(was: Environment Variables)
Not ok with the spec, section 24.1 states:
The enterprise bean must not attempt to create a class loader;
obtain the
current class loader;set the context class loader; set security manager;
create a new security manager; stop the JVM; or change the input, output,
and error streams.
These functions are reserved for the EJB Container. Allowing the
enterprise
bean to use these functions could compromise security and decrease the
Containers ability to properly manage the runtime environment.
I think the issue you'll find is that runtime security exceptions
can occur
when the loader is created/obtained. If the developer is doing
this sort of
thing then the container cannot intercept these exceptions so the
container
is no longer in control of the application.
From: Johan Eltes [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Using classloader to load files from EJB jar (was: Environment
Variables)
Date: Fri, 28 Sep 2001 10:42:01 +0200
I should be ok to load files in the EJB Jar through the class loader,
shouldn't it?
Otherwise it would be hard to do localization and other tasks that are
supported by property-files and other representations of localized
resources?
My interpretation of the file io restriction stated in the spec, is that
you
shouldn't do file io by referencing the file system.
This has been on the agenda in many threads
/Johan
_
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp
==
=
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.
Re: Using classloader to load files from EJB jar (was: Environment Variables)
I don't see how you can facilitate this if an unchecked RuntimeException
occurs in the VM. (cf. VMSpec sec. 2.16.4)
From: Ted Neward [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Re: Using classloader to load files from EJB jar (was:
Environment Variables)
Date: Fri, 28 Sep 2001 10:38:24 -0700
Not necessarily true--the container could always synthesize a
ClassLoaderInterceptor that provided whatever functionality the container
felt was necessary to maintain its services.
Ted Neward
{.NET||Java} Course Author Instructor
DevelopMentor (http://www.develop.com)
http://www.javageeks.com/tneward/index.html
-Original Message-
From: A mailing list for Enterprise JavaBeans development
[mailto:[EMAIL PROTECTED]]On Behalf Of John Harby
Sent: Friday, September 28, 2001 10:05 AM
To: [EMAIL PROTECTED]
Subject: Re: [EJB-INT] Using classloader to load files from EJB jar
(was: Environment Variables)
Not ok with the spec, section 24.1 states:
The enterprise bean must not attempt to create a class loader;
obtain the
current class loader;set the context class loader; set security manager;
create a new security manager; stop the JVM; or change the input,
output,
and error streams.
These functions are reserved for the EJB Container. Allowing the
enterprise
bean to use these functions could compromise security and decrease the
Containers ability to properly manage the runtime environment.
I think the issue you'll find is that runtime security exceptions
can occur
when the loader is created/obtained. If the developer is doing
this sort of
thing then the container cannot intercept these exceptions so the
container
is no longer in control of the application.
From: Johan Eltes [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Using classloader to load files from EJB jar (was:
Environment
Variables)
Date: Fri, 28 Sep 2001 10:42:01 +0200
I should be ok to load files in the EJB Jar through the class loader,
shouldn't it?
Otherwise it would be hard to do localization and other tasks that are
supported by property-files and other representations of localized
resources?
My interpretation of the file io restriction stated in the spec, is
that
you
shouldn't do file io by referencing the file system.
This has been on the agenda in many threads
/Johan
_
Get your FREE download of MSN Explorer at
http://explorer.msn.com/intl.asp
==
=
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.
_
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp
===
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.
Re: Using classloader to load files from EJB jar (was: Environment Variables)
No, no, wrong idea. I'm suggesting that (a) if the EJB Spec or
implementation wished to provide access to resources within the Codebase of
the component (that is, files stored within the .ear file or from the local
filesystem), and (b) the deployment tool of the EJB vendor was written to do
this, the deployer could create a ClassLoader type that honored the request
to getResource() and getResourceAsStream() (while still rejecting
loadClass() calls), with the security permissions set to allow calls to
Thread.currentThread().getContextClassLoader() and/or
getClass().getClassLoader().
Bear in mind, too, that I just walked into the middle of this discussion, so
I'm not entirely sure of the context in which we're speaking. That stated, I
don't see the relevance of 2.16.4 to a discussion of obtaining and using the
component's ClassLoader. Certainly a SecurityException will be thrown if the
thread's current security context holds a CodeSource frame that lacks the
necessary RuntimePersmission to obtain the ClassLoader, but that's merely an
exercise in Java Security Policy permission manipulation, not an artifact of
the VM itself.
Ted Neward
{.NET||Java} Course Author Instructor
DevelopMentor (http://www.develop.com)
http://www.javageeks.com/tneward/index.html
-Original Message-
From: A mailing list for Enterprise JavaBeans development
[mailto:[EMAIL PROTECTED]]On Behalf Of John Harby
Sent: Friday, September 28, 2001 12:25 PM
To: [EMAIL PROTECTED]
Subject: Re: [EJB-INT] Using classloader to load files from EJB jar
(was: Environment Variables)
I don't see how you can facilitate this if an unchecked RuntimeException
occurs in the VM. (cf. VMSpec sec. 2.16.4)
From: Ted Neward [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Re: Using classloader to load files from EJB jar (was:
Environment Variables)
Date: Fri, 28 Sep 2001 10:38:24 -0700
Not necessarily true--the container could always synthesize a
ClassLoaderInterceptor that provided whatever functionality the container
felt was necessary to maintain its services.
Ted Neward
{.NET||Java} Course Author Instructor
DevelopMentor (http://www.develop.com)
http://www.javageeks.com/tneward/index.html
-Original Message-
From: A mailing list for Enterprise JavaBeans development
[mailto:[EMAIL PROTECTED]]On Behalf Of John Harby
Sent: Friday, September 28, 2001 10:05 AM
To: [EMAIL PROTECTED]
Subject: Re: [EJB-INT] Using classloader to load files from EJB jar
(was: Environment Variables)
Not ok with the spec, section 24.1 states:
The enterprise bean must not attempt to create a class loader;
obtain the
current class loader;set the context class loader; set
security manager;
create a new security manager; stop the JVM; or change the input,
output,
and error streams.
These functions are reserved for the EJB Container. Allowing the
enterprise
bean to use these functions could compromise security and decrease the
Containers ability to properly manage the runtime environment.
I think the issue you'll find is that runtime security exceptions
can occur
when the loader is created/obtained. If the developer is doing
this sort of
thing then the container cannot intercept these exceptions so the
container
is no longer in control of the application.
From: Johan Eltes [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Using classloader to load files from EJB jar (was:
Environment
Variables)
Date: Fri, 28 Sep 2001 10:42:01 +0200
I should be ok to load files in the EJB Jar through the class loader,
shouldn't it?
Otherwise it would be hard to do localization and other
tasks that are
supported by property-files and other representations of localized
resources?
My interpretation of the file io restriction stated in the spec, is
that
you
shouldn't do file io by referencing the file system.
This has been on the agenda in many threads
/Johan
_
Get your FREE download of MSN Explorer at
http://explorer.msn.com/intl.asp
==
=
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.
_
Get your FREE download of MSN Explorer at http://explorer.msn.com
Re: Using classloader to load files from EJB jar (was:Environment Variables)
Back to the original question though. It is perfectly legal to do objabc.getClass().getResource(xxx); which all that's need to read a property resource or for localization. Reading and writing files is not restricted per say. The use of java.io is restricted. However, it's perfectly possible to use a jdbc driver to other resource adapter to read and write files. There's been extensive discussion of this in the archives. --Victor John Harby wrote: Not ok with the spec, section 24.1 states: The enterprise bean must not attempt to create a class loader; obtain the current class loader;set the context class loader; set security manager; create a new security manager; stop the JVM; or change the input, output, and error streams. These functions are reserved for the EJB Container. Allowing the enterprise bean to use these functions could compromise security and decrease the Containers ability to properly manage the runtime environment. I think the issue you'll find is that runtime security exceptions can occur when the loader is created/obtained. If the developer is doing this sort of thing then the container cannot intercept these exceptions so the container is no longer in control of the application. From: Johan Eltes [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Using classloader to load files from EJB jar (was: Environment Variables) Date: Fri, 28 Sep 2001 10:42:01 +0200 I should be ok to load files in the EJB Jar through the class loader, shouldn't it? Otherwise it would be hard to do localization and other tasks that are supported by property-files and other representations of localized resources? My interpretation of the file io restriction stated in the spec, is that you shouldn't do file io by referencing the file system. This has been on the agenda in many threads /Johan - I've figured out the difference between scientific knowledge and business knowledge. Scientific knowledge depends on facts, logic, and the rigorous testing of ideas in the laboratory and the field. Business knowledge depends on the assertion of pet biases with great confidence and exorbitant billing rates. --Bob Lewis === 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.
Using classloader to load files from EJB jar (was: Environment Variables)
I should be ok to load files in the EJB Jar through the class loader, shouldn't it? Otherwise it would be hard to do localization and other tasks that are supported by property-files and other representations of localized resources? My interpretation of the file io restriction stated in the spec, is that you shouldn't do file io by referencing the file system. This has been on the agenda in many threads /Johan -Original Message- From: A mailing list for Enterprise JavaBeans development [mailto:[EMAIL PROTECTED]]On Behalf Of Rajan Sent: den 28 september 2001 06:47 To: [EMAIL PROTECTED] Subject: Re: Environment Variables I have been doing the same thing using startup classes. Load the properties file in startup class and keep in memory. As almost every server supports startup classes so there will be no issues while porting. -Original Message- From: John Harby [mailto:[EMAIL PROTECTED]] Sent: Thursday, September 27, 2001 10:04 PM To: [EMAIL PROTECTED] Subject: Re: Environment Variables The danger of doing this sort of thing though is that although your container may allow you to do it today, it may (and probably should) not allow you to do it tommorow. Thus, you risk having to rewrite your code when your container vendor puts out a new release. From: Peter J. Braswell [EMAIL PROTECTED] Reply-To: Peter J. Braswell [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: Environment Variables Date: Thu, 27 Sep 2001 10:39:52 -0400 Steve, I usually use a property file to set runtime parameters and the loadAsResource method call to read the file. People will yell as soon as they read this post and point to not doing file i/o in ejbs as per the spec, but I've done it on numerous containers with no problem. I usually use a property factory to ensure the file is read and properties initialized only once... It works well, clean, simple, etc If you want code, let me know. I'll send it to you off line. cheers, peter -Original Message- From: A mailing list for Enterprise JavaBeans development [mailto:[EMAIL PROTECTED]]On Behalf Of Steve Brown Sent: Thursday, September 27, 2001 8:10 AM To: [EMAIL PROTECTED] Subject: Environment Variables Hi, I would like to set an environment variable for my EJB container that all EJBs can access. I can see how you set env-entry's for individual beans, but how do you set an environment variable that ALL server side components within the EJB container can read? We are using Weblogic 6.0. Thanks, Steve. === 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. _ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp === 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.
Re: Using classloader to load files from EJB jar (was: Environme nt Variables)
This is my interpretation also. I have a more general question: It seems environment entries are an alternative (the intended alternative?) to property files. When are environment entries the most appropriate way to specify parameters, and when are property files the most appropriate way? Off the top of my head: ** Environment entries might be more appropriate foe bean-specific parameters. ** Property files might be more appropriate for global parameters. (Are there scenarios where there is a legitimate need for global parameters??? Seems to violate the principle of encapsulation.) ** Property files might be necessary if you are using a legacy class library that uses property files. A possible downfall of property files/using the classloader is that the case where two independently developed beans each use a property file, and the two property files have the same name. The one that is loaded in each case depends on how classloading is implemented in the app server. (For example, in WebSphere 4.0, you can choose to have one classloader for each module, one classloader for each application, or one classloader for all applications. There would be no problem with the first option, but there could be problems with the second and third options.) Anyway, I am interested in finding out when others use environment entries versus property files. Laurel -Original Message- From: Johan Eltes [mailto:[EMAIL PROTECTED]] Sent: Friday, September 28, 2001 3:42 AM To: [EMAIL PROTECTED] Subject: Using classloader to load files from EJB jar (was: Environment Variables) I should be ok to load files in the EJB Jar through the class loader, shouldn't it? Otherwise it would be hard to do localization and other tasks that are supported by property-files and other representations of localized resources? My interpretation of the file io restriction stated in the spec, is that you shouldn't do file io by referencing the file system. This has been on the agenda in many threads /Johan -Original Message- From: A mailing list for Enterprise JavaBeans development [mailto:[EMAIL PROTECTED]]On Behalf Of Rajan Sent: den 28 september 2001 06:47 To: [EMAIL PROTECTED] Subject: Re: Environment Variables I have been doing the same thing using startup classes. Load the properties file in startup class and keep in memory. As almost every server supports startup classes so there will be no issues while porting. -Original Message- From: John Harby [mailto:[EMAIL PROTECTED]] Sent: Thursday, September 27, 2001 10:04 PM To: [EMAIL PROTECTED] Subject: Re: Environment Variables The danger of doing this sort of thing though is that although your container may allow you to do it today, it may (and probably should) not allow you to do it tommorow. Thus, you risk having to rewrite your code when your container vendor puts out a new release. From: Peter J. Braswell [EMAIL PROTECTED] Reply-To: Peter J. Braswell [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: Environment Variables Date: Thu, 27 Sep 2001 10:39:52 -0400 Steve, I usually use a property file to set runtime parameters and the loadAsResource method call to read the file. People will yell as soon as they read this post and point to not doing file i/o in ejbs as per the spec, but I've done it on numerous containers with no problem. I usually use a property factory to ensure the file is read and properties initialized only once... It works well, clean, simple, etc If you want code, let me know. I'll send it to you off line. cheers, peter -Original Message- From: A mailing list for Enterprise JavaBeans development [mailto:[EMAIL PROTECTED]]On Behalf Of Steve Brown Sent: Thursday, September 27, 2001 8:10 AM To: [EMAIL PROTECTED] Subject: Environment Variables Hi, I would like to set an environment variable for my EJB container that all EJBs can access. I can see how you set env-entry's for individual beans, but how do you set an environment variable that ALL server side components within the EJB container can read? We are using Weblogic 6.0. Thanks, Steve. === 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. _ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff EJB
Re: Using classloader to load files from EJB jar (was: Environment Variables)
Not ok with the spec, section 24.1 states: The enterprise bean must not attempt to create a class loader; obtain the current class loader;set the context class loader; set security manager; create a new security manager; stop the JVM; or change the input, output, and error streams. These functions are reserved for the EJB Container. Allowing the enterprise bean to use these functions could compromise security and decrease the Containers ability to properly manage the runtime environment. I think the issue you'll find is that runtime security exceptions can occur when the loader is created/obtained. If the developer is doing this sort of thing then the container cannot intercept these exceptions so the container is no longer in control of the application. From: Johan Eltes [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Using classloader to load files from EJB jar (was: Environment Variables) Date: Fri, 28 Sep 2001 10:42:01 +0200 I should be ok to load files in the EJB Jar through the class loader, shouldn't it? Otherwise it would be hard to do localization and other tasks that are supported by property-files and other representations of localized resources? My interpretation of the file io restriction stated in the spec, is that you shouldn't do file io by referencing the file system. This has been on the agenda in many threads /Johan _ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp === 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.
Environment Variables
Hi, I would like to set an environment variable for my EJB container that all EJBs can access. I can see how you set env-entry's for individual beans, but how do you set an environment variable that ALL server side components within the EJB container can read? We are using Weblogic 6.0. Thanks, Steve. === 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.
Re: Environment Variables
Steve, I usually use a property file to set runtime parameters and the loadAsResource method call to read the file. People will yell as soon as they read this post and point to not doing file i/o in ejbs as per the spec, but I've done it on numerous containers with no problem. I usually use a property factory to ensure the file is read and properties initialized only once... It works well, clean, simple, etc If you want code, let me know. I'll send it to you off line. cheers, peter -Original Message- From: A mailing list for Enterprise JavaBeans development [mailto:[EMAIL PROTECTED]]On Behalf Of Steve Brown Sent: Thursday, September 27, 2001 8:10 AM To: [EMAIL PROTECTED] Subject: Environment Variables Hi, I would like to set an environment variable for my EJB container that all EJBs can access. I can see how you set env-entry's for individual beans, but how do you set an environment variable that ALL server side components within the EJB container can read? We are using Weblogic 6.0. Thanks, Steve. === 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.
Re: Environment Variables
The danger of doing this sort of thing though is that although your container may allow you to do it today, it may (and probably should) not allow you to do it tommorow. Thus, you risk having to rewrite your code when your container vendor puts out a new release. From: Peter J. Braswell [EMAIL PROTECTED] Reply-To: Peter J. Braswell [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: Environment Variables Date: Thu, 27 Sep 2001 10:39:52 -0400 Steve, I usually use a property file to set runtime parameters and the loadAsResource method call to read the file. People will yell as soon as they read this post and point to not doing file i/o in ejbs as per the spec, but I've done it on numerous containers with no problem. I usually use a property factory to ensure the file is read and properties initialized only once... It works well, clean, simple, etc If you want code, let me know. I'll send it to you off line. cheers, peter -Original Message- From: A mailing list for Enterprise JavaBeans development [mailto:[EMAIL PROTECTED]]On Behalf Of Steve Brown Sent: Thursday, September 27, 2001 8:10 AM To: [EMAIL PROTECTED] Subject: Environment Variables Hi, I would like to set an environment variable for my EJB container that all EJBs can access. I can see how you set env-entry's for individual beans, but how do you set an environment variable that ALL server side components within the EJB container can read? We are using Weblogic 6.0. Thanks, Steve. === 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. _ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp === 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.
Re: Environment Variables
I have been doing the same thing using startup classes. Load the properties file in startup class and keep in memory. As almost every server supports startup classes so there will be no issues while porting. -Original Message- From: John Harby [mailto:[EMAIL PROTECTED]] Sent: Thursday, September 27, 2001 10:04 PM To: [EMAIL PROTECTED] Subject: Re: Environment Variables The danger of doing this sort of thing though is that although your container may allow you to do it today, it may (and probably should) not allow you to do it tommorow. Thus, you risk having to rewrite your code when your container vendor puts out a new release. From: Peter J. Braswell [EMAIL PROTECTED] Reply-To: Peter J. Braswell [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: Environment Variables Date: Thu, 27 Sep 2001 10:39:52 -0400 Steve, I usually use a property file to set runtime parameters and the loadAsResource method call to read the file. People will yell as soon as they read this post and point to not doing file i/o in ejbs as per the spec, but I've done it on numerous containers with no problem. I usually use a property factory to ensure the file is read and properties initialized only once... It works well, clean, simple, etc If you want code, let me know. I'll send it to you off line. cheers, peter -Original Message- From: A mailing list for Enterprise JavaBeans development [mailto:[EMAIL PROTECTED]]On Behalf Of Steve Brown Sent: Thursday, September 27, 2001 8:10 AM To: [EMAIL PROTECTED] Subject: Environment Variables Hi, I would like to set an environment variable for my EJB container that all EJBs can access. I can see how you set env-entry's for individual beans, but how do you set an environment variable that ALL server side components within the EJB container can read? We are using Weblogic 6.0. Thanks, Steve. === 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. _ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp === 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.
Initializing Instance Variables in Entity Beans
Hello, I would like to get an understanding what is the best practice with regard to initializing instance variables in the bean class of an BMP Entity bean. - ie. is it necessary before every ejbCreate() or ejbLoad() to initialize the variables and collections that contain dependant objects. The reason for the question is that with Weblogic, it seems as though that I can get away with out any initialization. On iPlanet, I find that I get dirty values and thus need to initialize the variable. If we do need to need initialize, then what is the best way to deal with dependant objects. Our thinking was that you could use the entity beans as way to cache the dependant objects. ie. Load them to start with, but then retrieved the object from the collection instead of going to the database each time. However, if you have to initialize them, then how can you get good performance with regard to the managing of dependant object. Thanks in advance. Tom _ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp === 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.
Re: Environment variables
HI, On the EJB tab page, right click on any EJB and see the Environment tab page that comes upyou can set the env variables thereI am referring to version 3.5 of Visual Age for Java.. Hope it helps Sumit - Original Message - From: Bas Eefting [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, May 08, 2001 2:36 PM Subject: Environment variables Hi, does anybody know whether or not it is possible to use environment variables in your EJB instead of Properties files. I'm especially interested in how to accomplish this in 'Visual Age for Java' en WebSphere Application Server. And please a little code example if available, that would be must usefull for us. thanks in advance, Bas Eefting *** This E-Mail Message is intended exclusively for the addressee. If the E-Mail was sent to you in error, please notify the sender immediately by replying to this E-mail. We would then request you to destroy the E-Mail and neither to use nor disclose the contents in any manner to third parties, as the message could contain confidential information which may be protected by the professional secrecy act. This footnote also confirms that this E-mail message has been swept for computer viruses. *** === 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.
Re: Client references and non-db variables in Entity Beans
Kirk: I don't think I understand what you mean. How is a situation in which users update the same records concurrently handled by an EJB server with built in persistance and support for distributed objects and distributed transactions. I am indeed looking to use an EJB server and I wrote a bunch of bean managed, entity beans. Thanks, Vladimir P.S. Could you please reply to [EMAIL PROTECTED] The software that I am using puts popd in the reply address and the mail won't be delivered. Original Message: - In applications of type "set," users or even programs may set the values of objects in the database concurrently; without a "real time" notification of the changes, what one user does may overwrite what another user has just saved, and the program may not be able to tell that something has been lost. Of course, even with such "real time" notifications, the client software needs to detect and handle situations in which someone else's changes get pushed to the user's terminal while the user is editing the modified field. What you are talking about is the classic problem of keeping seperate copies of the same thing. There are several ok solutions to the problem. The solution I have worked with is to build your own applications transaction framework that adds some sort of tag (integer) to the object when you check it out. If it's not the same when you try to commit it, you have a transactional conflict. Of course, this is assumming that you are using RDB (or similar technology) for persistance. If you use an EJB server with built in persistance and support for distributed objects and distributed transactions, you won't need these things. - This message has been posted from Mail2Web (http://www.mail2web.com/) Web Hosting for $9.95 per month! Visit: (http://www.yourhosting.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".
Re: Client references and non-db variables in Entity Beans
Kirk, Actually, even with EJB you still have to deal with optimistic concurrency the way you describe, unless you move to a long transaction model which we all know doesn't scale. -Chris. -Original Message- From: Kirk Pepperdine [SMTP:[EMAIL PROTECTED]] Sent: Thursday, November 25, 1999 5:33 PM To: [EMAIL PROTECTED] Subject: Re: Client references and non-db variables in Entity Beans In applications of type "set," users or even programs may set the values of objects in the database concurrently; without a "real time" notification of the changes, what one user does may overwrite what another user has just saved, and the program may not be able to tell that something has been lost. Of course, even with such "real time" notifications, the client software needs to detect and handle situations in which someone else's changes get pushed to the user's terminal while the user is editing the modified field. What you are talking about is the classic problem of keeping seperate copies of the same thing. There are several ok solutions to the problem. The solution I have worked with is to build your own applications transaction framework that adds some sort of tag (integer) to the object when you check it out. If it's not the same when you try to commit it, you have a transactional conflict. Of course, this is assumming that you are using RDB (or similar technology) for persistance. If you use an EJB server with built in persistance and support for distributed objects and distributed transactions, you won't need these things. == = 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".
Client references and non-db variables in Entity Beans
Hi, A couple of weeks ago I posted a question on the BEA EJB interest group and I got responses that point to a limitation in the EJB specs. As a result, I would like to post the same question in this group to see if indeed there are limitations, and if what I am looking for is achievable now or in the future using EJB. Last but not least, I would like people to take a fresh look at the issues and see if I have a valid point in my quest. Most real life applications are not of the "adjust" type as the classical banking application, in which I see the balance in my checking account on my computer terminal at home, type in the amount to transfer from checking to savings, and click the button to execute the operation. In case my wife has paid for a big purchase using her ATM card just after I downloaded the data but before I hit the transfer button, my transaction could be aborted with the appropriate error message and it really does not matter that I did not see the change "in real time." In applications of type "set," users or even programs may set the values of objects in the database concurrently; without a "real time" notification of the changes, what one user does may overwrite what another user has just saved, and the program may not be able to tell that something has been lost. Of course, even with such "real time" notifications, the client software needs to detect and handle situations in which someone else's changes get pushed to the user's terminal while the user is editing the modified field. In order to have "real time" notifications, the EB should store pointers (a set) to every client that is using the bean. Each time a bean is accessed by a client, the remote pointer is checked against the stored set and if the pointer does not exist already, it is added to the set. Since it is difficult to ask the client to specify when it no longer needs a bean, purging the set of no longer valid pointers could be done when a bean is pushing changes back to all clients. Then, the bean can detect that some clients are no longer active and remove the corresponding pointers from the set. This strategy assumes that there is at most one bean object active in the EJB server at any time. This should also be true of a "clustered" server. Were this condition not true, the set of pointers to clients would be distributed and any bean object would presumably store part of the set. Therefore, the first question would be: should the EJB spec mandate that there was a single entity bean instance in memory at any one time, even in a "clustered" environment? The second question relates to passivation. At any one time there are a limited number of bean instances in memory. When new instances are needed to satisfy the request of a client, some of the instances are passivated and the bean objects reused for other beans. Passivation involves saving the appropriate records to the database. However, in my case, the remote pointers cannot be saved to the database but must be somehow preserved. I could serialize and deserialize the objects myself upon passivation / activation, but it would be nice if the bean container did it for me. Particular non-db variables in the EJB could be recomputed upon activation, but definitely the set of clients accessing the beans cannot. The pointers must be saved and restored. Thus the second question is: could the EJB standard require the EJB container to serialize non-db variables upon passivation and de-serialize them upon activation? Vladimir === 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".
Re: Client references and non-db variables in Entity Beans
In applications of type "set," users or even programs may set the values of objects in the database concurrently; without a "real time" notification of the changes, what one user does may overwrite what another user has just saved, and the program may not be able to tell that something has been lost. Of course, even with such "real time" notifications, the client software needs to detect and handle situations in which someone else's changes get pushed to the user's terminal while the user is editing the modified field. What you are talking about is the classic problem of keeping seperate copies of the same thing. There are several ok solutions to the problem. The solution I have worked with is to build your own applications transaction framework that adds some sort of tag (integer) to the object when you check it out. If it's not the same when you try to commit it, you have a transactional conflict. Of course, this is assumming that you are using RDB (or similar technology) for persistance. If you use an EJB server with built in persistance and support for distributed objects and distributed transactions, you won't need these things. === 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".
Re: Static variables in EJBs?
Jim Rhyne wrote: Vlada, ... BTW, one of the issues brought up at the Inprise EJB Workshop was lack of support for singletons. There things are really necessary - some applications will just not work without them. I fully agree here ... Vlada wrote Many EJB servers cannot support singleton objects. For example, some servers require that there is a separate JVM for each client context, either for security reasons, or simply this is how their runtime is implemented. We intentially didn't want to put anything into EJB that would require platform vendors to route calls from multiple clients to a single instance. ... and here not. I think the argument is particularly lame. At the end of the day you need to make to the application programmer happy and not the vendor (says the vendor :-) Cheers, Andreas -- "Programming with EJB, JTS and OTS" is now available. Collect all three! begin:vcard n:Vogel;Andreas tel;fax:+1 650 655 3950 tel;home:+1 415 643 8827 tel;work:+1 650 358 3037 x-mozilla-html:TRUE url:http://www.wiley.com/compbooks/vogel org:Inprise Corp. version:2.1 email;internet:[EMAIL PROTECTED] title:Strategic Technology Adviser adr;quoted-printable:;;951 Mariners' Island Blvd.=0D=0ASuite 120;San Mateo;CA;94404;USA x-mozilla-cpt:;-6336 fn:Andreas Vogel end:vcard
Static variables in EJBs?
Can you define static variables in an EJB?
Re: Static variables in EJBs?
Only if they are read-only constants. Vlada -Original Message-From: Damon Williams [EMAIL PROTECTED]To: [EMAIL PROTECTED] [EMAIL PROTECTED]Date: Wednesday, April 14, 1999 12:02 PMSubject: Static variables in EJBs? Can you define static variables in an EJB?
Re: Static variables in EJBs?
Static methods and static variables are basically class methods and class variables. Though the home class acts as a representative of the bean class for the client, there is no way of defining static methods on the home class since the home class is actually generated. Thus the client cannot access the class class methods/variables. You would have to define them on the bean class and use a session bean to access those class methods/variables However your other server side classes can access them directly I think EJB spec should require that the bean developer should be able to specify the bean's static mathods on the home interface andf the home class generated should delegate the behavior to the bean class. This will allow the clients to access static methods on the beans. This is my understanding of the static method situation on EJBs. Sachin. -Original Message-From: A mailing list for Enterprise JavaBeans development [mailto:[EMAIL PROTECTED]]On Behalf Of Damon WilliamsSent: Wednesday, April 14, 1999 12:03 PMTo: [EMAIL PROTECTED]Subject: Static variables in EJBs? Can you define static variables in an EJB?
Re: Static variables in EJBs?
Only if they're final. Otherwise, it's prohibited. === Tom Valesky -- [EMAIL PROTECTED] http://www.patriot.net/users/tvalesky -Original Message-From: Damon Williams [EMAIL PROTECTED]To: [EMAIL PROTECTED] [EMAIL PROTECTED]Date: Wednesday, April 14, 1999 3:12 PMSubject: Static variables in EJBs? Can you define static variables in an EJB?
Re: Static variables in EJBs?
I see this specified in 16.4. Do you know why this restriction is imposed ? Is it because there is a generated BeanImpl class and that raises the issue of duplicating all the static methods over there and gets complicated by the fact that in Java the instances can directly access static/class variables of their class and thus some methods would be accessing the copy on the bean class and others could be accessing the static methods/variables on the generated Impl class ? Is this restriction going to be removed in the next EJB spec ? -Original Message-From: A mailing list for Enterprise JavaBeans development [mailto:[EMAIL PROTECTED]]On Behalf Of Tom ValeskySent: Wednesday, April 14, 1999 4:11 PMTo: [EMAIL PROTECTED]Subject: Re: Static variables in EJBs? Only if they're final. Otherwise, it's prohibited. === Tom Valesky -- [EMAIL PROTECTED] http://www.patriot.net/users/tvalesky -Original Message-From: Damon Williams [EMAIL PROTECTED]To: [EMAIL PROTECTED] [EMAIL PROTECTED]Date: Wednesday, April 14, 1999 3:12 PMSubject: Static variables in EJBs? Can you define static variables in an EJB?
Re: Static variables in EJBs?
Static variables need to be read-only constants so that classes loaded by different class loaders see consistent values. Imre Kifor Valto Systems -Original Message- From: Sachin Aggarwal [EMAIL PROTECTED] To: [EMAIL PROTECTED] [EMAIL PROTECTED] Date: Wednesday, April 14, 1999 8:03 PM Subject: Re: Static variables in EJBs? I see this specified in 16.4. Do you know why this restriction is imposed ? Is it because there is a generated BeanImpl class and that raises the issue of duplicating all the static methods over there and gets complicated by the fact that in Java the instances can directly access static/class variables of their class and thus some methods would be accessing the copy on the bean class and others could be accessing the static methods/variables on the generated Impl class ? Is this restriction going to be removed in the next EJB spec ? -Original Message- From: A mailing list for Enterprise JavaBeans development [mailto:[EMAIL PROTECTED]]On Behalf Of Tom Valesky Sent: Wednesday, April 14, 1999 4:11 PM To: [EMAIL PROTECTED] Subject: Re: Static variables in EJBs? Only if they're final. Otherwise, it's prohibited. === Tom Valesky -- [EMAIL PROTECTED] http://www.patriot.net/users/tvalesky -Original Message- From: Damon Williams [EMAIL PROTECTED] To: [EMAIL PROTECTED] [EMAIL PROTECTED] Date: Wednesday, April 14, 1999 3:12 PM Subject: Static variables in EJBs? Can you define static variables in an EJB? === 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".
Re: Static variables in EJBs?
Would you have multiple class loaders only when you have multiple EJB servers or even when running a single EJB server ? I am approaching this from a bean developers point of view. It's a handicap to not be able to use class methods and class variables. Is there a legit work-around besides modelling the bean class as a seperate singleton class and defining the static methods/variables as instance methods/variables on that class ? -Original Message- From: A mailing list for Enterprise JavaBeans development [mailto:[EMAIL PROTECTED]]On Behalf Of Imre Kifor Sent: Wednesday, April 14, 1999 5:16 PM To: [EMAIL PROTECTED] Subject: Re: Static variables in EJBs? Static variables need to be read-only constants so that classes loaded by different class loaders see consistent values. Imre Kifor Valto Systems -Original Message- From: Sachin Aggarwal [EMAIL PROTECTED] To: [EMAIL PROTECTED] [EMAIL PROTECTED] Date: Wednesday, April 14, 1999 8:03 PM Subject: Re: Static variables in EJBs? I see this specified in 16.4. Do you know why this restriction is imposed ? Is it because there is a generated BeanImpl class and that raises the issue of duplicating all the static methods over there and gets complicated by the fact that in Java the instances can directly access static/class variables of their class and thus some methods would be accessing the copy on the bean class and others could be accessing the static methods/variables on the generated Impl class ? Is this restriction going to be removed in the next EJB spec ? -Original Message- From: A mailing list for Enterprise JavaBeans development [mailto:[EMAIL PROTECTED]]On Behalf Of Tom Valesky Sent: Wednesday, April 14, 1999 4:11 PM To: [EMAIL PROTECTED] Subject: Re: Static variables in EJBs? Only if they're final. Otherwise, it's prohibited. = == Tom Valesky -- [EMAIL PROTECTED] http://www.patriot.net/users/tvalesky -Original Message- From: Damon Williams [EMAIL PROTECTED] To: [EMAIL PROTECTED] [EMAIL PROTECTED] Date: Wednesday, April 14, 1999 3:12 PM Subject: Static variables in EJBs? Can you define static variables in an EJB? == = 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".
Re: FW: (TO SUN: please clarify) Re: ejbCreate( ) - initializeinstan ce variables
Hey Larry Allen wrote: Hmm. I've been thinking about this one for a while now, and I've come to a somewhat radically different conclusion: I'm not convinced that there's substantial benefit in pooling EJB bean instances. snip You forget that setEntityContext() is a potentially expensive operation. If the bean creates sockets to a legacy system or something similar those calls alone are reason to have pooling. /Rickard -- Rickard Öberg Computer Science student@LiTH @home: +46 13 177937 Email: [EMAIL PROTECTED] Homepage: http://www-und.ida.liu.se/~ricob684 === 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 SUN: please clarify) Re: ejbCreate( ) - initialize instance variables
I looked at spec and do not see any moment of time where server can
safely reset any field except continer managed fields.
a) Before setting a instance context, there no need to reset anything,
intance was just created.
b) Aftter setting a instance context and before unsetting, a bean
instance
has variables which contain refernces to resources like
javax.sql.DataSource,
and alike and possibly wrapped InstanceContext. So resetting any
field
can cause unpredicatable problems.
9.4.1
The instance can take advantage of the setEntityContext(ic) method
to allocate any resources that are to be held by the instance for
its lifetime. Such resources cannot be specific to an EJB object
identity since the instance might be reused during its lifetime
to serve multiple EJB objects.
c) Aftter unsetting a instance context, container should not use it.
9.4.2
The container invokes this method when the container wants
to reduce the number of instances in the pool. After this
method completes, the container is not allowed to reuse this
instance, and therefore it should drop any references to
the instance to allow the Java programming language garbage
collector to eventually invoke the finalize() method on the
instance.
So it is not safe to reset anything except container managed fields
during instance lifetime. So I think that Ejipt behaviour is
incorrect one because they reset all fileds.
I would like if Vlada of other author of EJB spec will clarify
the issue.
Constantine
Jim Frentress wrote:
to reduce object creation, this might be better:
class TestBean
{
List l = null;
void ejbCreate() {
init();
}
void ejbActivate()
{
init();
}
void init()
{
if (l == null)
l = new ArrayList();
l.clear();
}
void test(String a)
{
l.add(a);
}
}
-Original Message-
From: Imre Kifor [SMTP:[EMAIL PROTECTED]]
Sent: Wednesday, March 17, 1999 2:20 PM
To: [EMAIL PROTECTED]
Subject: Re: ejbCreate( ) - initialize instance variables
Sachin,
class TestBean
{
List l = null;
void ejbCreate()
{
}
void ejbActivate()
{
l = new ArrayList();
}
void test(String a)
{
l.add(a);
}
}
Imre,
don't we need to have " l = new ArrayList();" in the ejbCreate( ) also
as
ejbActivate is not called for every ejbCreate( ) ? In essence does the
bean
developer end up initializing in activate as well as create methods.
Of course, sorry about that. You have to do initialization in both
ejbActivate and ejbCreate methods (or ejbPostCreate in the case of entity
beans).
Imre
Thanks,
Sachin.
The example (combined with our mechanism) will guarantee that 1) your
deep
hierarchies are ready before your business methods hit 2) pooled
instances
don't use up resources by storing deep hierarchies associated with a
specific EJBObject 3) left over deep hierarchies are not accessible by
accident when a pooled instance is re-attached to a different
EJBObject and
4) and the whole thing is fast :-)
Imre Kifor
Valto Systems
Constantine
-Original Message-
From: Constantine Plotnikov [EMAIL PROTECTED]
To: [EMAIL PROTECTED] [EMAIL PROTECTED]
Date: Wednesday, March 17, 1999 8:50 AM
Subject: Re: ejbCreate( ) - initialize instance variables
Hi!
1. Do I understand it correctly? In your server, initial
values for all
fields are saved for each instance and they are restored
right before
creation.
2. If yes, how do you save values?
a) in serialized form
b) just pointers to values recived as Field.get()
c) other, please clarify what.
3. If no, could you please clarify semantics of restoring values
in your server.
Constantine
Imre Kifor wrote:
We believe that bean instances retrieved from the instance
pool should
always be in their initial state (i.e. the state right after
construction)
regardless of the used persistence management type.
This means that with Ejipt your 'country' member will be
predictably
set
to
"USA" upon entering ejbCreate, ejbFindXXX and ejbActivate.
Moreover,
since
Ejipt resets all instances before returning them to the
pool, you will
also
be assured that your possibly sensitive or very large member data
is
not
held by pooled instances.
Imre Kifor
Valto Systems
-Original Message-
From: Sachin Aggarwal [EMAIL PROTECTED]
To: [EMAIL PROTECTED] [EMAIL PROTECTED]
Date: Tuesday, March 16, 1999 11:26 PM
Subject: ejbCreate( ) - initialize instance variables
The spec mentions that ejbCreate( ) initializes instance
variables.
Re: (TO SUN: please clarify) Re: ejbCreate( ) - initialize instance variables
The only instance's fields that the container is allowed to manipulate are the
fields designated for container-managed persistence. All the other fields
are in the hands of the bean developer, and the container should not modify
them under the covers.
Vlada
-Original Message-
From: Imre Kifor [EMAIL PROTECTED]
To: [EMAIL PROTECTED] [EMAIL PROTECTED]
Date: Thursday, March 18, 1999 9:50 AM
Subject: Re: (TO SUN: please clarify) Re: ejbCreate( ) - initialize instance variables
Constantine,
So it is not safe to reset anything except container managed fields
during instance lifetime. So I think that Ejipt behaviour is
incorrect one because they reset all fileds.
I would like if Vlada of other author of EJB spec will clarify
the issue.
Constantine
The issue boils down to resource management. We view bean instances as
reusable resources and have applied the same resource management principles
to them as to all the other shared resources we manage in our servers.
Guaranteeing a consistent and predictable state for all pooled resources is
crucial for a robust and scalable server implementation. Resetting fields in
a generic fashion is not possible in JDK1.1. However, that restriction
should not be extended to the spec itself, especially now that Java 2 lifted
the restriction in a secure and highly controllable fashion.
Imre Kifor
Valto Systems
Jim Frentress wrote:
to reduce object creation, this might be better:
class TestBean
{
List l = null;
void ejbCreate() {
init();
}
void ejbActivate()
{
init();
}
void init()
{
if (l == null)
l = new ArrayList();
l.clear();
}
void test(String a)
{
l.add(a);
}
}
-Original Message-
From: Imre Kifor [SMTP:[EMAIL PROTECTED]]
Sent: Wednesday, March 17, 1999 2:20 PM
To: [EMAIL PROTECTED]
Subject: Re: ejbCreate( ) - initialize instance variables
Sachin,
class TestBean
{
List l = null;
void ejbCreate()
{
}
void ejbActivate()
{
l = new ArrayList();
}
void test(String a)
{
l.add(a);
}
}
Imre,
don't we need to have " l = new ArrayList();" in the ejbCreate( )
also
as
ejbActivate is not called for every ejbCreate( ) ? In essence does the
bean
developer end up initializing in activate as well as create methods.
Of course, sorry about that. You have to do initialization in both
ejbActivate and ejbCreate methods (or ejbPostCreate in the case of
entity
beans).
Imre
Thanks,
Sachin.
The example (combined with our mechanism) will guarantee that 1)
your
deep
hierarchies are ready before your business methods hit 2) pooled
instances
don't use up resources by storing deep hierarchies associated with a
specific EJBObject 3) left over deep hierarchies are not accessible
by
accident when a pooled instance is re-attached to a different
EJBObject and
4) and the whole thing is fast :-)
Imre Kifor
Valto Systems
Constantine
-Original Message-
From: Constantine Plotnikov [EMAIL PROTECTED]
To: [EMAIL PROTECTED] [EMAIL PROTECTED]
Date: Wednesday, March 17, 1999 8:50 AM
Subject: Re: ejbCreate( ) - initialize instance variables
Hi!
1. Do I understand it correctly? In your server, initial
values for all
fields are saved for each instance and they are restored
right before
creation.
2. If yes, how do you save values?
a) in serialized form
b) just pointers to values recived as Field.get()
c) other, please clarify what.
3. If no, could you please clarify semantics of restoring values
in your server.
Constantine
Imre Kifor wrote:
We believe that bean instances retrieved from the instance
pool should
always be in their initial state (i.e. the state right after
construction)
regardless of the used persistence management type.
This means that with Ejipt your 'country' member will be
predictably
set
to
"USA" upon entering ejbCreate, ejbFindXXX and ejbActivate.
Moreover,
since
Ejipt resets all instances before returning them to the
pool, you will
also
be assured that your possibly sensitive or very large member
data
is
not
held by pooled instances.
Imre Kifor
Valto Systems
-Original Message-
From: Sachin Aggarwal [EMAIL PROTECTED]
To: [EMAIL PROTECTED] [EMAIL PROTECTED]
Date: Tuesday, March 16, 1999 11:26 PM
Subject: ejbCreate( ) - initialize instance variables
The spec mentions that ejbCreate( ) initializes instance
variables.
Question 1. Who's reponsibility is that in CMP beans ? The
containers
or
the
bean developers?
If the ans
Re: (TO SUN: please clarify) Re: ejbCreate( ) - initialize instance variables
Point taken. We will update Ejipt accordingly.
Imre Kifor
Valto Systems
-Original Message-
From: Vlada Matena [EMAIL PROTECTED]
To: [EMAIL PROTECTED] [EMAIL PROTECTED]
Date: Thursday, March 18, 1999 1:34 PM
Subject: Re: (TO SUN: please clarify) Re: ejbCreate( ) - initialize instance
variables
The only instance's fields that the container is allowed to manipulate are
the
fields designated for container-managed persistence. All the other fields
are in the hands of the bean developer, and the container should not modify
them under the covers.
Vlada
-Original Message-
From: Imre Kifor [EMAIL PROTECTED]
To: [EMAIL PROTECTED] [EMAIL PROTECTED]
Date: Thursday, March 18, 1999 9:50 AM
Subject: Re: (TO SUN: please clarify) Re: ejbCreate( ) - initialize
instance variables
Constantine,
So it is not safe to reset anything except container managed fields
during instance lifetime. So I think that Ejipt behaviour is
incorrect one because they reset all fileds.
I would like if Vlada of other author of EJB spec will clarify
the issue.
Constantine
The issue boils down to resource management. We view bean instances as
reusable resources and have applied the same resource management
principles
to them as to all the other shared resources we manage in our servers.
Guaranteeing a consistent and predictable state for all pooled resources
is
crucial for a robust and scalable server implementation. Resetting fields
in
a generic fashion is not possible in JDK1.1. However, that restriction
should not be extended to the spec itself, especially now that Java 2
lifted
the restriction in a secure and highly controllable fashion.
Imre Kifor
Valto Systems
Jim Frentress wrote:
to reduce object creation, this might be better:
class TestBean
{
List l = null;
void ejbCreate() {
init();
}
void ejbActivate()
{
init();
}
void init()
{
if (l == null)
l = new ArrayList();
l.clear();
}
void test(String a)
{
l.add(a);
}
}
-Original Message-
From: Imre Kifor [SMTP:[EMAIL PROTECTED]]
Sent: Wednesday, March 17, 1999 2:20 PM
To: [EMAIL PROTECTED]
Subject: Re: ejbCreate( ) - initialize instance variables
Sachin,
class TestBean
{
List l = null;
void ejbCreate()
{
}
void ejbActivate()
{
l = new ArrayList();
}
void test(String a)
{
l.add(a);
}
}
Imre,
don't we need to have " l = new ArrayList();" in the ejbCreate( )
also
as
ejbActivate is not called for every ejbCreate( ) ? In essence does
the
bean
developer end up initializing in activate as well as create methods.
Of course, sorry about that. You have to do initialization in both
ejbActivate and ejbCreate methods (or ejbPostCreate in the case of
entity
beans).
Imre
Thanks,
Sachin.
The example (combined with our mechanism) will guarantee that 1)
your
deep
hierarchies are ready before your business methods hit 2) pooled
instances
don't use up resources by storing deep hierarchies associated with
a
specific EJBObject 3) left over deep hierarchies are not
accessible
by
accident when a pooled instance is re-attached to a different
EJBObject and
4) and the whole thing is fast :-)
Imre Kifor
Valto Systems
Constantine
-Original Message-
From: Constantine Plotnikov [EMAIL PROTECTED]
To: [EMAIL PROTECTED] [EMAIL PROTECTED]
Date: Wednesday, March 17, 1999 8:50 AM
Subject: Re: ejbCreate( ) - initialize instance variables
Hi!
1. Do I understand it correctly? In your server, initial
values for all
fields are saved for each instance and they are restored
right before
creation.
2. If yes, how do you save values?
a) in serialized form
b) just pointers to values recived as Field.get()
c) other, please clarify what.
3. If no, could you please clarify semantics of restoring
values
in your server.
Constantine
Imre Kifor wrote:
We believe that bean instances retrieved from the instance
pool should
always be in their initial state (i.e. the state right after
construction)
regardless of the used persistence management type.
This means that with Ejipt your 'country' member will be
predictably
set
to
"USA" upon entering ejbCreate, ejbFindXXX and ejbActivate.
Moreover,
since
Ejipt resets all instances before returning them to the
pool, you will
also
be assured that your possibly sensitive or very large member
data
is
not
held by pooled instances.
Imre Kifor
Valto Systems
-Original Message-
From: Sachin Aggarwal [EMAIL PROTECTED]
To: [EMAIL PROTECTED] [EMAIL PROTECTED]
Date: Tuesday,
Re: (TO SUN: please clarify) Re: ejbCreate( ) - initialize instance variables
Imre, I don't know if I would give up the fight yet. Earlier, you said: The issue boils down to resource management. We view bean instances as reusable resources and have applied the same resource management principles to them as to all the other shared resources we manage in our servers. Guaranteeing a consistent and predictable state for all pooled resources is crucial for a robust and scalable server implementation. IMHO, your approach is right, and the spec should change, perhaps adding a container hands off section to an XML deployment descriptor. The containers would, by default, reset fields that were not in this section, when a bean is cycled back to the free pool. OTOH, who really needs a robust, scalable system, anyway? :) === 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".
Re: FW: (TO SUN: please clarify) Re: ejbCreate( ) - initialize instan ce variables
Jim Frentress wrote: i wish i could get off the fence on this one. in my opinion, you're both right. Hmm. I've been thinking about this one for a while now, and I've come to a somewhat radically different conclusion: I'm not convinced that there's substantial benefit in pooling EJB bean instances. Consider the relative cost of getting an instance from the pool vs. new'ing up an instance from scratch. In CMP, for example, if there is no pool, the following sequence of events must happen when calling a business method on an Entity Bean: - newInstance() call to the bean class - new() of an EntityContext object - setEntityContext() on the instance - ejbActivate() call to the instance (N.B. it's not totally clear this is required, but the spec seems to indicate that it is) - read entity state from the database and load the container-managed fields - ejbLoad() call to the bean class - and now we're ready to call the business method Compared to the sequence of calls required for activating an instance from the pool: - look up a free instance in the pool - ejbActivate() call to the instance - read entity state from the database and load the container-managed fields - ejbLoad() call to the bean class - and now we're ready to call the business method So, what's saved by pooling? Two newInstances() and a setEntityContext(). The new() of the EntityContext object itself must be pretty cheap, as the EntityContext object can't contain any information that's specific to the bean instance; setEntityContext() is usually a cheap operation. The new() calls might be somewhat expensive, but this is something that's continually being improved in the Java VM's. Any expensive initialization of the bean instance's fields must be done in the ejbActivate() (since, as this thread has pointed out, the bean can't depend on the container to initialize its non-persistent fields). Finally, in most instances, all these costs will be dwarfed by the cost of reloading the instance's persistent state from the database anyway. And, pooling adds cost and complexity to an implementation. Every pool needs to be managed (how many objects or what size should the pool be? How does the LRU'ing work? How do objects get removed from the pool if a new version of the Entity Bean class is installed? etc.) The pool will probably have to be synchronized, possibly becoming a point for thread contention on a large MP system. The pool management in some sense is in conflict with the operation of the garbage collector, which works to make currently-unused objects available as free space for other (possibly non-EJB) uses; unused objects held in the Entity Bean pool use up memory (or address space) that could be used by these other uses. I'm not debating that there could be some special cases in which Entity Bean instance pooling is a net gain in performance. And, certainly for those cases (e.g. object-oriented databases) in which the implementation can avoid having to reload the persistent state from the database, caching of instances can be a big win. But, for most cases, I don't see the gain. -Larry Allen SilverStream Software === 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".
Re: FW: (TO SUN: please clarify) Re: ejbCreate( ) - initialize in stan ce variables
Great comment! Depending the type of garbage collection being used and the amount of activity on the system, your point may or may not be valid. Creating new objects requires that space be allocated in memory and may also require that work be done by the garbage collector (marking a reference alive for example). With each object creation, cycles are needed to allocate space and perform other activities. When a bean instance is destroyed, the time required to perform garbage collection is increased. This is compounded when bean instances have a large object graph. It's these costs that are offset by pooling. (That and the cost of resource allocation). For really big systems where thousands of beans are used concurrently, the cost of creating and garbage collecting all the bean instances needed, can become a real bottleneck to performance. Maintaining a small pool of bean instances that can service many clients can offset this bottleneck. It would be great to hear more on this from the vendors. I know that some use pooling while other do not Richard -Original Message- From: Larry Allen To: [EMAIL PROTECTED] Sent: 3/18/99 4:02 PM Subject: Re: FW: (TO SUN: please clarify) Re: ejbCreate( ) - initialize instan ce variables Jim Frentress wrote: i wish i could get off the fence on this one. in my opinion, you're both right. Hmm. I've been thinking about this one for a while now, and I've come to a somewhat radically different conclusion: I'm not convinced that there's substantial benefit in pooling EJB bean instances. Consider the relative cost of getting an instance from the pool vs. new'ing up an instance from scratch. In CMP, for example, if there is no pool, the following sequence of events must happen when calling a business method on an Entity Bean: - newInstance() call to the bean class - new() of an EntityContext object - setEntityContext() on the instance - ejbActivate() call to the instance (N.B. it's not totally clear this is required, but the spec seems to indicate that it is) - read entity state from the database and load the container-managed fields - ejbLoad() call to the bean class - and now we're ready to call the business method Compared to the sequence of calls required for activating an instance from the pool: - look up a free instance in the pool - ejbActivate() call to the instance - read entity state from the database and load the container-managed fields - ejbLoad() call to the bean class - and now we're ready to call the business method So, what's saved by pooling? Two newInstances() and a setEntityContext(). The new() of the EntityContext object itself must be pretty cheap, as the EntityContext object can't contain any information that's specific to the bean instance; setEntityContext() is usually a cheap operation. The new() calls might be somewhat expensive, but this is something that's continually being improved in the Java VM's. Any expensive initialization of the bean instance's fields must be done in the ejbActivate() (since, as this thread has pointed out, the bean can't depend on the container to initialize its non-persistent fields). Finally, in most instances, all these costs will be dwarfed by the cost of reloading the instance's persistent state from the database anyway. And, pooling adds cost and complexity to an implementation. Every pool needs to be managed (how many objects or what size should the pool be? How does the LRU'ing work? How do objects get removed from the pool if a new version of the Entity Bean class is installed? etc.) The pool will probably have to be synchronized, possibly becoming a point for thread contention on a large MP system. The pool management in some sense is in conflict with the operation of the garbage collector, which works to make currently-unused objects available as free space for other (possibly non-EJB) uses; unused objects held in the Entity Bean pool use up memory (or address space) that could be used by these other uses. I'm not debating that there could be some special cases in which Entity Bean instance pooling is a net gain in performance. And, certainly for those cases (e.g. object-oriented databases) in which the implementation can avoid having to reload the persistent state from the database, caching of instances can be a big win. But, for most cases, I don't see the gain. -Larry Allen SilverStream Software === 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
Re: FW: (TO SUN: please clarify) Re: ejbCreate( ) - initialize instan ce variables
David Rauschenbach wrote: So, what's saved by pooling? Two newInstances() and a setEntityContext(). Almost. Can I add a third? The load on the gc. Minimizing lots of new's is the name of the game in scalable Java server, right? If you don't know me, lots = billions/day! I love my job. I used to think so too. Now, I'm not so sure. Certainly this doesn't seem to have been a priority in the implementation of the base Java classes, or the networking support, or the database support. Look at the number of of objects allocated in the course of a remote method call (especially using CORBA), or in the course of a database SELECT using JDBC. These are allocations that a "normal" developer (one who doesn't own his or her own VM) can't avoid, meaning that there's little impetus for such a developer to be extra-careful to minimize the allocations he/she CAN avoid -- it just doesn't buy very much. I now tend to think that the solution will be in the form of better object allocation and garbage collection schemes -- generational GC's, thread-specific heaps where possible, and so on. If so, then special-purpose pools like the one suggested for Entity Beans will actually end up hurting things in the long run. -Larry Allen SilverStream Software === 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".
Re: FW: (TO SUN: please clarify) Re: ejbCreate( ) - initialize instan ce variables
Larry Allen wrote: Hmm. I've been thinking about this one for a while now, and I've come to a somewhat radically different conclusion: I'm not convinced that there's substantial benefit in pooling EJB bean instances. The pools in EJB are not only for reducing the number of memory allocations. The ability to limit/adjust resource usage in a server is the secret behind the server's scalability. The various instance pools in an EJB server allow you to fine tune/balance the overall server for a specific configuration of resources. It is again a question of resource management. Without pools (or their functional equivalents) we cannot talk about scalable servers. Imre Kifor Valto Systems Consider the relative cost of getting an instance from the pool vs. new'ing up an instance from scratch. In CMP, for example, if there is no pool, the following sequence of events must happen when calling a business method on an Entity Bean: - newInstance() call to the bean class - new() of an EntityContext object - setEntityContext() on the instance - ejbActivate() call to the instance (N.B. it's not totally clear this is required, but the spec seems to indicate that it is) - read entity state from the database and load the container-managed fields - ejbLoad() call to the bean class - and now we're ready to call the business method Compared to the sequence of calls required for activating an instance from the pool: - look up a free instance in the pool - ejbActivate() call to the instance - read entity state from the database and load the container-managed fields - ejbLoad() call to the bean class - and now we're ready to call the business method So, what's saved by pooling? Two newInstances() and a setEntityContext(). The new() of the EntityContext object itself must be pretty cheap, as the EntityContext object can't contain any information that's specific to the bean instance; setEntityContext() is usually a cheap operation. The new() calls might be somewhat expensive, but this is something that's continually being improved in the Java VM's. Any expensive initialization of the bean instance's fields must be done in the ejbActivate() (since, as this thread has pointed out, the bean can't depend on the container to initialize its non-persistent fields). Finally, in most instances, all these costs will be dwarfed by the cost of reloading the instance's persistent state from the database anyway. And, pooling adds cost and complexity to an implementation. Every pool needs to be managed (how many objects or what size should the pool be? How does the LRU'ing work? How do objects get removed from the pool if a new version of the Entity Bean class is installed? etc.) The pool will probably have to be synchronized, possibly becoming a point for thread contention on a large MP system. The pool management in some sense is in conflict with the operation of the garbage collector, which works to make currently-unused objects available as free space for other (possibly non-EJB) uses; unused objects held in the Entity Bean pool use up memory (or address space) that could be used by these other uses. I'm not debating that there could be some special cases in which Entity Bean instance pooling is a net gain in performance. And, certainly for those cases (e.g. object-oriented databases) in which the implementation can avoid having to reload the persistent state from the database, caching of instances can be a big win. But, for most cases, I don't see the gain. -Larry Allen SilverStream Software === 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".
Re: FW: (TO SUN: please clarify) Re: ejbCreate( ) - initialize in stan ce variables
-Original Message- From: Imre Kifor [mailto:[EMAIL PROTECTED]] Sent: Thursday, March 18, 1999 3:45 PM To: [EMAIL PROTECTED] Subject: Re: FW: (TO SUN: please clarify) Re: ejbCreate( ) - initialize instan ce variables The pools in EJB are not only for reducing the number of memory allocations. The ability to limit/adjust resource usage in a server is the secret behind the server's scalability. The various instance pools in an EJB server allow you to fine tune/balance the overall server for a specific configuration of resources. It is again a question of resource management. Without pools (or their functional equivalents) we cannot talk about scalable servers. Couldn't the same thing be achieved via reference-counting? If you want to have a maximum number of a certain EJB, just check to see if you've created that many. If you have, fail the creation of new ones (or wait until the number of EJBs falls below a certain threshold). When ejbRemove() is invoked (or maybe ejbPassivate()), reduce the reference count. Or am I missing something? -jon === 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".
Re: FW: (TO SUN: please clarify) Re: ejbCreate( ) - initialize in stan ce variables
-Original Message- From: Jonathan Bodner [EMAIL PROTECTED] To: [EMAIL PROTECTED] [EMAIL PROTECTED] Date: Thursday, March 18, 1999 7:00 PM Subject: Re: FW: (TO SUN: please clarify) Re: ejbCreate( ) - initialize in stan ce variables Without pools (or their functional equivalents) we cannot talk about scalable servers. Couldn't the same thing be achieved via reference-counting? If you want to have a maximum number of a certain EJB, just check to see if you've created that many. If you have, fail the creation of new ones (or wait until the number of EJBs falls below a certain threshold). When ejbRemove() is invoked (or maybe ejbPassivate()), reduce the reference count. That is what I meant by "functional equivalents". Besides, by the time you implement the reference counting/releasing/waiting logic, you have implemented pooling without the benefit of memory reuse :-) Imre === 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".
Re: ejbCreate( ) - initialize instance variables
We believe that bean instances retrieved from the instance pool should always be in their initial state (i.e. the state right after construction) regardless of the used persistence management type. This means that with Ejipt your 'country' member will be predictably set to "USA" upon entering ejbCreate, ejbFindXXX and ejbActivate. Moreover, since Ejipt resets all instances before returning them to the pool, you will also be assured that your possibly sensitive or very large member data is not held by pooled instances. Imre Kifor Valto Systems -Original Message- From: Sachin Aggarwal [EMAIL PROTECTED] To: [EMAIL PROTECTED] [EMAIL PROTECTED] Date: Tuesday, March 16, 1999 11:26 PM Subject: ejbCreate( ) - initialize instance variables The spec mentions that ejbCreate( ) initializes instance variables. Question 1. Who's reponsibility is that in CMP beans ? The containers or the bean developers? If the answer to above is Bean Developer, then: Q2. If the instance variable is declared as public String county = "USA"; and the bean developer does not reinitialize it in ejbCreate(), then does the container have the right to initialize it to unpredicatable values ? Thanks for your 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".
Re: ejbCreate( ) - initialize instance variables
Hey Imre Kifor wrote: We believe that bean instances retrieved from the instance pool should always be in their initial state (i.e. the state right after construction) regardless of the used persistence management type. This means that with Ejipt your 'country' member will be predictably set to "USA" upon entering ejbCreate, ejbFindXXX and ejbActivate. Moreover, since Ejipt resets all instances before returning them to the pool, you will also be assured that your possibly sensitive or very large member data is not held by pooled instances. That is great, but I don't think this is required by the spec so as a bean developer you cannot rely on this to be done :-( /Rickard -- Rickard Öberg Computer Science student@LiTH @home: +46 13 177937 Email: [EMAIL PROTECTED] Homepage: http://www-und.ida.liu.se/~ricob684 === 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".
Re: ejbCreate( ) - initialize instance variables
Rickard wrote: Hey Imre Kifor wrote: We believe that bean instances retrieved from the instance pool should always be in their initial state (i.e. the state right after construction) regardless of the used persistence management type. This means that with Ejipt your 'country' member will be predictably set to "USA" upon entering ejbCreate, ejbFindXXX and ejbActivate. Moreover, since Ejipt resets all instances before returning them to the pool, you will also be assured that your possibly sensitive or very large member data is not held by pooled instances. That is great, but I don't think this is required by the spec so as a bean developer you cannot rely on this to be done :-( Yes, it also means that the pooled instance can't hold onto pooled resources. It's a useful container behaviour certainly, but one that should be a deployment option rather than mandatory. Ian McCallion CICS Business Unit IBM Hursley [EMAIL PROTECTED] Tel: ++44-1962-818065 Fax: ++44-1962-818069 === 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".
Re: ejbCreate( ) - initialize instance variables
Very nice! If other vendors are implementing this type of logic, please let us (subscribers) know ... Imre Kifor wrote: We believe that bean instances retrieved from the instance pool should always be in their initial state (i.e. the state right after construction) regardless of the used persistence management type. This means that with Ejipt your 'country' member will be predictably set to "USA" upon entering ejbCreate, ejbFindXXX and ejbActivate. Moreover, since Ejipt resets all instances before returning them to the pool, you will also be assured that your possibly sensitive or very large member data is not held by pooled instances. Imre Kifor Valto Systems -Original Message- From: Sachin Aggarwal [EMAIL PROTECTED] To: [EMAIL PROTECTED] [EMAIL PROTECTED] Date: Tuesday, March 16, 1999 11:26 PM Subject: ejbCreate( ) - initialize instance variables The spec mentions that ejbCreate( ) initializes instance variables. Question 1. Who's reponsibility is that in CMP beans ? The containers or the bean developers? If the answer to above is Bean Developer, then: Q2. If the instance variable is declared as public String county = "USA"; and the bean developer does not reinitialize it in ejbCreate(), then does the container have the right to initialize it to unpredicatable values ? Thanks for your 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". -- Richard Monson-Haefel Senior Consultant BORN Information Services === 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".
Re: ejbCreate( ) - initialize instance variables
The spec states that all bean instances must be created using newInstance() on the bean's class. This means that there will be only one valid initial state per bean class in a running server (and is created through the bean's default public constructor). We keep one such "template" instance around for all deployed bean classes and before the server releases an instance back to the pool, we "wipe" the instance's state clean with the template using reflection. No serialization is required in the process and, since we operate on the Java 2 platform, we can reset private members as well. Imre Kifor Valto Systems -Original Message- From: Constantine Plotnikov [EMAIL PROTECTED] To: [EMAIL PROTECTED] [EMAIL PROTECTED] Date: Wednesday, March 17, 1999 8:50 AM Subject: Re: ejbCreate( ) - initialize instance variables Hi! 1. Do I understand it correctly? In your server, initial values for all fields are saved for each instance and they are restored right before creation. 2. If yes, how do you save values? a) in serialized form b) just pointers to values recived as Field.get() c) other, please clarify what. 3. If no, could you please clarify semantics of restoring values in your server. Constantine Imre Kifor wrote: We believe that bean instances retrieved from the instance pool should always be in their initial state (i.e. the state right after construction) regardless of the used persistence management type. This means that with Ejipt your 'country' member will be predictably set to "USA" upon entering ejbCreate, ejbFindXXX and ejbActivate. Moreover, since Ejipt resets all instances before returning them to the pool, you will also be assured that your possibly sensitive or very large member data is not held by pooled instances. Imre Kifor Valto Systems -Original Message- From: Sachin Aggarwal [EMAIL PROTECTED] To: [EMAIL PROTECTED] [EMAIL PROTECTED] Date: Tuesday, March 16, 1999 11:26 PM Subject: ejbCreate( ) - initialize instance variables The spec mentions that ejbCreate( ) initializes instance variables. Question 1. Who's reponsibility is that in CMP beans ? The containers or the bean developers? If the answer to above is Bean Developer, then: Q2. If the instance variable is declared as public String county = "USA"; and the bean developer does not reinitialize it in ejbCreate(), then does the container have the right to initialize it to unpredicatable values ? Thanks for your 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". === 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".
Re: ejbCreate( ) - initialize instance variables
Rickard, Use ejbActivate instead of the constructor to set the id. Also, I just answered Constantine about the same issue. Please refer to that answer for more details. Imre Kifor Valto Systems -Original Message- From: Rickard Öberg [EMAIL PROTECTED] To: [EMAIL PROTECTED] [EMAIL PROTECTED] Date: Wednesday, March 17, 1999 10:29 AM Subject: Re: ejbCreate( ) - initialize instance variables Hey Imre Kifor wrote: The spec states that all bean instances must be created using newInstance() on the bean's class. This means that there will be only one valid initial state per bean class in a running server (and is created through the bean's default public constructor). Although I agree that this is a great feature it won't be able to handle this: public int id = nextId(); ... since the value will change for each newInstance() call. The technique will work for simple default values, but if the value is computed somehow, as above, you're in trouble. Right? /Rickard -- Rickard Öberg Computer Science student@LiTH @home: +46 13 177937 Email: [EMAIL PROTECTED] Homepage: http://www-und.ida.liu.se/~ricob684 === 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".
Re: ejbCreate( ) - initialize instance variables
class TestBean
{
List l = null;
void ejbCreate()
{
}
void ejbActivate()
{
l = new ArrayList();
}
void test(String a)
{
l.add(a);
}
}
Imre,
don't we need to have " l = new ArrayList();" in the ejbCreate( ) also as
ejbActivate is not called for every ejbCreate( ) ? In essence does the bean
developer end up initializing in activate as well as create methods.
Thanks,
Sachin.
The example (combined with our mechanism) will guarantee that 1) your deep
hierarchies are ready before your business methods hit 2) pooled instances
don't use up resources by storing deep hierarchies associated with a
specific EJBObject 3) left over deep hierarchies are not accessible by
accident when a pooled instance is re-attached to a different
EJBObject and
4) and the whole thing is fast :-)
Imre Kifor
Valto Systems
Constantine
-Original Message-
From: Constantine Plotnikov [EMAIL PROTECTED]
To: [EMAIL PROTECTED] [EMAIL PROTECTED]
Date: Wednesday, March 17, 1999 8:50 AM
Subject: Re: ejbCreate( ) - initialize instance variables
Hi!
1. Do I understand it correctly? In your server, initial
values for all
fields are saved for each instance and they are restored
right before
creation.
2. If yes, how do you save values?
a) in serialized form
b) just pointers to values recived as Field.get()
c) other, please clarify what.
3. If no, could you please clarify semantics of restoring values
in your server.
Constantine
Imre Kifor wrote:
We believe that bean instances retrieved from the instance
pool should
always be in their initial state (i.e. the state right after
construction)
regardless of the used persistence management type.
This means that with Ejipt your 'country' member will be predictably
set
to
"USA" upon entering ejbCreate, ejbFindXXX and ejbActivate. Moreover,
since
Ejipt resets all instances before returning them to the
pool, you will
also
be assured that your possibly sensitive or very large member data is
not
held by pooled instances.
Imre Kifor
Valto Systems
-Original Message-
From: Sachin Aggarwal [EMAIL PROTECTED]
To: [EMAIL PROTECTED] [EMAIL PROTECTED]
Date: Tuesday, March 16, 1999 11:26 PM
Subject: ejbCreate( ) - initialize instance variables
The spec mentions that ejbCreate( ) initializes instance variables.
Question 1. Who's reponsibility is that in CMP beans ? The
containers
or
the
bean developers?
If the answer to above is Bean Developer, then:
Q2. If the instance variable is declared as public String county =
"USA";
and the bean developer does not reinitialize it in
ejbCreate(), then
does
the container have the right to initialize it to unpredicatable
values ?
Thanks for your 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".
=
==
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".
==
=
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 [EMAI
Re: ejbCreate( ) - initialize instance variables
Sachin,
class TestBean
{
List l = null;
void ejbCreate()
{
}
void ejbActivate()
{
l = new ArrayList();
}
void test(String a)
{
l.add(a);
}
}
Imre,
don't we need to have " l = new ArrayList();" in the ejbCreate( ) also as
ejbActivate is not called for every ejbCreate( ) ? In essence does the bean
developer end up initializing in activate as well as create methods.
Of course, sorry about that. You have to do initialization in both
ejbActivate and ejbCreate methods (or ejbPostCreate in the case of entity
beans).
Imre
Thanks,
Sachin.
The example (combined with our mechanism) will guarantee that 1) your
deep
hierarchies are ready before your business methods hit 2) pooled
instances
don't use up resources by storing deep hierarchies associated with a
specific EJBObject 3) left over deep hierarchies are not accessible by
accident when a pooled instance is re-attached to a different
EJBObject and
4) and the whole thing is fast :-)
Imre Kifor
Valto Systems
Constantine
-Original Message-
From: Constantine Plotnikov [EMAIL PROTECTED]
To: [EMAIL PROTECTED] [EMAIL PROTECTED]
Date: Wednesday, March 17, 1999 8:50 AM
Subject: Re: ejbCreate( ) - initialize instance variables
Hi!
1. Do I understand it correctly? In your server, initial
values for all
fields are saved for each instance and they are restored
right before
creation.
2. If yes, how do you save values?
a) in serialized form
b) just pointers to values recived as Field.get()
c) other, please clarify what.
3. If no, could you please clarify semantics of restoring values
in your server.
Constantine
Imre Kifor wrote:
We believe that bean instances retrieved from the instance
pool should
always be in their initial state (i.e. the state right after
construction)
regardless of the used persistence management type.
This means that with Ejipt your 'country' member will be
predictably
set
to
"USA" upon entering ejbCreate, ejbFindXXX and ejbActivate.
Moreover,
since
Ejipt resets all instances before returning them to the
pool, you will
also
be assured that your possibly sensitive or very large member data
is
not
held by pooled instances.
Imre Kifor
Valto Systems
-Original Message-
From: Sachin Aggarwal [EMAIL PROTECTED]
To: [EMAIL PROTECTED] [EMAIL PROTECTED]
Date: Tuesday, March 16, 1999 11:26 PM
Subject: ejbCreate( ) - initialize instance variables
The spec mentions that ejbCreate( ) initializes instance
variables.
Question 1. Who's reponsibility is that in CMP beans ? The
containers
or
the
bean developers?
If the answer to above is Bean Developer, then:
Q2. If the instance variable is declared as public String county =
"USA";
and the bean developer does not reinitialize it in
ejbCreate(), then
does
the container have the right to initialize it to unpredicatable
values ?
Thanks for your 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".
=
==
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".
==
=
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 in
Re: ejbCreate( ) - initialize instance variables
to reduce object creation, this might be better:
class TestBean
{
List l = null;
void ejbCreate() {
init();
}
void ejbActivate()
{
init();
}
void init()
{
if (l == null)
l = new ArrayList();
l.clear();
}
void test(String a)
{
l.add(a);
}
}
-Original Message-
From: Imre Kifor [SMTP:[EMAIL PROTECTED]]
Sent: Wednesday, March 17, 1999 2:20 PM
To: [EMAIL PROTECTED]
Subject: Re: ejbCreate( ) - initialize instance variables
Sachin,
class TestBean
{
List l = null;
void ejbCreate()
{
}
void ejbActivate()
{
l = new ArrayList();
}
void test(String a)
{
l.add(a);
}
}
Imre,
don't we need to have " l = new ArrayList();" in the ejbCreate( ) also
as
ejbActivate is not called for every ejbCreate( ) ? In essence does the
bean
developer end up initializing in activate as well as create methods.
Of course, sorry about that. You have to do initialization in both
ejbActivate and ejbCreate methods (or ejbPostCreate in the case of entity
beans).
Imre
Thanks,
Sachin.
The example (combined with our mechanism) will guarantee that 1) your
deep
hierarchies are ready before your business methods hit 2) pooled
instances
don't use up resources by storing deep hierarchies associated with a
specific EJBObject 3) left over deep hierarchies are not accessible by
accident when a pooled instance is re-attached to a different
EJBObject and
4) and the whole thing is fast :-)
Imre Kifor
Valto Systems
Constantine
-Original Message-
From: Constantine Plotnikov [EMAIL PROTECTED]
To: [EMAIL PROTECTED] [EMAIL PROTECTED]
Date: Wednesday, March 17, 1999 8:50 AM
Subject: Re: ejbCreate( ) - initialize instance variables
Hi!
1. Do I understand it correctly? In your server, initial
values for all
fields are saved for each instance and they are restored
right before
creation.
2. If yes, how do you save values?
a) in serialized form
b) just pointers to values recived as Field.get()
c) other, please clarify what.
3. If no, could you please clarify semantics of restoring values
in your server.
Constantine
Imre Kifor wrote:
We believe that bean instances retrieved from the instance
pool should
always be in their initial state (i.e. the state right after
construction)
regardless of the used persistence management type.
This means that with Ejipt your 'country' member will be
predictably
set
to
"USA" upon entering ejbCreate, ejbFindXXX and ejbActivate.
Moreover,
since
Ejipt resets all instances before returning them to the
pool, you will
also
be assured that your possibly sensitive or very large member data
is
not
held by pooled instances.
Imre Kifor
Valto Systems
-Original Message-
From: Sachin Aggarwal [EMAIL PROTECTED]
To: [EMAIL PROTECTED] [EMAIL PROTECTED]
Date: Tuesday, March 16, 1999 11:26 PM
Subject: ejbCreate( ) - initialize instance variables
The spec mentions that ejbCreate( ) initializes instance
variables.
Question 1. Who's reponsibility is that in CMP beans ? The
containers
or
the
bean developers?
If the answer to above is Bean Developer, then:
Q2. If the instance variable is declared as public String county
=
"USA";
and the bean developer does not reinitialize it in
ejbCreate(), then
does
the container have the right to initialize it to unpredicatable
values ?
Thanks for your 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".
=
==
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 "signof
