I want to open access to a database using JDBC protocol, so that many people in the company can access it.
The JDBC connection string would look like jdbc:sqlserver://[serverName[\instanceName][:portNumber].
I'm wondering if there is a way to have a layer of abstraction between the client and the server. Let me explain...
For example, using REST services, we can tell people to use a URL that looks like https://servername/path/to/resource/123, which we can url-rewrite to https://my-server/my-path/resource?id=123. Implementation, location, complexity is hidden from the user, and anything can be changed transparently.
Is there something similar we can do with JDBC ? For example, can I redirect jdbc://[serverName[\instanceName][:portNumber] to jdbc:sqlserver://[my--server[\my-instance][:my-port] ?
Thanks for your help !
We can't rewrite JDBC url.
But you can use JNDI (Javax Naming Directory Interface). You must configure JNDI data source first, ex: in tomcat 6.0
Then you can use this JNDI in your application
Related
I want to know if there's a way to configure the datasource for Ignite as Elastic Search. I was browsing the web. But I did not find a solution.
I want to implement this integration for a Java application.
If I understand your idea correctly there's a way to do it. As far as I can see Elasticsearch supports SQL table-like data access and it's available through jdbc connection. From the Ignite's side we have 3rd party persistance, it uses jdbc to connect to an underlying store system. To be honest I haven't tested it but I suppose it should work.
Also I need mention that you can use GridGain WebConsole to generate simple Ignite project from existing jdbc connection. This functionality could be found on Configuration tab -> Create Cluster Configuration.
WSO2 Identity Server 5.0.0 (and some patches ;))
It does not appear that custom JDBC user store managers (child of JDBCUserStoreManager) use a JDBC pool. I'm noticing that I can end up session closed errors and sql exceptions whereas the Identity Server itself is still operating OK with its separate database connection (a configured pool).
So I guess I have two questions about this:
Somewhere up the chain, is there a JDBC pool for the JDBCUserStoreManager? If so, are there means to configure that guy more robustly?
Can I create another JDBC datasource in master-datasources.xml which my custom JDBC user store manage could reference?
Instead of using your own datasources/connections, you can import Carbon Datasources and use those (they come with inbuilt pooling and no need to worry about any configurations etc). You can either access these programmatically by directly calling ndatasource component or access them via JNDI.
To access them directly from ndatasource component:
The dependency:
<dependency>
<groupId>org.wso2.carbon</groupId>
<artifactId>org.wso2.carbon.ndatasource.core</artifactId>
<version>add_correct_version_here</version>
</dependency>
(You can check repository/components/plugins to find out the correct version for above dependency)
You can inject DataSourceService as in this code (the #scr.reference tag refers to the service you need to inject, this uses maven scr plugin to parse these dependencies when building the bundle).
Note that when you follow this approach you'll have to build the jar as an OSGi bundle as it uses declarative services (and have to place it in repository/components/dropins). Otherwise the dependencies won't be injected at runtime.
Next, you can access all the data sources as:
List<CarbonDataSource> dataSources = dataSourceService.getAllDataSources();
Rajeev's answer was really insightful and helped with investigating and evaluating what I should do. But, I didn't end up using that route. :)
I ended up looking through the Identity Server and Carbon source code and found out that the JDBCUserStoreManager does end up creating a JDBC pool configured by the properties you set for that manager. I had a class called CustomUserStoreConstants for my custom user store manager which had setMandatoryProperty called by default to set:
JDBCRealmConstants.DRIVER_NAME
JDBCRealmConstants.URL
JDBCRealmConstants.USER_NAME
JDBCRealmConstants.PASSWORD
So the pool was configured with these values, BUT that was it...nothing else. So no wonder it wasn't surviving the night!
It turned out that the code setting this up, if it found a value for the JDBCRealmConstants.DATASOURCE in the config params, it would just load up that datasource and ignore any other params set. Seeing that, I got rid of those 4 params listed above and forced my custom user store to only allow having a DATASOURCE and I set it in code with the default JNDI name that I would name that datasource always. With that, I was able to configure my JDBC pool for this datasource with all params such as testOnBorrow, validationQuery, validationInterval, etc in master-datasources.xml. Now the only thing that would ever need to change is the datasource's configuration in that file.
The other reason I went with the datasource in the master-datasources.xml is that I didn't have to decided in my custom user store's code which parameters I would want to have or not have and just manage it all in the xml file easily. This really has advantages with portability of configs and IT involvement for deployments and debugging. I already have other datasources in this file for the IS deployment.
All said, my user store is now living through the night and weekends. :)
While trying to connect to my Oracle 11.1.0.7.0 database using jdbc with the ojdbc6.jar of the matching version, I found two variants.
Assuming a string DBURL of the form
jdbc:oracle:thin:#//#DBSERV#:#DBPORT#/#DBSID#
where those hashed words ('...') are filled correct, they (the variants) look like
ods=new oracle.jdbc.pool.OracleDataSource();
ods.setPassword(Datenbankpasswort);
ods.setUser(Datenbankuser);
ods.setURL(DBURL);
dbconn=ods.getConnection;
java.sql.DriverManager.registerDriver(new oracle.jdbc.OracleDriver());
dbconn=java.sql.DriverManager.getConnection(DBURL,Datenbankuser,Datenbankpasswort);
of course followed by dbconn.getConnection();.
So far, I think both should work - but I'm interested which way is better? Maybe one is deprecated?
Further I can only connect with variant 1. Maybe I missed something in variant 2.
I'm interested in any suggestions.
DataSource is the preferred way to provide connection to a database.
This kind of high-level object "do" the job for you and access to lower classes, like the DriverManager
You can find some implementations of DataSource more powerful, where connections are pooled and reusable: ConnectionPoolDataSource
DataSource are typically configured and registered into a JNDI tree.
Usually, application/web servers like Tomcat offer capability to configure (and share) a DataSource.
I was wondering: how does one go about configuring WAS if they want to store some confidential information that is not datasource, JMS or Mail related? I'm looking more for an adhoc JNDI resource (a few Strings) that can be queried at runtime to get both a username and password for a vendor system I need to connect to.
Not being uber familiar with WAS, I'm sort of lost. In Tomcat it was a breeze. In WAS, I think I'm missing a few concepts, I'm sure it's possible though.
WAS JNDI is open to extension using your own URL provider class. The examplehere uses the capability to point to property files, but presumably you could instead create a provider that obtained data from a database (or whatever repository you are required to use) instead of a property file.
You can define your own JNDI entries.
Under Environment -> Naming -> Name Space Bindings you can create String binding type, and assign a key and value which can be looked up by the applications.
Is this what you are after?
Manglu
I am looking for a tool that Logs SQL statemetns fired in the application as I use the application.
I found p6spy. But there is an issue with that. It doesnt seem to be compatible with XA Datasources.
Is there a way to make p6spy work on Websphere 6.1 OR is there an alternative to p6spy ?
Also, if anyone has any AspectJ code that intercepts the PreparedStatment object and dumps the SQL, that would also be great.
It is not mandatory for the JDBC drivers to implement a feature to be able to extract / print out the SQL statements. To be honest, I would do this in database. All reasonable database products can log in detail everything that comes in. Also, you can at the same time get further information like execution plans and their impact on the server.
It does depend on the way that you are accessing the database. If you are using Hibernate then you can make that spit out its SQL, if you are accessing the datasource through WAS then you can use the trace service. Set the trace to something like:
=info: com.ibm.websphere.rsadapter.=detail
And see what you get out of it.
I seem to remember there being some parameter you can add to your jdbc url configuration, and/or the connection. Can't remember the details.
You shold change trace level into jdbc driver.
If you using DB2 then change custom properties for data source
if you using Oracle then change driver on the ojbdc6_g.jar and change JVM properties