Re: Bean Choices (code question)

2001-05-21 Thread Michael Stacey


>
>I have a lot of informational beans that hold static reference data (think
>ISO codes, State abbreviations, etc...) With these types of beans, I have
>the choice of instantiating a singleton object reference to the bean and
>accessing the methods through the object, or making all the methods "public
>static" so I can access them via BeanName.method(). For the former, the bean
>does all of it's initialization and database access in it's constructor and
>my JSP's have something like the following at the top:

Isn't this a prime candidate for application-level beans?  These are 
instantiated
when the servlet is started and reused, no?

-- Michael 





Re: Bean Choices (code question)

2001-05-18 Thread Jeff Kilbride

That's what I thought, too. I guess I'll have to leave my initialization
code inside the static blocks.

Right now, I'm only using these classes in one context, so the classloader
issues don't apply. (yet...)

Thanks Charlie and Bo!

--jeff

- Original Message -
From: "Cox, Charlie" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, May 18, 2001 11:21 AM
Subject: RE: Bean Choices (code question)


>
> >
> >-Original Message-
> >From: Bo Xu [mailto:[EMAIL PROTECTED]]
> >Sent: Friday, May 18, 2001 1:47 PM
> >To: [EMAIL PROTECTED]
> >Subject: Re: Bean Choices (code question)
> >
> >
> >Jeff Kilbride wrote:
> >
> >> Hi Charlie,
> >> [...]
> >> On the same subject, are class constructors called when static methods
> are
> >> accessed? Right now, in my "all static method" classes, I'm doing my
> >> initialization in static blocks. I'm wondering if I can move that
> >> initialization into the class constructor, but I'm not sure if/when the
> >> constructor is called when a static method is called.
> >>
> >> Any insight on this point, also, is greatly appreciated.
> >>
> >> Thanks,
> >> --jeff
> >> [...]
> >
> >Hi :-)  I did a test, I find:
> >- when I invoke a static method with "className.methodName(...)",
> >  constructor and non-static init-block will not be invoked
> >
>
> That's what I thought. The constructor is not invoked because there is no
> instance of the class. Basically, if it's not static, it won't/can't run
> until an instance is created. Therefore static methods can only call other
> static methods in the same class.
>
>
> > -  it doesn't metter that if this class is a "all static method style
> class"
> > or Not,i.e., this class can have all of the following:
> >% static init-block/non-static init-block
> >% static field/non-static(instance) filed
> >% static method/non-static method
> >
> >- only when this class is being loaded into the classloader,
> >  static init-block will be invoked(i.e., normally, static init-block
> >  only will be invoked One time), now we only have a Class object
> >  of my-class, we don't have the instance object of my-class.
> >
> >- I am not sure if the above is righ when Java Reflection is used to
> >  find/load this class(like a Servlet container does)
> >
> I think this is where the classloader(s) issue comes into account and that
> separate instances in different contexts would be considered different
> classes. There was a very good explaination of tomcat's classloading
> discussed in a previous thread :
> http://www.mail-archive.com/tomcat-user@jakarta.apache.org/msg13260.html
>
> >
> >
> >Bo
> >May.18, 2001
> >
>
> Charlie
>




RE: Bean Choices (code question)

2001-05-18 Thread Cox, Charlie
Title: RE: Bean Choices (code question)






>
>-Original Message-
>From: Bo Xu [mailto:[EMAIL PROTECTED]]
>Sent: Friday, May 18, 2001 1:47 PM
>To: [EMAIL PROTECTED]
>Subject: Re: Bean Choices (code question)
>
>
>Jeff Kilbride wrote:
>
>> Hi Charlie,
>> [...]
>> On the same subject, are class constructors called when static methods are
>> accessed? Right now, in my "all static method" classes, I'm doing my
>> initialization in static blocks. I'm wondering if I can move that
>> initialization into the class constructor, but I'm not sure if/when the
>> constructor is called when a static method is called.
>>
>> Any insight on this point, also, is greatly appreciated.
>>
>> Thanks,
>> --jeff
>> [...]
>
>Hi :-)  I did a test, I find:
>- when I invoke a static method with "className.methodName(...)",
>  constructor and non-static init-block will not be invoked
>


That's what I thought. The constructor is not invoked because there is no instance of the class. Basically, if it's not static, it won't/can't run until an instance is created. Therefore static methods can only call other static methods in the same class.


> -  it doesn't metter that if this class is a "all static method style class"
> or Not,    i.e., this class can have all of the following:
>    % static init-block/non-static init-block
>    % static field/non-static(instance) filed
>    % static method/non-static method
>
>- only when this class is being loaded into the classloader,
>  static init-block will be invoked(i.e., normally, static init-block
>  only will be invoked One time), now we only have a Class object
>  of my-class, we don't have the instance object of my-class.
>
>- I am not sure if the above is righ when Java Reflection is used to
>  find/load this class(like a Servlet container does)
>
I think this is where the classloader(s) issue comes into account and that separate instances in different contexts would be considered different classes. There was a very good explaination of tomcat's classloading discussed in a previous thread : 

http://www.mail-archive.com/tomcat-user@jakarta.apache.org/msg13260.html


>
>
>Bo
>May.18, 2001
>


Charlie





Re: Bean Choices (code question)

2001-05-18 Thread Bo Xu

Jeff Kilbride wrote:

> Hi Charlie,
> [...]
> On the same subject, are class constructors called when static methods are
> accessed? Right now, in my "all static method" classes, I'm doing my
> initialization in static blocks. I'm wondering if I can move that
> initialization into the class constructor, but I'm not sure if/when the
> constructor is called when a static method is called.
>
> Any insight on this point, also, is greatly appreciated.
>
> Thanks,
> --jeff
> [...]

Hi :-)  I did a test, I find:
- when I invoke a static method with "className.methodName(...)",
  constructor and non-static init-block will not be invoked

 -  it doesn't metter that if this class is a "all static method style class"
 or Not,i.e., this class can have all of the following:
% static init-block/non-static init-block
% static field/non-static(instance) filed
% static method/non-static method

- only when this class is being loaded into the classloader,
  static init-block will be invoked(i.e., normally, static init-block
  only will be invoked One time), now we only have a Class object
  of my-class, we don't have the instance object of my-class.

- I am not sure if the above is righ when Java Reflection is used to
  find/load this class(like a Servlet container does)



Bo
May.18, 2001





Re: Bean Choices (code question)

2001-05-18 Thread Jeff Kilbride

Hi Charlie,

Thanks for confirming this! I was under the impression that static methods
were loaded once and never unloaded, but I wasn't sure.

On the same subject, are class constructors called when static methods are
accessed? Right now, in my "all static method" classes, I'm doing my
initialization in static blocks. I'm wondering if I can move that
initialization into the class constructor, but I'm not sure if/when the
constructor is called when a static method is called.

Any insight on this point, also, is greatly appreciated.

Thanks,
--jeff

- Original Message -
From: "Cox, Charlie" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, May 18, 2001 4:28 AM
Subject: RE: Bean Choices (code question)


> there is no gc on static objects. static objects(methods,fields, or
classes)
> are created once on startup and there is only one instance of the method
or
> field ever created that all requestors to your class will use. But with
> Tomcat I do believe that if you have the same class in 2 different
contexts,
> that it will load two separate instances of your bean due to the different
> class loaders.
>
> This also means that if you are writing to the static fields on the
first(or
> any) call, make sure to synchronize the write, in case 2 calls occur at
the
> same time.
>
> Charlie
>
> -Original Message-
> From: Jeff Kilbride [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, May 17, 2001 8:56 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Bean Choices (code question)
>
>
> Yeah, I know, but it's tempting to write all the methods as "public
static".
> Then I don't have to create the object at all, but I don't know the
affects
> on garbage collection.
>
> --jeff
>
> - Original Message -
> From: "Ross Dyson" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Thursday, May 17, 2001 5:24 PM
> Subject: RE: Bean Choices (code question)
>
>
> > If you make the bean class have a private constructor and a static
> reference
> > to an instance of its own class, then there will always be a strong
> > reference from the class itself to the instance of the class.  (The
first
> > call to bean.getInstance() instantiates the private static member
variable
> > which is your singleton instance of your bean, the contructor does the
db
> > work etc.)
> >
> > Therefore, it won't get gc'd.
> >
> > That's the way I do my classes that do that kind of stuff, anyway.
> >
> > -Original Message-
> > From: Jeff Kilbride [mailto:[EMAIL PROTECTED]]
> > Sent: Friday, 18 May 2001 9:35 AM
> > To: [EMAIL PROTECTED]
> > Subject: Bean Choices (code question)
> >
> >
> > I'm sorry if this is a little off-topic, since it is more about java
code,
> > but I thought Tomcat users would be interested/knowledgeable about the
way
> > beans work.
> >
> > I have a lot of informational beans that hold static reference data
(think
> > ISO codes, State abbreviations, etc...) With these types of beans, I
have
> > the choice of instantiating a singleton object reference to the bean and
> > accessing the methods through the object, or making all the methods
> "public
> > static" so I can access them via BeanName.method(). For the former, the
> bean
> > does all of it's initialization and database access in it's constructor
> and
> > my JSP's have something like the following at the top:
> >
> > <%!
> > private static BeanName bean = BeanName.getInstance();
> > %>
> >
> > For the latter, the bean does all of it's initialization and database
> access
> > in a static block:
> >
> > static {
> > // bean initialization and DB access
> > }
> >
> > and my JSPs reference the static methods:
> >
> > <%= BeanName.method() %>
> >
> > My question concerns the way beans with all "public static" methods are
> > instantiated and garbage collected. Because these beans hold unchanging
> > reference info, I only want the data loaded from the database once the
> first
> > time the bean is referenced. For beans with all "public static" methods,
> > since there are no object references to them, when are they garbage
> > collected? Is it possible that the bean will be unloaded and the code in
> my
> > static block will be re-run when the bean is next referenced? Or do
these
> > all static objects somehow stick around forever? For the singleton, I
know
> > the object will last as long as the JSP is loaded, because there is a
> > definite object reference to the singleton. I'm a little unclear as to
> what
> > happens with a bean that has all "public static" methods, though.
> >
> > Can anyone shed some light on this?
> >
> > Thanks,
> > --jeff
> >
> >
>




RE: Bean Choices (code question)

2001-05-18 Thread Cox, Charlie
Title: RE: Bean Choices (code question)





there is no gc on static objects. static objects(methods,fields, or classes) are created once on startup and there is only one instance of the method or field ever created that all requestors to your class will use. But with Tomcat I do believe that if you have the same class in 2 different contexts, that it will load two separate instances of your bean due to the different class loaders.

This also means that if you are writing to the static fields on the first(or any) call, make sure to synchronize the write, in case 2 calls occur at the same time.

Charlie


-Original Message-
From: Jeff Kilbride [mailto:[EMAIL PROTECTED]]
Sent: Thursday, May 17, 2001 8:56 PM
To: [EMAIL PROTECTED]
Subject: Re: Bean Choices (code question)



Yeah, I know, but it's tempting to write all the methods as "public static".
Then I don't have to create the object at all, but I don't know the affects
on garbage collection.


--jeff


- Original Message -
From: "Ross Dyson" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, May 17, 2001 5:24 PM
Subject: RE: Bean Choices (code question)



> If you make the bean class have a private constructor and a static
reference
> to an instance of its own class, then there will always be a strong
> reference from the class itself to the instance of the class.  (The first
> call to bean.getInstance() instantiates the private static member variable
> which is your singleton instance of your bean, the contructor does the db
> work etc.)
>
> Therefore, it won't get gc'd.
>
> That's the way I do my classes that do that kind of stuff, anyway.
>
> -Original Message-
> From: Jeff Kilbride [mailto:[EMAIL PROTECTED]]
> Sent: Friday, 18 May 2001 9:35 AM
> To: [EMAIL PROTECTED]
> Subject: Bean Choices (code question)
>
>
> I'm sorry if this is a little off-topic, since it is more about java code,
> but I thought Tomcat users would be interested/knowledgeable about the way
> beans work.
>
> I have a lot of informational beans that hold static reference data (think
> ISO codes, State abbreviations, etc...) With these types of beans, I have
> the choice of instantiating a singleton object reference to the bean and
> accessing the methods through the object, or making all the methods
"public
> static" so I can access them via BeanName.method(). For the former, the
bean
> does all of it's initialization and database access in it's constructor
and
> my JSP's have something like the following at the top:
>
> <%!
> private static BeanName bean = BeanName.getInstance();
> %>
>
> For the latter, the bean does all of it's initialization and database
access
> in a static block:
>
> static {
> // bean initialization and DB access
> }
>
> and my JSPs reference the static methods:
>
> <%= BeanName.method() %>
>
> My question concerns the way beans with all "public static" methods are
> instantiated and garbage collected. Because these beans hold unchanging
> reference info, I only want the data loaded from the database once the
first
> time the bean is referenced. For beans with all "public static" methods,
> since there are no object references to them, when are they garbage
> collected? Is it possible that the bean will be unloaded and the code in
my
> static block will be re-run when the bean is next referenced? Or do these
> all static objects somehow stick around forever? For the singleton, I know
> the object will last as long as the JSP is loaded, because there is a
> definite object reference to the singleton. I'm a little unclear as to
what
> happens with a bean that has all "public static" methods, though.
>
> Can anyone shed some light on this?
>
> Thanks,
> --jeff
>
>





Re: Bean Choices (code question)

2001-05-17 Thread Jeff Kilbride

Yeah, I know, but it's tempting to write all the methods as "public static".
Then I don't have to create the object at all, but I don't know the affects
on garbage collection.

--jeff

- Original Message -
From: "Ross Dyson" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, May 17, 2001 5:24 PM
Subject: RE: Bean Choices (code question)


> If you make the bean class have a private constructor and a static
reference
> to an instance of its own class, then there will always be a strong
> reference from the class itself to the instance of the class.  (The first
> call to bean.getInstance() instantiates the private static member variable
> which is your singleton instance of your bean, the contructor does the db
> work etc.)
>
> Therefore, it won't get gc'd.
>
> That's the way I do my classes that do that kind of stuff, anyway.
>
> -Original Message-
> From: Jeff Kilbride [mailto:[EMAIL PROTECTED]]
> Sent: Friday, 18 May 2001 9:35 AM
> To: [EMAIL PROTECTED]
> Subject: Bean Choices (code question)
>
>
> I'm sorry if this is a little off-topic, since it is more about java code,
> but I thought Tomcat users would be interested/knowledgeable about the way
> beans work.
>
> I have a lot of informational beans that hold static reference data (think
> ISO codes, State abbreviations, etc...) With these types of beans, I have
> the choice of instantiating a singleton object reference to the bean and
> accessing the methods through the object, or making all the methods
"public
> static" so I can access them via BeanName.method(). For the former, the
bean
> does all of it's initialization and database access in it's constructor
and
> my JSP's have something like the following at the top:
>
> <%!
> private static BeanName bean = BeanName.getInstance();
> %>
>
> For the latter, the bean does all of it's initialization and database
access
> in a static block:
>
> static {
> // bean initialization and DB access
> }
>
> and my JSPs reference the static methods:
>
> <%= BeanName.method() %>
>
> My question concerns the way beans with all "public static" methods are
> instantiated and garbage collected. Because these beans hold unchanging
> reference info, I only want the data loaded from the database once the
first
> time the bean is referenced. For beans with all "public static" methods,
> since there are no object references to them, when are they garbage
> collected? Is it possible that the bean will be unloaded and the code in
my
> static block will be re-run when the bean is next referenced? Or do these
> all static objects somehow stick around forever? For the singleton, I know
> the object will last as long as the JSP is loaded, because there is a
> definite object reference to the singleton. I'm a little unclear as to
what
> happens with a bean that has all "public static" methods, though.
>
> Can anyone shed some light on this?
>
> Thanks,
> --jeff
>
>




RE: Bean Choices (code question)

2001-05-17 Thread Ross Dyson

If you make the bean class have a private constructor and a static reference
to an instance of its own class, then there will always be a strong
reference from the class itself to the instance of the class.  (The first
call to bean.getInstance() instantiates the private static member variable
which is your singleton instance of your bean, the contructor does the db
work etc.)

Therefore, it won't get gc'd.

That's the way I do my classes that do that kind of stuff, anyway.

-Original Message-
From: Jeff Kilbride [mailto:[EMAIL PROTECTED]]
Sent: Friday, 18 May 2001 9:35 AM
To: [EMAIL PROTECTED]
Subject: Bean Choices (code question)


I'm sorry if this is a little off-topic, since it is more about java code,
but I thought Tomcat users would be interested/knowledgeable about the way
beans work.

I have a lot of informational beans that hold static reference data (think
ISO codes, State abbreviations, etc...) With these types of beans, I have
the choice of instantiating a singleton object reference to the bean and
accessing the methods through the object, or making all the methods "public
static" so I can access them via BeanName.method(). For the former, the bean
does all of it's initialization and database access in it's constructor and
my JSP's have something like the following at the top:

<%!
private static BeanName bean = BeanName.getInstance();
%>

For the latter, the bean does all of it's initialization and database access
in a static block:

static {
// bean initialization and DB access
}

and my JSPs reference the static methods:

<%= BeanName.method() %>

My question concerns the way beans with all "public static" methods are
instantiated and garbage collected. Because these beans hold unchanging
reference info, I only want the data loaded from the database once the first
time the bean is referenced. For beans with all "public static" methods,
since there are no object references to them, when are they garbage
collected? Is it possible that the bean will be unloaded and the code in my
static block will be re-run when the bean is next referenced? Or do these
all static objects somehow stick around forever? For the singleton, I know
the object will last as long as the JSP is loaded, because there is a
definite object reference to the singleton. I'm a little unclear as to what
happens with a bean that has all "public static" methods, though.

Can anyone shed some light on this?

Thanks,
--jeff