geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jarek Gawor (JIRA)" <>
Subject [jira] [Commented] (GERONIMODEVTOOLS-805) Restart bundle when Eclipse HCR fails
Date Thu, 11 Oct 2012 18:21:03 GMT


Jarek Gawor commented on GERONIMODEVTOOLS-805:

Updated the code to restart the bundle in revision 1394917.

When Eclipse HCR fails Eclipse saves the Java type as out-of-synch type. During publishing
GEP checks if any of the modified classes are on this out-of-synch list and if so forces bundle
restart. If none of the modified classes are on the out-of-synch list then the class changes
are just persisted to the disk. 
Garbage collection is also forced after a bundle is restarted after HCR failure. This is done
in order to (or try to) ensure that there is only one copy of the given Java type loaded in
the server VM. Otherwise, Eclipse HCR might fail if tires to update two or more (i.e. old
and new) versions of the same Java type.
Every time bundle restart is forced after HCR failure the following informational message
will show up in the Eclipse "error log": Eclipse hot code replace failed - will restart bundle.
GEP also registers a custom HotCodeReplaceListener which prevents the Eclipse's standard "hot
code replace failed" dialog from showing. The HotCodeReplaceListener just logs the HCR results.

> Restart bundle when Eclipse HCR fails
> -------------------------------------
>                 Key: GERONIMODEVTOOLS-805
>                 URL:
>             Project: Geronimo-Devtools
>          Issue Type: Improvement
>          Components: eclipse-plugin
>    Affects Versions: 3.0
>            Reporter: Jarek Gawor
>            Assignee: Jarek Gawor
> Currently, when Eclipse hot code replace (HCR) fails at debug time the changes made to
the Java class are just persisted to disk. This can be improved a bit so that the bundle is
automatically restarted when HCR fails. This should allow the user to continue debugging the
class without being in an inconsistent state.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see:

View raw message