s******e
发帖数: 63 | 1 in one web application(resin server), I put string constants in one class
Constants, those string constants are like:
public final static String UPPER="...."
when other classes use this constants, just call Constants.UPPER etc.
but when I changed some string value, recompiled, even restarted resin server,
in the places where uses changed constants, it still uses old constants.
how could this happen? if changes was taken inside jsp, I could understant
there's some cache issue. do java classes als | g*****g
发帖数: 34805 | 2 Depends on server and setting, your classes may not have been updated.
Find the extracted location, delete it and redeploy.
server,
【在 s******e 的大作中提到】
: in one web application(resin server), I put string constants in one class
: Constants, those string constants are like:
: public final static String UPPER="...."
: when other classes use this constants, just call Constants.UPPER etc.
: but when I changed some string value, recompiled, even restarted resin server,
: in the places where uses changed constants, it still uses old constants.
: how could this happen? if changes was taken inside jsp, I could understant
: there's some cache issue. do java classes als
| t****5
发帖数: 20 | 3 other classes are not recompiled, they still 'remember' the old value.
you have to do a clean build. this is a very bad 'feature' of java.
server,
【在 s******e 的大作中提到】
: in one web application(resin server), I put string constants in one class
: Constants, those string constants are like:
: public final static String UPPER="...."
: when other classes use this constants, just call Constants.UPPER etc.
: but when I changed some string value, recompiled, even restarted resin server,
: in the places where uses changed constants, it still uses old constants.
: how could this happen? if changes was taken inside jsp, I could understant
: there's some cache issue. do java classes als
| s******e
发帖数: 63 | 4 if delete all classes, recompile, restart resin, it will work.
but I could not do all these in productions after deployed. normally
I only patch new Constants and couple of new classes to production.
【在 g*****g 的大作中提到】
: Depends on server and setting, your classes may not have been updated.
: Find the extracted location, delete it and redeploy.
:
: server,
| s******e
发帖数: 63 | 5 you meant other classes 'remember' old final constants during their
compilation
time? does this only happen to 'final static'? so if I use 'static', it should
solve the problem?
problem is that I could not always do clean build on production. we need
to keep it running always and only patch couple of classes from time to time
(for example, constants in Constant class may be changed)
【在 t****5 的大作中提到】
: other classes are not recompiled, they still 'remember' the old value.
: you have to do a clean build. this is a very bad 'feature' of java.
:
: server,
| t****5
发帖数: 20 | 6 what's the difference? compiling all classes taking too long?
any production update has to be a clean build -or you'll missing something.
similiar incidence can be: touch a name/signature of one method in one
class, but forgot to change those classes who call the method.
if you don't do a clean build, it will blow up on production.
【在 s******e 的大作中提到】
: if delete all classes, recompile, restart resin, it will work.
: but I could not do all these in productions after deployed. normally
: I only patch new Constants and couple of new classes to production.
| g*****g
发帖数: 34805 | 7 It's not a good idea to do it this way.
Why not keep the develop/test enviroment away from production one,
once you want to release a build, you clean everything on production env.
and redeploy.
【在 s******e 的大作中提到】
: if delete all classes, recompile, restart resin, it will work.
: but I could not do all these in productions after deployed. normally
: I only patch new Constants and couple of new classes to production.
| s******e
发帖数: 63 | 8 we don't have big release. we add new partners to web application from time
to time, and need to keep web application running always since it's money
machine:)
previously these constants are defined in each partner specific classes so
there's
no issue. These constants are web service url of those partners so I tries
to seperate them out to Constants class, and use another staging version
Constants class for devo/staging server so testing won't be posted to partner
web service in devo/staging.now
【在 g*****g 的大作中提到】
: It's not a good idea to do it this way.
: Why not keep the develop/test enviroment away from production one,
: once you want to release a build, you clean everything on production env.
: and redeploy.
| t****5
发帖数: 20 | 9 how you build has nothing to do with how much downtime on production.
should
【在 s******e 的大作中提到】
: you meant other classes 'remember' old final constants during their
: compilation
: time? does this only happen to 'final static'? so if I use 'static', it should
: solve the problem?
: problem is that I could not always do clean build on production. we need
: to keep it running always and only patch couple of classes from time to time
: (for example, constants in Constant class may be changed)
| g*****g
发帖数: 34805 | 10 There's no site which has to be up and running all the time,
shut it down at night and do your upgrade. It takes than 10 minutes
for moderate sites.
If it's really that hot, reproduce the server on another machine
and remap the domain name, it can be switched in a couple of seconds.
should
【在 s******e 的大作中提到】
: you meant other classes 'remember' old final constants during their
: compilation
: time? does this only happen to 'final static'? so if I use 'static', it should
: solve the problem?
: problem is that I could not always do clean build on production. we need
: to keep it running always and only patch couple of classes from time to time
: (for example, constants in Constant class may be changed)
| | | s******e
发帖数: 63 | 11 what do you mean? when I do clean build on production, it's still running?
【在 t****5 的大作中提到】
: how you build has nothing to do with how much downtime on production.
:
: should
| g*****g
发帖数: 34805 | 12 If your business runs this way, then your design is very flawed,
put them in database. Add an entry when you need it.
A new partner shouldn't be a constant in your class.
partner
【在 s******e 的大作中提到】
: we don't have big release. we add new partners to web application from time
: to time, and need to keep web application running always since it's money
: machine:)
: previously these constants are defined in each partner specific classes so
: there's
: no issue. These constants are web service url of those partners so I tries
: to seperate them out to Constants class, and use another staging version
: Constants class for devo/staging server so testing won't be posted to partner
: web service in devo/staging.now
| s******e
发帖数: 63 | 13 we only have one production server, and could not shut it down always since
we do paid search on google etc and we will lose money if someone clicked
during downtime:)
【在 g*****g 的大作中提到】
: There's no site which has to be up and running all the time,
: shut it down at night and do your upgrade. It takes than 10 minutes
: for moderate sites.
: If it's really that hot, reproduce the server on another machine
: and remap the domain name, it can be switched in a couple of seconds.
:
: should
| g*****g
发帖数: 34805 | 14 I've never seen a company who cannot afford a couple seconds downtime
and a spare server at the same time. Put it on a mediocre machine at night,
switch for a couple of minutes, then switch back, big deal?
I think not.
【在 s******e 的大作中提到】
: we only have one production server, and could not shut it down always since
: we do paid search on google etc and we will lose money if someone clicked
: during downtime:)
| s******e
发帖数: 63 | 15 normaly those web service urls don't change, so it does not make sense
to put them in database. if I do it this way, it will cost many testing
time also. I just need a quick, safe way to make the change.
thanks.
so even 'static' won't solve the problem? I could not test now, have to try
tomorrow?
【在 g*****g 的大作中提到】
: If your business runs this way, then your design is very flawed,
: put them in database. Add an entry when you need it.
: A new partner shouldn't be a constant in your class.
:
: partner
| t****5
发帖数: 20 | 16 build and deploy are normally seperated...
I think you can just remove 'final' and get over it.
next time remember that live data that changes on runtime
are absoutely NOT constant.
【在 s******e 的大作中提到】
: we only have one production server, and could not shut it down always since
: we do paid search on google etc and we will lose money if someone clicked
: during downtime:)
| s******e
发帖数: 63 | 17 not only we have no spare machine, but also I don't have that much time to
do all these things for small change(which may happen several times in one day
)
only I am responsible for the web application and I only have less than 50%
time spending on that.
【在 g*****g 的大作中提到】
: I've never seen a company who cannot afford a couple seconds downtime
: and a spare server at the same time. Put it on a mediocre machine at night,
: switch for a couple of minutes, then switch back, big deal?
: I think not.
| g*****g
发帖数: 34805 | 18 It would be very unwise to assume urls don't change, as you see,
you are adding entries frequently. Put it in database, or put it
in an external xml if you worry about performance. I don't see how
it costs you more testing time? Isn't a constant just a constant,
be it in class, in xml or in database?
【在 s******e 的大作中提到】
: normaly those web service urls don't change, so it does not make sense
: to put them in database. if I do it this way, it will cost many testing
: time also. I just need a quick, safe way to make the change.
: thanks.
: so even 'static' won't solve the problem? I could not test now, have to try
: tomorrow?
| s******e
发帖数: 63 | 19
if mess up session of current users or response too slow during compiling time
,
it could cost a couple of Ks. and we may have changes to patch for several
times/week, and we are small company:)
if I do patch carefully, I could avoid those problems:)
【在 t****5 的大作中提到】
: what's the difference? compiling all classes taking too long?
: any production update has to be a clean build -or you'll missing something.
: similiar incidence can be: touch a name/signature of one method in one
: class, but forgot to change those classes who call the method.
: if you don't do a clean build, it will blow up on production.
| s******e
发帖数: 63 | 20 if put in database/xml, I need to replace places of Constants.URL with
database/xml reading code/method, right? so need more time in implementing
and testing.
【在 g*****g 的大作中提到】
: It would be very unwise to assume urls don't change, as you see,
: you are adding entries frequently. Put it in database, or put it
: in an external xml if you worry about performance. I don't see how
: it costs you more testing time? Isn't a constant just a constant,
: be it in class, in xml or in database?
| | | g*****g
发帖数: 34805 | 21 You have to re-think about it, a web service url is part of business
data, and it has to be either in database or xml.
Do you think Amazon will add a constant in some of their classes every
time they have a new merchandise?
time
【在 s******e 的大作中提到】
: if put in database/xml, I need to replace places of Constants.URL with
: database/xml reading code/method, right? so need more time in implementing
: and testing.
| s******e
发帖数: 63 | 22
?then always no constants except something like 3.14159...:)
in your code, you are sure every constant will never be changed?
【在 t****5 的大作中提到】
: build and deploy are normally seperated...
: I think you can just remove 'final' and get over it.
: next time remember that live data that changes on runtime
: are absoutely NOT constant.
| g*****g
发帖数: 34805 | 23 Will save you time in the long run, when your design is flawed,
the maintenance will be ugly anyway.
【在 s******e 的大作中提到】
: if put in database/xml, I need to replace places of Constants.URL with
: database/xml reading code/method, right? so need more time in implementing
: and testing.
| s******e
发帖数: 63 | 24 that's because their mechandises are too many and changed too often.
【在 g*****g 的大作中提到】
: You have to re-think about it, a web service url is part of business
: data, and it has to be either in database or xml.
: Do you think Amazon will add a constant in some of their classes every
: time they have a new merchandise?
:
: time
| g*****g
发帖数: 34805 | 25 So you call a couple of times a day "not too often"? LOL.
Never hard code your business data. Be it small or big.
【在 s******e 的大作中提到】
: that's because their mechandises are too many and changed too often.
| s******e
发帖数: 63 | 26 don't see database/xml is easier to maintain in this case.
for database, you need to maintain different copy in production and staging;
for xml, you need to spend more time to check it's format or spelling.
for foreseeable future, total constants will be less than 30 and normally
only new constants to be added. I ask this question just in case one constant
would be changed...
【在 g*****g 的大作中提到】
: Will save you time in the long run, when your design is flawed,
: the maintenance will be ugly anyway.
| s******e
发帖数: 63 | 27 sorry, I thought you misunderstood.
"a couple of times a day" is not for changing/adding constants, but for
other changes. I said this to reply "always need to do a clean build" or
"shutdown server", not to reply constants problem.:)
【在 g*****g 的大作中提到】
: So you call a couple of times a day "not too often"? LOL.
: Never hard code your business data. Be it small or big.
| m******t
发帖数: 2416 | 28
It's actually a good 'optimization' of java - the language spec says that
a constant should always be inlined if its value can be determined at
compile-time. It's intended to mimic the macro in C/C++ and encourage
programmers to use constants rather than literal values.
It's a little counter-intuitive, I agree, nonetheless a reasonable price
to pay for the performance gain.
【在 t****5 的大作中提到】
: other classes are not recompiled, they still 'remember' the old value.
: you have to do a clean build. this is a very bad 'feature' of java.
:
: server,
| m******t
发帖数: 2416 | 29
constant
I have gone through the whole conversation so far and agree with
goodbug. IMHO, your architecture is flawed on two accounts:
1. service URL's are not constants. In fact, the whole point of
using URL's to denote service points is to support dynamic
configuration.
2. You probably never, ever, want to do a partial update to your
production application. If your application can be or must be updated
partially, divide it into smaller deployment units and always do clean
build of one whole un
【在 s******e 的大作中提到】
: don't see database/xml is easier to maintain in this case.
: for database, you need to maintain different copy in production and staging;
: for xml, you need to spend more time to check it's format or spelling.
: for foreseeable future, total constants will be less than 30 and normally
: only new constants to be added. I ask this question just in case one constant
: would be changed...
| t****5
发帖数: 20 | 30 K
'final' does help performance, especially in a multi-threaded environment.
'final' is a huge commitment a programmer makes, java trusts that
commitment and do optimizations based on the assured knowledge. that trust
can be betrayed in several ways by a careless programmer, aided by this
flaw we are talking about in javac+jvm. To understand how serious this
commitment is, imagine in JDK some final fields changed values in a new
release (the values have no real meaning, like SocketOptions.SO_xx
【在 m******t 的大作中提到】
:
: constant
: I have gone through the whole conversation so far and agree with
: goodbug. IMHO, your architecture is flawed on two accounts:
: 1. service URL's are not constants. In fact, the whole point of
: using URL's to denote service points is to support dynamic
: configuration.
: 2. You probably never, ever, want to do a partial update to your
: production application. If your application can be or must be updated
: partially, divide it into smaller deployment units and always do clean
| | | m******t
发帖数: 2416 | 31
[snip]
I completely agree with what you said here and below about "final",
but unless I misunderstood the OP, his problem is with constants, i.e.,
"static final", rather than just "final". I would say they are totally
different animals. 8-)
Section 13.4.8, JLS actually does dictate that "compiler-time constants",
i.e., static final variables be inlined, and even gives some explanation
as to the rationale behind this requirement.
【在 t****5 的大作中提到】
: K
:
: 'final' does help performance, especially in a multi-threaded environment.
: 'final' is a huge commitment a programmer makes, java trusts that
: commitment and do optimizations based on the assured knowledge. that trust
: can be betrayed in several ways by a careless programmer, aided by this
: flaw we are talking about in javac+jvm. To understand how serious this
: commitment is, imagine in JDK some final fields changed values in a new
: release (the values have no real meaning, like SocketOptions.SO_xx
| t****5
发帖数: 20 | 32
now that's cheating! the reason is related to bytecode format, as I said...
and again, it dosn't say a java impl *must* do that.
well this discussion has become moot:)
【在 m******t 的大作中提到】
:
: [snip]
: I completely agree with what you said here and below about "final",
: but unless I misunderstood the OP, his problem is with constants, i.e.,
: "static final", rather than just "final". I would say they are totally
: different animals. 8-)
: Section 13.4.8, JLS actually does dictate that "compiler-time constants",
: i.e., static final variables be inlined, and even gives some explanation
: as to the rationale behind this requirement.
|
|
