Thanks, Kathey. I still don't understand the scenario you're describing.
It seems to me that application A never saw the bug fix at all because
the shared code was always shadowed by the version which application B
needed. However, the following scenario could occur and might be akin to
the problem which is troubling you:
o Two applications, EmbeddedApp and ClientServerApp run in the same VM.
o EmbeddedApp contains derby.jar(rev 1)
o ClientServerApp contains derbyclient.jar(rev 3)
o classpath=EmbeddedApp;ClientServerApp
o ClientServerApp wants an important bug fix in shared code available in
Derby rev 4. However, after upgrading to derbyclient.jar(rev 4),
ClientServerApp still can't enjoy the bugfix because the improved shared
code is shadowd by the old, buggy version in EmbeddedApp. The only way
that ClientServerApp can enjoy this bugfix is if EmbeddedApp upgrades to
use derby.jar(rev 4).
It's worth pointing out that this problem already exists today:
o Two applications, ClientServerApp1 and ClientServerApp2 run in the
same VM.
o ClientServerApp1 contains derbyclient.jar(rev 1)
o ClientServerApp2 contains derbyclient.jar(rev 3)
o classpath=ClientServerApp1;ClientServerApp2
o ClientServerApp2 wants an important bug fix in shared code available
in Derby rev 4. However, after upgrading to derbyclient.jar(rev 4),
ClientServerApp2 still can't enjoy the bugfix because the improved code
is shadowd by the old, buggy version in ClientServerApp1. The only way
that ClientServerApp2 can enjoy this bugfix is if ClientServerApp1
upgrades to use derbyclient.jar(rev 4).
The authority which owns this VM and classpath has to coordinate the two
applications.
Our users are already exposed to this problem. I think that the benefits
of code sharing are significant enough that they warrant slightly
increasing this exposure.
Regards,
-Rick
Kathey Marsden wrote:
Rick Hillegas wrote:
Scenario 1 - Fixing a Bug
If I have it right the issue of "masking" comes up only when you have
a mixed version environment. Let's say the user is running with the
10.2 embedded driver and the 10.3 client driver. Hopefully the user
tells us "I'm using both 10.2 and 10.3." Then we would fix the bug in
both the 10.2 and 10.3 common code.
If for some reason the user doesn't tell us this, we may fix the bug
in the wrong version the first time, but after getting more info from
the customer it will be clear that the bugfix should be ported to the
other branch.
We could have a policy that a common bug fix should be ported to all
releases currently available and supported, but that seems like
overkill and against the policy of "scratch your own itch" -- a bug
should be fixed in the versions that matter to the user who has the
bug.
So I would argue when you do your test, you should make the fix in
both versions of the common code and you should see no problem.
Now *that* is user impact, developer impact and support impact. The
fact that the bug fix revision level will regress with mixed jars if the
new jar is not first, is an important product behaviour change to
mention. I don't fix a bug normally for a single end user. I fix a bug
for a product that is deployed (hopefully) to thousands of users. You
are saying I need to know the configuration of all of those sites and
deal with them one by one. It's impossible. And this is not 10.2 and
10.3 mixing that we are talking about. Installing some product with the
embedded driver at 10.2.1.1 might mask a client install at 10.2.1.19
and make something that is working just fine break in strange ways,
where as now the two are totally independent.
I have lost the track of this argument. I am confused by the phrase
"the bug fix revision level will regress with mixed jars". Can you
help me understand how behavior regresses, that is, becomes worse? I'm
only seeing two cases here:
o The bug fix is applied to the wrong Derby version (the second one in
the classpath), in which case it is a NOP. The experience for the
customer will be that the bug was not fixed. However, no new
regressions are introduced.
o The bug fix is applied to the correct Derby version (the first one
in the classpath). This fixes the bug for the customer. But what
behavior is made worse here?
A concrete example would help. Thanks.
This is the circumstance that Dan was talking about where jars are mixed
by circumstances. I quote Dan's July 13 (Wow)
JIRA-289 comment. Dan said ....
.
In case it's not clear, this is the type of situation I'm talking about.
Application A is a client server application and requires Derby client
10.2
Application B is a local embedded Derby application and requires Derby
engine 10.3
Now I want to run a client to A and B in the same JVM for some reason,
maybe portlets, maybe multiple applications
in the same app server, maybe application B requires access to
application A.
This would be supported with the current model, complete flexibility
because the code bases are separate.
So do we want to lose this flexibility, or support it with the shared
code model?
Now lets change the versions a bit and say our classpath is in this
order derby.jar;derbyclient.jar
Application A is at 10.2.1.2 - They just last week got a critical bug
fix in shared code and are happy to be running again.
Application B is at 10.1.2.1 - They are running fine too but
planning to upgrade next week.
next week rolls around and the user installs their CD from Application B
which contains 10.2.1.1 .
Application B is working great, but because the new derby.jar masks the
fix in derbyclient.jar, Application A is broken again.
I agree that jar mixing is an unfortunate reality, but it is a reality
and has to stay safe and legal at least for a period of time while work
is done to make it rare.
Kathey
