geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dain Sundstrom <>
Subject Re: GBean configuration confusion
Date Wed, 04 Feb 2004 23:35:08 GMT
On Feb 4, 2004, at 5:20 PM, Greg Wilkins wrote:

> Dain Sundstrom wrote:
>>> If you try calling any methods on it, including toString, it gives 
>>> you  a
>>>    java.lang.IllegalStateException: Proxy is stopped
>>> I'm not sure what state this is meant to be in???
>>  Proxies are not valid until doStart.  This is due to the fact that 
>> the  pattern you have assigned for the endpoint may not match any 
>> other  running GBeans (or their may be more then one matching GBean). 
>>  When  you enter the running state we lock down the single reference.
> OK - so I should leave that config alone in the context constructor (I 
> was
> only wondering what it was :-)
> But as you say, the NPE that results if I don't catch the 
> IllegalStateException
> does appear wacky.


> To get this NPE, simply throw an IllegalStateException from the
> constructor of JettyWebApplicationContext and this will cause the NPE.

I'll try that.

> There are obviously other ways it can be triggerred, as I'm currently
> trying to add an attribute to the context GBean - I must have done 
> something
> wrong somewhere, that is resulting in an exception somewhere - as I'm 
> getting this
> NPE. But for the life of me I can't find out what the original 
> exception is yet.
> Still learning eclipse - so debugging multiple threads over multiple 
> projects
> with generated code is a tad beyond me at the moment.  So far my 
> exhaustive
> hunt-and-kill-bug-with-printlns approach has also failed to work out 
> where
> the problem is.

If you can reproduce it, I might be able to fix it for you.

> So any help working out the causes of the NPE and how to better catch 
> and
> report them would be good.  Perhaps just an empty catch block 
> somewhere?

Their is a bug in GBeanMBean.  The references used in the constructor 
are set online, which results in registration for mbean notifications.  
When the constructor fails, we don't take the references back offline, 
so we end up still listening for notifications.  I think I can fix this 
fairly easily.


View raw message