Hi Jielin,
Please review the changes to the java2db processing required by issue
https://glassfish.dev.java.net/issues/show_bug.cgi?id=1038.
The problem: files left sometimes locked by a "normal" redeploy processing
on Windows. Ludo found out that Windows allow to override those files even
though they do not allow to remove them (usually those are 3rd party lib jars
and redeploy doesn't actually cause any changes to them).
The solution: split redeploy event processing for java2db into PRE_DEPLOY
and POST_DEPLOY, where tables are dropped in PRE_DEPLOY and created in
POST_DEPLOY. No changes to the event processing in the 1st deploy or undeploy
are expected.
Note, that PRE_DEPLOY event can be only fired on redeploy.
Also note, that for quite some time already our app server completely wipes
out previously deployed application in case of a failed redeploy, so it seems
logical to drop the tables also (what's good to have tables for an undeployed
application?).
And one more note - the corresponding code has changed its location and had
been split into a base class and 2 subclasses since you've last touched it to
add JPA processing.
These changes actually simplify our processing logic a bit as there is no
need to calculate drop vs. create step. It can be simplified even further,
but that would require to have too many 'if (create)' blocks.
I've tested so far with RosterAppJ2DB (ear and jar), and persistence example.
I'll test deploydir tomorrow as it was broken until today's fix by Jane.
Please let me know if you have any questions.
thanks,
-marina