By deep confirmation, the way of modifying RunLevel value is not right
because the issue still has possiblity of being triggered.
So, pl. ignoring my original fixing way.
However, I found another fixing way and seems more safe. The fixing way
is delaying Recovery Helper Thread's running and after
PostStartupRunLevel has been finished, by sending event, running
Recovery Helper Thread.
about detailed fixing way, pl. seeing the attachment. I also request
JTS's leader to confirm the patch.
Thanks
Tang
Tang Yong wrote:
> JMS)Leader
> CC: Sahoo
>
> pl. allowing me open a new thread for GLASSFISH-20934.
>
> Firstly, I request you can see the issue. if having any issue, pl. tell
> me and I will re-check my description.
>
> Secondly, about fixing way, I have a very simple method as following:
>
> [original definition]
> @Service
> @RunLevel(value=PostStartupRunLevel.VAL,
> mode=RunLevel.RUNLEVEL_MODE_NON_VALIDATING)
> public class JmsProviderLifecycle implements PostConstruct{
> ...
> }
>
> [my fixing way]
> @Service
> @RunLevel(value=StartupRunLevel.VAL,
> mode=RunLevel.RUNLEVEL_MODE_NON_VALIDATING)
> public class JmsProviderLifecycle implements PostConstruct{
> ...
> }
>
>
> That is to say, making org.glassfish.main.jms.core can be started
> earlier. Because this is also related to kernel starting, cc Sahoo for
> evaluation.
>
> Thanks
> Tang
--
−−−−−−−−−−−−−−−−−−−−−−
Tang Yong
Senior Engineer
GlassFish Committer (OSGi & OSGi-JavaEE)
OSGi Alliance Supporter
Blog: http://osgizone.typepad.com/tangyong/
Nanjing Fujitsu NanDa Software Tec CO.,LTD
http://www.fujitsu.com/cn/fnst
Tel: +86-25-86630566-8310
Fax: +86-25-83317685
−−−−−−−−−−−−−−−−−−−−−−