Message catalog key not transformed: using.default.ds

[dmatej]

[2015-10-30T16:34:38.851+0100] [Payara 4.1] [WARNING] [] [javax.enterprise.resource.resourceadapter.org.glassfish.jdbcruntime] [tid: _ThreadID=17 _ThreadName=RunLevelControllerThread-1446219277451] [timeMillis: 1446219278851] [levelValue: 900] [[
using.default.ds]]
...
[2015-10-30T16:34:39.452+0100] [Payara 4.1] [WARNING] [] [javax.enterprise.resource.resourceadapter.org.glassfish.jdbc.util] [tid: _ThreadID=17 _ThreadName=RunLevelControllerThread-1446219277451] [timeMillis: 1446219279452] [levelValue: 900] [[
using.default.ds]]

There is another problem but from this message I could not identify the cause. It seems the message comes from the method
JdbcResourcesUtil.getRANameofJdbcConnectionPool

• and there is another problem of the code - cause of the error (exception) is not logged.

I will create another issue after this will be resolved. Current state with 4.1.1.154:

• clustered instance hangs on startup without any error in server.log. This is the last message in the log file.
• it seems it somehow depends on using the annotation:
  @schedule(second = "/10", minute = "", hour = "*", persistent = false)
• another instance in another cluster with applications not using this annotation starts without any problem.

[dmatej]

Pfff, also JdbcResourceUtil has some copy&pasted methods as JdbcRuntimeExtension. Both in same jar, jdbc-runtime ...

[dmatej]

Logging works in my Payara version but there is too much refactoring ... finally it seems that

• this problem is based on OSGi classloader for connectors-runtime; it's LogStrings.properties bundle is used also in jdbc-runtime, but this path is missing in exports in osgi.bundle
• another weird thing is too much voodoo programming in LogDomains class

I did these things but I'm not sure if they are completely correct except the first two (but everything together works, it seems):

• added com.sun.logging.enterprise.resource.resourceadapter; to exports
• added using thread context classloader to "guessing" part
• removed all synchronization from LogDomains
• added System.out/err logging for every "guessing" in LogDomains
• removed LogDomains classloader usage in "guessing" - it was completely unsuccessful
• added method to allow explicit classloader for bundle loading
• separated logger initialization and searching for resource bundle (maybe core of many sync problems)
• cleaned up ...

Now I'm too tired to finish it but it seems I can fix all similar glassfish logging issues :-)
And then the hanging ... and timers.

[dmatej]

Ok, finished. I will try the 502.2 branch with the clustered instances on monday.

[dmatej]

Since last commits I have found more unresolved message keys, but I have to leave it now. But the issue #502 is not completely resolved - it seems that the logging system was too heavy and developers always invented any way how to see their logs and were not interested what their change did to others.
The main problems are:

• source files moved to another jar file - their keys remained in a resource bundle hidden in another file (and classloader)
• conflicting paths - some LogString.properties are seen by the classloader sooner than other placed on the same relative path (from the classloader's view point)
• shared LogStrings.properties - hidden by osgi.bundle configuration and not accessible outside the jar file.
• LogStrings.properties found by another classloader (thread context); I don't know if this is correct but simetimes it works ... and sometimes not.
• I don't know how each of these problems can interact with the security policy ...

It would take weeks to fix it all, but it should be fixed because without perfect logging system is very hard to identify and fix most of bugs.

[mikecroft]

Created internal issue PAYARA-1063 to evaluate and pull these commits.

[lprimak]

@dmatej can you create a pull request for this?
This would be very helpful

[dmatej]

It seems my older commits are already merged to Payaras 4.1.1.163 and payara-blue-4.1.1.162, I have seen some unresolved keys sice then, but didn't fix them yet (one is fatal, payara could not create it's self signed certificates in one environment but I don't know why, because the cause was not printed in server.log - only "{0}").

[mikecroft]

Hi @dmatej are these changes still relevant? Is there more we need to do on this?

[dmatej]

I think we can close it now. Any other unresolved keys should be fixed in their own issues.