geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aaron Mulder (JIRA)" <>
Subject [jira] Resolved: (GERONIMO-1200) HotDeployer gets IllegalStateExceptions during a non-hot deploy deploy of an app
Date Sat, 10 Dec 2005 09:33:08 GMT
     [ ]
Aaron Mulder resolved GERONIMO-1200:

    Resolution: Fixed

Fixed in HEAD (revision 355729) and 1.0 branch (revision 355730)

> HotDeployer gets IllegalStateExceptions during a non-hot deploy deploy of an app
> --------------------------------------------------------------------------------
>          Key: GERONIMO-1200
>          URL:
>      Project: Geronimo
>         Type: Bug
>   Components: deployment
>     Versions: 1.0
>  Environment: Win XP/1.4.2
>     Reporter: Kevan Miller
>     Assignee: Aaron Mulder
>     Priority: Minor
>      Fix For: 1.0
>  Attachments: HotDeploy.patch
> During a deploy of DayTrader, I get several (2 or 3) of the following warnings sent to
> 19:27:12,259 WARN  [DirectoryHotDeployer] Hot deployer unable to determine whether kernel
is started
> java.lang.IllegalStateException: Cannot retrieve the value for non-persistent attribute
kernelFullyStarted when GBeanInstance is DESTROYED
>         at org.apache.geronimo.gbean.runtime.GBeanInstance.getAttribute(
>         at org.apache.geronimo.kernel.basic.BasicKernel.getAttribute(
>         at
>         at
>         at
> The problem must be in HotDeployer.isServerRunning(). It's getting a list of PersistentConfiguration
GBeans and querying each one to see if it's active. Only when all are active is the server
determined to be "active". During a deploy, there must be GBeans which are destroyed, probably
as a replacement is created? (e.g. LocalAttributeManager).
> I have a patch (will post shortly) that sets a boolean to true once a server is detected
as "running". After it's set to true, we'll never check the GBeans again... Clearly we're
in need of a better way of determining server "state", any bright ideas? However, the boolean
fixes the problem at hand...

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

View raw message