So basically i have created user-defined JDBC provider through wsadmin:
AdminTask.createJDBCProvider('[-scope Cluster=MyCluster -databaseType User-defined -providerType "User-defined JDBC Provider" -implementationType User-defined -name "MSSQL JDBC Provider" -description "Microsoft SQL Server JDBC Driver" -classpath [${SQL_PATH}/sql.jar ] -nativePath "" -implementationClassName com.microsoft.sqlserver.jdbc.SQLServerConnectionPoolDataSource ]')
After that i want to create datasource. So basically when i use UI to create datasource - it fills 3 pages with custom properties (J2EEResourcePropertySet) of that datasource (55 J2EEResourceProperties).
If i use wsadmin it does not fills those 3 pages for some reason only i see ~8 custom properties (J2EEResourceProperties).
If i look at log command assistance commands when creating trough UI and script - those are the same.
Can someone explain me what is wrong? I need to have 55 custom properties when running a script also. Thanks.
Here is my datasource script:
jdbcprovider = AdminConfig.getid('/JDBCProvider:MSSQL JDBC Provider/')
AdminTask.createDatasource(jdbcprovider, '[-name DataSource1 -jndiName DataSource1 -dataStoreHelperClassName com.ibm.websphere.rsadapter.MicrosoftSQLServerDataStoreHelper -containerManagedPersistence true -componentManagedAuthenticationAlias SAmgr/DataSource1 ]')
Adding images to understand:
55 custom properties appeared: Creating datasource trough UI Custom Properties:
8 custom properties appeared: Creating datasource trough wsadmin script custom properties
EDIT: When you create a DataSource using a JDBC provider created using one of the pre-defined types, like MS SQL Server JDBC Driver, WAS uses the contents of a template to populate (among other things) the properties of the datasource. There is a template for both the 8 WebSphere properties (like webSphereDefaultQueryTimeout), and the other vendor-specific properties (like applicationName for MSSQL Server). The 8 WebSphere specific properties are common to all datasources and are maintained by WAS and are not properties of the JDBC driver. The properties in the vendor-specific template are a subset of all the vendor properties based on our assessment of whether it is “safe” to set/unset the property in a managed (JEE app server) environment.
Whether you create the datasource from the admin console or wsadmin, when the JDBC provider is based on one of the predefined vendors, the property set is the same since it’s coming from standard templates. The behavior difference you're seeing is because you’re creating a user-defined JDBC provider and not using one of the predefined ones. Typically, user-defined JDBC providers are only needed when the JDBC driver you want to use is not one of the pre-defined ones. When you create a datasource from a user-defined JDBC provider using the admin console, behind the scenes it is calling a method to introspect the driver and discover any public javabeans that the JDBC driver exposes as properties. The admin console then adds these properties to the datasource in addition to the 8 WebSphere properties from the template discussed above. The admin console performs the introspection because there is no template available for the vendor properties. However, when you create a datasource from a user-defined JDBC provider using wsadmin, it doesn’t perform that introspection, thus the only properties you see on the datasource will be the 8 WebSphere properties from the template discussed above. There are instances where the console executes some steps programmatically vs. via scripting and differences in behavior like this can arise. So, that's the answer to "why the difference”. After investigation, there no option to have the wsadmin command introspect the driver adding the additional properties. I see two ways you can address the issue and get the properties added.
If the set of driver properties you need is part of those included in the standard template for that driver, change from creating a user-defined JDBC provider to using one created with that driver vendor. Using wsadmin, you’ll get all the same properties you would get if you created it from the admin console. If some, but not all of the property(s) you need are in the template, you can add those properties via scripting using the AdminConfig.create(…) method as you suggested. After your config is saved, all objects created via scripting will be available to see in the admin console, including the custom properties.