I tried it on GF 3.1.2 b17. Same behaviour on this version. If is possible, please plan to fix in 3.1.2, because issue is really critical. In fact, cannot switch to another loging level than INFO for all application and many system components (for example cannot set level FINE for ShoalLogger).

janouskovec
added a comment - 24/Jan/12 2:41 PM I tried it on GF 3.1.2 b17. Same behaviour on this version. If is possible, please plan to fix in 3.1.2, because issue is really critical. In fact, cannot switch to another loging level than INFO for all application and many system components (for example cannot set level FINE for ShoalLogger).

Java Logger is creating weak reference logger so when it's not referred it's removing the same. Now when your app is trying to use getLogger, it's creating new logger with parent log levels (which is INFO) so above app is not working.

I created strong logger reference in log manager service and updating every time when log level changes so it's not removing loggers now. So getLogger now returns existing logger only.

What is the impact on the customer of the bug?
It's highly impact and visible bug

How likely is it that a customer will see the bug and how serious is the bug?
When ever custom logger is created and reference is removed it's failing to log messages.

Is it a regression? Does it meet other bug fix criteria (security, performance, etc.)?
No

What is the cost/risk of fixing the bug?
It's not going to impact other functionality as I am just adding strong reference so JUL not remove any loggers.

How risky is the fix? How much work is the fix? Is the fix complicated?
Investigation of this bug took much time but fix is straight forward.

Is there an impact on documentation or message strings?
No.

Which tests should QA (re)run to verify the fix did not destabilize GlassFish?
You can run same app attached in this bug to verify the same.

naman_mehta
added a comment - 31/Jan/12 10:32 AM - edited Java Logger is creating weak reference logger so when it's not referred it's removing the same. Now when your app is trying to use getLogger, it's creating new logger with parent log levels (which is INFO) so above app is not working.
I created strong logger reference in log manager service and updating every time when log level changes so it's not removing loggers now. So getLogger now returns existing logger only.
What is the impact on the customer of the bug?
It's highly impact and visible bug
How likely is it that a customer will see the bug and how serious is the bug?
When ever custom logger is created and reference is removed it's failing to log messages.
Is it a regression? Does it meet other bug fix criteria (security, performance, etc.)?
No
What is the cost/risk of fixing the bug?
It's not going to impact other functionality as I am just adding strong reference so JUL not remove any loggers.
How risky is the fix? How much work is the fix? Is the fix complicated?
Investigation of this bug took much time but fix is straight forward.
Is there an impact on documentation or message strings?
No.
Which tests should QA (re)run to verify the fix did not destabilize GlassFish?
You can run same app attached in this bug to verify the same.
Which is the targeted build of 3.1.2 for this fix?
3.1.2 b19