Develop Reference

need insight with logstash and elk

I am trying to add in data from logstash to elastic search bellow is the config file and the result on the terminal
input {
file {
path => "F:/business/data/clinical_trials/ctp.csv"
start_position => "beginning"
sincedb_path => "C:/Users/matth/Downloads/logstash-7.14.2-windows-x86_641/logstash-
7.14.2/data/plugins/inputs/file/.sincedb_88142d557695dc3df93b28d02940763d"
}
}
filter {
csv {
separator => ","
columns => ["web-scraper-order", "web-scraper-start-url", "First Submitted Date"]
}
}
output {
stdout { codec => "rubydebug"}
elasticsearch {
hosts => ["https://idm.es.eastus2.azure.elastic-cloud.com:9243"]
index => "DB"
user => "elastic"
password => "******"
}
}
and when i run i get the following it gets right down to the piplines and the next step should be establishing connection with elastic but it hangs on pipeline forever.
OpenJDK 64-Bit Server VM warning: Option UseConcMarkSweepGC was deprecated in version 9.0 and will likely be removed in a future release.
C:/Users/matth/Downloads/logstash-7.14.2-windows-x86_641/logstash-7.14.2/vendor/bundle/jruby/2.5.0/gems/bundler-1.17.3/lib/bundler/rubygems_integration.rb:200: warning: constant Gem::ConfigMap is deprecated
Sending Logstash logs to C:/Users/matth/Downloads/logstash-7.14.2-windows-x86_641/logstash-7.14.2/logs which is now configured via log4j2.properties
[2021-09-22T22:40:20,327][INFO ][logstash.runner ] Log4j configuration path used is: C:\Users\matth\Downloads\logstash-7.14.2-windows-x86_641\logstash-7.14.2\config\log4j2.properties
[2021-09-22T22:40:20,333][INFO ][logstash.runner ] Starting Logstash {"logstash.version"=>"7.14.2", "jruby.version"=>"jruby 9.2.19.0 (2.5.8) 2021-06-15 55810c552b OpenJDK 64-Bit Server VM 11.0.12+7 on 11.0.12+7 +indy +jit [mswin32-x86_64]"}
[2021-09-22T22:40:20,383][WARN ][logstash.config.source.multilocal] Ignoring the 'pipelines.yml' file because modules or command line options are specified
[2021-09-22T22:40:21,625][INFO ][logstash.agent ] Successfully started Logstash API endpoint {:port=>9600}
[2021-09-22T22:40:22,007][INFO ][org.reflections.Reflections] Reflections took 46 ms to scan 1 urls, producing 120 keys and 417 values
[2021-09-22T22:40:22,865][INFO ][logstash.outputs.elasticsearch][main] New Elasticsearch output {:class=>"LogStash::Outputs::ElasticSearch", :hosts=>["https://idm.es.eastus2.azure.elastic-cloud.com:9243"]}
[2021-09-22T22:40:23,032][INFO ][logstash.outputs.elasticsearch][main] Elasticsearch pool URLs updated {:changes=>{:removed=>[], :added=>[https://elastic:xxxxxx#idm.es.eastus2.azure.elastic-cloud.com:9243/]}}
[2021-09-22T22:40:23,707][WARN ][logstash.outputs.elasticsearch][main] Restored connection to ES instance {:url=>"https://elastic:xxxxxx#idm.es.eastus2.azure.elastic-cloud.com:9243/"}
[2021-09-22T22:40:24,094][INFO ][logstash.outputs.elasticsearch][main] Elasticsearch version determined (7.14.1) {:es_version=>7}
[2021-09-22T22:40:24,096][WARN ][logstash.outputs.elasticsearch][main] Detected a 6.x and above cluster: the `type` event field won't be used to determine the document _type {:es_version=>7}
[2021-09-22T22:40:24,277][INFO ][logstash.javapipeline ][main] Starting pipeline {:pipeline_id=>"main", "pipeline.workers"=>12, "pipeline.batch.size"=>125, "pipeline.batch.delay"=>50, "pipeline.max_inflight"=>1500, "pipeline.sources"=>["C:/Users/matth/Downloads/logstash-7.14.2-windows-x86_641/logstash-7.14.2/config/logstash-sample.conf"], :thread=>"#<Thread:0x52ff5a7a run>"}
[2021-09-22T22:40:24,346][INFO ][logstash.outputs.elasticsearch][main] Using a default mapping template {:es_version=>7, :ecs_compatibility=>:disabled}
[2021-09-22T22:40:24,793][INFO ][logstash.javapipeline ][main] Pipeline Java execution initialization time {"seconds"=>0.51}
[2021-09-22T22:40:24,835][INFO ][logstash.javapipeline ][main] Pipeline started {"pipeline.id"=>"main"}
[2021-09-22T22:40:24,856][INFO ][filewatch.observingtail ][main][c4df97cc309d579dc89a5115b7fcf43a440ef876f640039f520f6b116b913f49] START, creating Discoverer, Watch with file and sincedb collections
[2021-09-22T22:40:24,876][INFO ][logstash.agent ] Pipelines running {:count=>1, `:running_pipelines=>[:main], :non_running_pipelines=>[]}
any help as to why my data isnt getting to elastic??? please help

THE HIVE 4: impossible to launch because of cortex.connector module not found

I'm trying to setup The Hive 4 but it fails to start saying:
Cannot load module[Module [connectors.cortex.CortexConnector] cannot be instantiated
I look at the modules loaded in the java process module list and found:
/opt/thehive/lib/org.thp.thehive-cortex-4.0.0-RC1.jar
/opt/thehive/lib/org.thp.cortex-client-4.0.0-RC1.jar
/opt/thehive/lib/org.thp.cortex-dto-4.0.0-RC1.jar
As it is working with the version 3 of The Hive, I looked at the loaded modules and only found:
/opt/thehive/lib/org.thehive-project.thehivecortex-3.3.0-1.jar
I've checked the connection to my cortex server with:
curl -H 'Authorization: Bearer OBFUSCATED' http://OBFUSCATED:9001/api/analyzer
It works
I hop someone could help because I'm completely stuck.
Thanks in advance
Here's my application.conf
play.http.secret.key = OBFUSCATED
# Authentication
auth {
# ad : use ActiveDirectory to authenticate users. Configuration is under "auth.ad" key
provider = [local]
}
# Maximum time between two requests without requesting authentication
session {
warning = 5m
inactivity = 1h
}
play.http.parser.maxMemoryBuffer= 1M
play.http.parser.maxDiskBuffer = 1D
# Cortex
play.modules.enabled += connectors.cortex.CortexConnector
cortex {
"CORTEX-SERVER-ID" {
url = "https://OBFUSCATED:9001/"
key = "OBFUSCATED"
}
refreshDelay = 1 minute
maxRetryOnError = 3
statusCheckInterval = 1 minute
}
https.port: 9000
play.server.https.keyStore {
path: /etc/thehive/keystore.jks
type: JKS
password: OBFUSCATED
}
http.port: disabled
auth.method.basic = true
db {
provider: janusgraph
janusgraph {
storage {
backend: cql
hostname: [
"127.0.0.1"
] # seed node ip addresses
#username: "<cassandra_username>" # login to connect to database (if configured in Cassandra)
#password: "<cassandra_passowrd"
cql {
cluster-name: thehivedb # cluster name
keyspace: thehive # name of the keyspace
local-datacenter: datacenter1 # name of the datacenter where TheHive runs (relevant only on multi datacenter setup)
# replication-factor: 2 # number of replica
read-consistency-level: ONE
write-consistency-level: ONE
}
}
}
}
storage {
provider: hdfs
hdfs {
root: "hdfs://thehive1:10000" # namenode server
location: "/thehive"
username: thehive
}
}

this is the solution I've obtained on the TheHive github project:
See the key "play.modules.enabled" in application.conf. Replace
play.modules.enabled += connectors.cortex.CortexConnector
by
play.modules.enabled += org.thp.thehive.connector.cortex.CortexModule

A fatal error in Junit with objectify

I cannot discover why my integrations tests with objectify that are crashing.
There is no problem when is executed one by one or debuging.
That is the objectify code.
protected void before() throws Throwable {
original = ObjectifyService.factory();
ObjectifyFactory factory = newObjectifyFactory();
for (Class<?> type : register) {
factory.register(type);
}
ObjectifyService.setFactory(factory);
closeable = ObjectifyService.begin();
}
protected void after() {
ObjectifyService.setFactory(original);
closeable.close();
}
After some tests the runner stop and i receive this message.
#
# A fatal error has been detected by the Java Runtime Environment:
#
# EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x0000000000000003, pid=15104, tid=9848
#
# JRE version: Java(TM) SE Runtime Environment (7.0_80-b15) (build 1.7.0_80-b15)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (24.80-b11 mixed mode windows-amd64 compressed oops)
# Problematic frame:
# C 0x0000000000000003
#
# Failed to write core dump. Minidumps are not enabled by default on client versions of Windows
#
# An error report file with more information is saved as: Compiled method (nm) 7403 625 n java.lang.Class::isInstance (native) total in heap [0x0000000002b4bf10,0x0000000002b4c2b8] = 936 relocation [0x0000000002b4c030,0x0000000002b4c088] = 88 main code [0x0000000002b4c0a0,0x0000000002b4c2b8] = 536 Compiled method (c2) 7404 752 java.lang.invoke.LambdaForm$NamedFunction::invoke_L_L (28 bytes) total in heap [0x0000000002c38490,0x0000000002c38778] = 744 relocation [enter image description here][1][0x0000000002c385b0,0x0000000002c385d0] = 32 main code [0x0000000002c385e0,0x0000000002c38660] = 128 stub code [0x0000000002c38660,0x0000000002c38698] = 56 oops [0x0000000002c38698,0x0000000002c386a0] = 8 scopes data [0x0000000002c386a0,0x0000000002c386e8] = 72 scopes pcs [0x0000000002c386e8,0x0000000002c38748] = 96 dependencies [0x0000000002c38748,0x0000000002c38750] = 8 handler table [0x0000000002c38750,0x0000000002c38768] = 24 nul chk table [0x0000000002c38768,0x0000000002c38778] = 16

Whatever you are seeing here is a JVM bug. This is not supposed to be possible. Make sure you have the most recent version of the JDK installed, and if so, the only place you can really file an issue is with Oracle :-(

How do I trigger the default signal handling behavior?

In my Java application I want to capture SIGINTs, do some pre-processing, and then let the default behavior (process termination) run. I would think I could do something like this:
Signal.handle(new Signal("INT"), new SignalHandler() {
#Override
public void handle(Signal signal) {
// preprocessing
// ...
// now do default behavior
SignalHandler.SIG_DFL.handle(signal);
}
});
However when I send at SIGINT to this application, I get a SEGV:
#
# A fatal error has been detected by the Java Runtime Environment:
#
# SIGSEGV (0xb) at pc=0x0000000000000000, pid=10261, tid=21507
#
# JRE version: Java(TM) SE Runtime Environment (8.0_51-b16) (build 1.8.0_51-b16)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (25.51-b03 mixed mode bsd-amd64 compressed oops)
# Problematic frame:
# C 0x0000000000000000
#
# Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
#
# An error report file with more information is saved as:
# /private/tmp/hs_err_pid10261.log
#
# If you would like to submit a bug report, please visit:
# http://bugreport.java.com/bugreport/crash.jsp
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#
Abort trap: 6
It seems SignalHandler.SIG_DFL is not meant to be called directly (even from other signal handling code). So how can I manually trigger it?
Alternatively, how can I manually replicate the behavior of SIG_DFL? It appears to be equivalent to:
System.exit(signal.getNumber() + 128)
but I don't see any documentation to that effect.
Another way to phrase my question:
In practice* is there a difference between these two code blocks?
A)
Signal.handle(new Signal("INT"), SignalHandler.SIG_DFL);
B)
Signal.handle(new Signal("INT"), new SignalHandler() {
#Override
public void handle(Signal signal) {
System.exit(signal.getNumber() + 128)
}});
*I know undocumented behavior could change at any time, but it's unlikely that the JVM's exit behavior will change mid-version. An answer that simply details what happens now is acceptable, in practice.

I think the key to the mystery here is that SIG_DFL is not the original handler for SIGINT.
The following code worked for me:
Signal sigInt = new Signal("INT");
// First register with SIG_DFL, just to get the old handler.
final SignalHandler oldHandler = Signal.handle(sigInt, SignalHandler.SIG_DFL );
// Now register the actual handler
Signal.handle(sigInt, new SignalHandler(){
#Override
public void handle(Signal signal) {
System.err.println("Sigint is being handled");
oldHandler.handle(signal);
}
});
This does not cause the segmentation violation, and instead terminates the program as expected (after printing the sample text).

Credit for originally noticing this goes to RealSkeptic, but I wanted to expand on it in an answer.
The default behavior for SIGINT, SIGTERM, and SIGHUP is not, in fact, SignalHandler.SIG_DFL. Instead, the java.lang.Terminator class registers a SignalHandler that simply calls Shutdown.exit():
SignalHandler sh = new SignalHandler() {
public void handle(Signal sig) {
Shutdown.exit(sig.getNumber() + 0200);
}
};
You can capture this SignalHandler by calling Signal.handle() (since it returns the old handler), or you can simply define your own handler that calls System.exit() which will do the same thing.
Note that Terminator's call to Shutdown.exit() is not exactly the same as System.exit(). The former is package-private, meaning you can't call it directly. If a security manager prevents you from calling System.exit(), you'll have to capture the original handler and reuse it.
Warning: this is undocumented behavior. It's unlikely but entirely possible that future releases of Java could change this behavior.

Exiting with 128+signal number seems to be typical on Unix/Linux.
Are there any standard exit status codes in Linux?
For more evidence, see also:
http://journal.thobe.org/2013/02/jvms-and-kill-signals.html
Browsing the source code on OpenJDK suggests that the default behaviour is to allow the underlying C Runtime or OS default action to proceed.
In any case this is only typical behaviour, and as you point out is not documented. Exit codes are not standardized - generally there is a convention that zero means success, and nonzero failure, but even the first part is not always adhered to. Therefore it is for you to define your own exit codes.

informix jdbc stuck connecting

I'm trying to connect to a Informix database server with jdbc using the standard way :
connection = DriverManager.getConnection("jdbc:informix-sqli://"+ip+
/"+sid+":INFORMIXSERVER="+server+";user="+user+";password="+pass+"");
But it keeps trying to connect and does not throw a error message (I suppose it tries to connect because it does not show anything). I'm using IBM Informix driver 4.10.00.1534 and Java 1.7.
I have been using this method to connect to Informix servers until now, in fact it only fails with one server. I can connect to this server through Informix clients with odbc but it keeps failing with jdbc with no error message.
Is there any method to verbose the jdbc connection? Any suggestion about why it fails?
UPDATE: The sqlidebug trace:
C->S (4)
SQ_VERSION
SQ_EOT
S->C (14)
SQ_VERSION
"7.31.TD6" [8]
SQ_EOT
C->S (66)
SQ_INFO
INFO_ENV
Name Length = 12
Value Length = 8
"DBTIME"="%d/%M/%Y"
"DBTEMP"="/tmp"
"SUBQCACHESZ"="10"
INFO_DONE
SQ_EOT
S->C (2)
SQ_EOT
C->S (16)
SQ_DBOPEN
"database" [8]
NOT EXCLUSIVE
SQ_EOT
S->C (28)
SQ_DONE
Warning..: 0x15
# rows...: 0
rowid....: 0
serial id: 0
SQ_COST
estimated #rows: 1
estimated I/O..: 1
SQ_EOT
C->S (78)
SQ_PREPARE
# values: 0
CMD.....: "select site from informix.systables where tabname = ' GL_COLLATE'" [65]
SQ_NDESCRIBE
SQ_WANTDONE
SQ_EOT
And the jdbctrace.log says:
trying com.informix.jdbc.IfxDriver
SQLWarning: reason(Database selected) SQLState(01I04)
SQLWarning: reason(Float to decimal conversion has been used) SQLState(01I05)
SQLWarning: reason(Database has transactions) SQLState(01I01)
SQLWarning: reason(Database selected) SQLState(01I04)
SQLWarning: reason(Database has transactions) SQLState(01I01)
SQLWarning: reason(Database selected) SQLState(01I04)

Try to run code that connects do Informix database but also shows full exception info and create trace files. One trace file is for JDBC, one is for Informix. Change URL to database, username and password, and run it. You will probably see the problem on screen or in trace file:
import java.io.FileWriter;
import java.io.PrintWriter;
import java.sql.Connection;
import java.sql.DriverManager;
import java.sql.ResultSet;
import java.sql.Statement;
class informix_trace
{
public static void main(String[] args)
{
try
{
Class.forName("com.informix.jdbc.IfxDriver");
FileWriter fwTrace = new FileWriter("c:\\JDBCTrace.log");
PrintWriter pwTrace = new PrintWriter(fwTrace);
DriverManager.setLogWriter(pwTrace);
String debug_url = "SQLIDEBUG=C:\\sqlidebug.trace";
String url = "jdbc:informix-sqli://1.2.3.4:9088/test_db:informixserver=ol_testifx;DB_LOCALE=pl_PL.CP1250;CLIENT_LOCALE=pl_PL.CP1250;charSet=CP1250;" + debug_url
Connection connection = DriverManager.getConnection(url, "user", "passwd");
Statement statement = connection.createStatement();
ResultSet resultSet = statement.executeQuery("SELECT FIRST 1 DBINFO('version','full') FROM systables;");
while (resultSet.next())
System.out.println(resultSet.getObject(1));
}
catch (Exception e)
{
e.printStackTrace();
}
}
} // class informix_trace
Informix trace file will be with some postfix (timestamp or similar info) and in my case it was something like sqlidebug.trace1391758523500.0. It is binary but you can analyze it using sqliprt utility.
Example of my session with wrong database name:
c:\>sqliprt sqlidebug.trace1391758523500.0
SQLIDBG Version 1
...
S->C (12)
SQ_ERR
SQL error..........: -329
ISAM/RSAM error....: -111
Offset in statement: 0
Error message......: "" [0]
SQ_EOT
In JDBCTrace.log I can found more interesting info (I see it also on my screen):
SQLState(IX000) vendor code(-111)
java.sql.SQLException: ISAM error: no record found.
at com.informix.util.IfxErrMsg.getSQLException(IfxErrMsg.java:413)
at com.informix.jdbc.IfxSqli.E(IfxSqli.java:3412)
at com.informix.jdbc.IfxSqli.dispatchMsg(IfxSqli.java:2324)
....
at java.sql.DriverManager.getConnection(Unknown Source)
at informix_trace.main(informix_trace.java:20)
getConnection failed: java.sql.SQLException: No database found or wrong system privileges.
(I have translated it from Polish so it can be little different)

My suggestion is to:
build ConnectString and show us its full content, this way we will see if in ip there is only IP address or if it is with port number
instead of adding username and password to ConnectString use 3 parameter version of getConnection() just like:
getConnection("jdbc:informix-sqli://169.0.5.10:9088/test_db:informixserver=ol_test;DB_LOCALE=pl_PL.CP1250;CLIENT_LOCALE=pl_PL.CP1250;charSet=CP1250", username, password)
(of course set your own locale instead of my Polish locale)
To spy network traffic use tools like Wireshark. Start capturing ip traffic to your Informix database. In my case Wireshark rule is:
ip.addr == 169.0.5.10
If I set up wrong IP Wireshark will display "Destination unreachable".
You can also see someting using netstat:
c:\>netstat -an | grep 9088
TCP 169.0.1.126:4295 169.0.5.10:9088 TIME_WAIT
It was when my application stopped working.
In case of error (wrong IP port) I see:
c:\>netstat -an | grep 9089
TCP 169.0.1.126:4398 169.0.5.10:9089 SYN_SENT

IBM says that: From version 3.00.JC1 of IBM® Informix® JDBC Driver onwards, debug drivers are no longer shipped.
Informix JDBC Driver now supports SQLIDEBUG. You no longer need to set values for TRACE, TRACEFILE or PROTOCOLTRACE, PROTOCOLTRACEFILE. You only need to set SQLIDEBUG. and the page goes on to outline the steps you need to create a trace. Copying:
Set the CLASSPATH to the Informix JDBC Driver package.
c:\Infx\Java>set
CLASSPATH=C:\infx\JDBC3.00JC3\lib\ifxjdbc.jar;C:\infx\JDBC3.00JC3\lib\ifxjdbcx.jar;.
Compile simple.java
c:\Infx\Java>javac simple.java
Ensure that SQLIDEBUG is set correctly
c:\Infx\Java>grep SQLIDEBUG simple.java
conn=DriverManager.getConnection("jdbc:informix-sqli://irk:1526/sysmaster:INFORMIXSERVER=irk940;USER=informix;
PASSWORD=ximrofni;SQLIDEBUG=C:\infx\java\trace");
Note: SQLIDEBUG is set in the connection string. It points to where
the trace file will be found with a certain format i.e.
trace.xxxxxxx
Remove or move all other trace files
c:\Infx\Java>del trace*
Run java.simple
c:\Infx\Java>java simple systables syscolumns ... ...
oledbordinals
Then locate the trace file
c:\Infx\Java>dir trace* Volume in drive C has no label. Volume
Serial Number is B823-46D8
Directory of c:\Infx\Java
04/04/2006 14:12 20,560 trace1144156355642.0 1 File(s) 20,560 bytes
0 Dir(s) 4,067,995,648 bytes free
c:\Infx\Java>
You will be able to see that a trace file has been created however
you will not be able to read the file.
Send the trace file to your local technical support office for
analysis.
Of course, if you're not using Version 3.00.JC1 of the Informix drivers, ignore the above and follow a different set of instructions; again duplicated for your convenience:
To turn on tracing, specify the environment variables TRACE,
TRACEFILE, PROTOCOLTRACE, and PROTOCOLTRACEFILE in the database URL or
the property list when you establish a connection to an Informix
database or database server. TRACE can be set to one of the following
levels:
Tracing not enabled. This is the default value.
Traces the entry and exit points of methods.
Same as Level 1, plus generic error messages are also traced.
Same as Level 2, plus data variables are also traced. TRACEFILE Specifies the full pathname of the operating system file on the client
computer to which the TRACE messages are written.
PROTOCOLTRACE traces the SQLI protocol messages sent between your Java
program and the Informix database server.
Can be set to the following levels:
Protocol tracing not enabled. This is the default value.
Traces message IDs.
Same as Level 1, plus the data in the message packets are also traced. PROTOCOLTRACFILE specifies the full pathname of the operating
system file on the client computer to which the PROTOCOLTRACE messages
are written.
Hope that helps

try different jdbc version
check NETTYPE configuration parameter and compare it with current number of informix sessions
dump java thread states (kill -3 ) when jdbc connection hangs

import java.sql.Connection;
import java.sql.DriverManager;
import java.sql.SQLException;
import com.informix.*;
public class DBConnect {
static String url="jdbc:informix-sqli://host_name:port/database_name:INFORMIXSERVER=server;user=username;password=password";
public static void main(String [] args){
try {
Class.forName("com.informix.jdbc.IfxDriver");
}catch (Exception e){
System.out.println("ERROR: failed to load Informix JDBC driver.");
e.printStackTrace();
return;
}
try{
DriverManager.registerDriver((com.informix.jdbc.IfxDriver)Class.forName("com.informix.jdbc.IfxDriver").newInstance());
}catch(Exception ex){
System.out.println("Driver is not Registered");
}
try{
Connection conn = DriverManager.getConnection(url);
System.out.println("Connection Successful");
}catch (SQLException e){
System.out.println("ERROR: failed to connect!");
System.out.println("ERROR: " + e.getMessage());
e.printStackTrace();
return;
}
}
}
For more info go through [this book] (http://www.cursor-distribution.de/aktuell.11.70.xC6/documentation/ids_jdbc_bookmap.pdf)

The problem I encountered was that Informix was listening on local IPv6 address on port 7360, command netstat -a was displaying this format :
TCP [feab::11ab:78ab:efab:8aab%17]:7360 myhostname:0 LISTENING
Therefore my jdbc connection was always failing until I figured out I should have use the IPv6 address in the URL :
jdbc:informix-sqli://fe80::1125:78c0:ef17:8ab5%17:7360:user=informix;password=test;INFORMIXSERVER=ol_informix1210_2
You can test that the connection is working with this simple script :
/***************************************************************************
*
* Title: SimpleConnection.java
*
* Description: Demo a connection to a server (no database specified)
*
* An example of running the program:
*
* java SimpleConnection
* 'jdbc:informix-sqli://myhost:1533:user=<username>;password=<password>'
*
* Expected result:
*
* >>>Simple Connection test.
* URL = "jdbc:informix-sqli://myhost:1533:user=<username>;password=<password>"
* >>>End of Simple Connection test.
*
***************************************************************************
*/
import java.io.PrintWriter;
import java.sql.Connection;
import java.sql.DriverManager;
import java.sql.SQLException;
public class SimpleConnection {
public static void main(String[] args) {
if (args.length == 0) {
System.out.println("FAILED: connection URL must be provided in order to run the demo!");
return;
}
String url = args[0];
String testName = "Simple Connection";
Connection conn = null;
System.out.println(">>>" + testName + " test.");
System.out.println("URL = \"" + url + "\"");
try {
Class.forName("com.informix.jdbc.IfxDriver");
} catch (Exception e) {
System.out.println("FAILED: failed to load Informix JDBC driver.");
}
try {
PrintWriter out = new PrintWriter(System.out, true);
DriverManager.setLogWriter(out);
conn = DriverManager.getConnection(url);
} catch (SQLException e) {
System.out.println("FAILED: failed to connect!");
}
try {
conn.close();
} catch (SQLException e) {
System.out.println("FAILED: failed to close the connection!");
}
System.out.println(">>>End of " + testName + " test.");
}
}