>
> As DomainUpgrade is only a marker interface, and you *inject* the
> impl classes, how can any errors be reported back to the users, if
> postConstruct encounters any?
I'm not Jerome, but I think you can just log any errors the way you
would normally. If upgrade tool sees any Level.SEVERE messages in the
output it will alert the user and tell him/her to check the server
log. If there's something you want to try without committing you can
always send me a jar file or two to drop into my installation.
>
> For the EJB Timer Service, to upgrade the timer table, the
> underlining database must be up and running. While this is not a
> problem in default case (when embedded derby is used), if the setup
> was changed to use some other database, it might have been stopped,
> and it would be nice to tell the user that they need to execute
> themselves the alter statement from the fix xyz.sql.
For what it's worth, I've been maintaining that it's simply invalid to
bring the database down during an upgrade. That just doesn't sound
like real life, and as you point out the DB may need to be accessed
during an upgrade. I think it's great to handle this case gracefully,
but it's not something that really should happen in a normal
environment. Upgrading the app server should be orthogonal to any
database changes (unless your enterprise is running on the bundled
javadb!).
Cheers,
Bobby