am facing NonSqlTransientException Null userid not supported while starting the liberty server where my server.xml contain authdata
-
Looks like you may be missing something in your configuration. Can you post your server.xml and a stacktrace of your exception? – Alex Motley Aug 27 '18 at 19:16
-
Thanks @AlexMotley but the issue now got resolved.:) – mm6 Aug 30 '18 at 10:01
1 Answers
The authData configuration in Liberty is only for container managed authentication. If you are using application authentication (as is the case for JNDI lookup without resource reference, or if using a resource reference that is set to authentication type of Application), then authData does not apply. If you are using a resource reference with Container authentication, then you can use the authData, but there is an additional configuration step to associate the authData with the dataSource. This can be done in either of the following ways, documented in this knowledge center article.
One option is to configure the containerAuthDataRef of the dataSource to point at the id of the authData element (you'll need to add an id for it if it doesn't have one). Here is an example,
<authData id="myAuth" user="user1" password="pwd1"/>
<dataSource jndiName="jdbc/myDataSource" containerAuthDataRef="myAuth">
<jdbcDriver libraryRef=...
<properties...
</dataSource>
The other option is to specify the authData's id under the authentication-alias in the application's bindings (such as ibm-web-bnd.xml or ibm-ejb-jar-bnd.xml) for the data source. For example, the following bindings are based on the server config from the previous example,
<resource-ref name="java:app/env/jdbc/myDataSourceRef" binding-name="jdbc/myDataSource">
<authentication-alias name="myAuth"/>
</resource-ref>
It should be noted that the former is a default for container authentication that is used in the absence of the latter. So if you specify both ways, then the latter takes precedence and will be used instead.

- 3,399
- 9
- 7
-
Thanks for your solution..:) but these option didn't solve the issue so tried without
. hence removed – mm6 Aug 29 '18 at 09:48tag and included "user" and "password" in -
I assume you mean that you put the user, password attributes on the properties element, not jdbcDriver. They are not valid on jdbcDriver and would be completely ignored there. But on the properties element, for most JDBC vendor data source implementations these establish a default user and password that are used in the absence of having specified authentication in any other way. If that was your intent, it's fine. But if your intent was to only make the user/password available for container authentication, then you have inadvertently opened them up for application auth and direct lookup. – njr Aug 29 '18 at 18:02
-
Yes Correct i have put the user and password attributes on the properties element, not the jdbc driver. Well the intent was to avail the user & pwd so its working as expected. Many Thanks for help & sharing the knowledge :) – mm6 Aug 30 '18 at 10:00