5 Replies Latest reply on Aug 7, 2013 7:57 AM by michaelh

    Why the JDBC client needs a local install

    mahes

      We are developing PI connectivity to a java based application.

       

      The application connects to PI server with a local JDBC installation.

       

      This defeat the purpose of a Java application. Just copying RDSAWrapper.dll into C:\Windows\system32\ doesn't work.

       

      Is there anyway to make java application to run without JDBC install?

       

      Any help appreciated.

       

      Thanks in advance

       

      Mahes

        • Re: Why the JDBC client needs a local install
          michaelh

          Not sure if I understand your question correctly.

           

          In order to use the PI JDBC driver, your java application needs access to PIJDBCDriver.jar ( at least via the Driver Manager )

           

          PIJDBCDriver.jar needs some native (c++) code to do the https connection to a (typically remote) PI SQL Data Access Server.

           

          In a windows environment with a 64 bit JVM, this native code is in RDSAWrapper64.dll

           

          With a 32 bit JVM,  RDSAWrapper.dll should be in an appropriate directory, depending on your Operating System (typically either C:\Windows\system32 or  C:\Windows\SysWOW64)

           

          The PI JDBC Setup copies all files to an appropriate location and sets some environment variables, to make sure the files can be found.
          Details regarding those environment variables can be guessed by reading the Linux installation. (Linux users are supposed to be smart enough to do this manually, apply it to their environment, or ignore it).
          By setting the environment variables PI_RDSA_LIB and/or PI_RDSA_LIB64  properly, RdsaWrapper could be located anywhere ...

           

          I don't understand why you do not want to use the setup kit, but of course there is "any way" to run without.
          Not sure if a future upgrade setup would work, so I would discourage from this approach.

            • Re: Why the JDBC client needs a local install
              Børre Heggernes

              PI JDBC provider is a type 1 (bridge). Maybe Mahes is looking for a type 4 implementation? en.wikipedia.org/.../JDBC_driver

                • Re: Why the JDBC client needs a local install
                  michaelh

                  The type 1 / type 4 classification is a rather legacy discussion from times where ODBC was "The Standard"
                  You could easily count PI JDBC as a type 2 driver, talking to  PI SQL DAS ( the database )

                   

                  But I agree with Børre and I was not sure if Mahes was looking for some pure Java solution.

                   

                  We were discussing such an approach some time ago ( moving all native code to the DAS side and have a pure Java client )
                  This was abandoned in favor of web services as platform independent communication.

                   

                  Besides the existing SOAP web services, we're going the REST path by an ODATA provider (soon to come, stay tuned)

                    • Re: Why the JDBC client needs a local install
                      mahes

                      Thanks, Michael for clear explanation.

                       

                      We have done the steps fine ( java lib, device driver and setting environment variables etc)

                       

                      The application is distributed as bundled .exe to run any clients  including Citrix.

                       

                      Therefore it is not easy to install jdbc.

                       

                      If we install jdbc, it runs fine with PI server.

                       

                      Without installtion (copying dll )

                       

                      java.sql.SQLException: Native RDSAWrapper

                       

                           at com.osisoft.jdbc.ConnectionImpl.<init>(ConnectionImpl.java:81)

                       

                           at com.osisoft.jdbc.DriverExtension.connect(DriverExtension.java:121)

                       

                           at com.osisoft.jdbc.Driver.connect(Driver.java:261)

                       

                           at java.sql.DriverManager.getConnection(Unknown Source)

                       

                           at java.sql.DriverManager.getConnection(Unknown Source)

                       

                           at org.apache.commons.dbcp.DriverManagerConnectionFactory.createConnection(DriverManagerConnectionFactory.java:51)

                       

                           at org.apache.commons.dbcp.PoolableConnectionFactory.makeObject(PoolableConnectionFactory.java:290)

                       

                           at org.apache.commons.pool.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:771)

                       

                           at org.apache.commons.dbcp.PoolingDataSource.getConnection(PoolingDataSource.java:95)

                       

                      ........

                       

                      Caused by: com.osisoft.rdsa.RdsaException: Native RDSAWrapper

                       

                           at com.osisoft.rdsa.NativeRDSA.<init>(NativeRDSA.java:214)

                       

                           at com.osisoft.rdsa.NativeRDSA.create(NativeRDSA.java:180)

                       

                           at com.osisoft.rdsa.NativeRDSA.create(NativeRDSA.java:127)

                       

                           at com.osisoft.jdbc.ConnectionImpl.<init>(ConnectionImpl.java:75)

                       

                      Deploying a java application connecting to PI is a minor issue.

                       

                      We are not looking for a pure Java solution.

                       

                      Thanks

                       

                      Mahes

                        • Re: Why the JDBC client needs a local install
                          michaelh

                          Thanks for your clarification , Mahes

                           

                          Caused by: com.osisoft.rdsa.RdsaException: Native RDSAWrapper
                          at com.osisoft.rdsa.NativeRDSA.<init>(NativeRDSA.java:214)
                          at com.osisoft.rdsa.NativeRDSA.create(NativeRDSA.java:180)
                          at ...

                           

                          is a good hint.

                          It is caused by an Exception when calling either  System.loadLibrary or System.load

                           

                          Which of these two call is used, depends on the existence of environment variables, and on the JVM architecture
                          similar to this sample code:

                           

                           

                           

                          // Get VM architecture
                          Properties pList = System.getProperties();
                          String arch = (String) pList.get("sun.arch.data.model");
                          if (arch.startsWith("64")) {
                             envLibPath = System.getenv("PI_RDSA_LIB64");
                             defaultLib = "RdsaWrapper64";
                          }
                          else {
                             envLibPath = System.getenv("PI_RDSA_LIB");
                            
                          defaultLib = "RdsaWrapper";
                          }

                           

                          ...

                           

                           

                           

                          if (envLibPath == null)
                              S
                          ystem.loadLibrary(defaultLib);
                          else {
                              // System.out.println ("Using c++ wrapper : "+ envLibPath);
                             
                          System.load(envLibPath); // full path recommended
                          }

                           

                          A standard setup sets the environment variables for both 64 and 32 bit JVM's

                           

                          Additionally, after your non-setup, you might run  getSnap ( included in the setup kit, see manual for details ;)
                          which would print more information ( One more level of  " caused by  .. " stack ) to stderr

                           

                          I guess you confused the 64 bit and the 32 bit version and/or their proper location.
                          Perhaps it's possible for you to set the appropriate environment variable, too.