I have spent quite some time reading previous posts, but none of them seem to help me. I'm trying to run a simple Java app from NetBeans, here the simplest code:
final String DB_URL = "jdbc:derby:CoffeeDB;create=true";
try
{
// Create a connection to the database.
Connection conn = DriverManager.getConnection(DB_URL);
// If the DB already exists, drop the tables.
dropTables(conn);
// Build the Coffee table.
buildCoffeeTable(conn);
// Close the connection.
conn.close();
}
catch (Exception ex)
{
System.out.println("ERROR: " + ex.getMessage());
}
Usually is the environmental variables causing trouble, but I have checked that and they seem to be set up correctly:
CLASSPATH:
C:\Program Files\Java\jdk1.7.0_17\db\lib\derby.jar;C:\Program Files\Java\jdk1.7.0_17\db\lib\derbytools.jar;
DERBY_HOME
C:\Program Files\Java\jdk1.7.0_17\db
PATH: (only the part concerning jdbc )
C:\Program Files\Java\jdk1.7.0_17\db\bin
I already created a table using ij from the command prompt and it worked, is when I try to run it through Netbeans when I get this error. Something interesting though, is when I run the sysinfo from the command prompt, it comes up like this:
------------------ Java Information ------------------
Java Version: 1.7.0_17
Java Vendor: Oracle Corporation
Java home: C:\Program Files\Java\jre7
Java classpath: C:\Program Files\Java\jdk1.7.0_17\db\lib\derby.jar;C:\Program Files\Java\jdk1.7.0_17\db\lib\derbytools.jar;C:\Program Files\Java\jdk1.7.0_17\db/lib/derby.jar;C:\Program Files\Java\jdk1.7.0_17\db/lib/derbynet.jar;C:\Program Files\Java\jdk1.7.0_17\db/lib/derbyclient.jar;C:\Program Files\Java\jdk1.7.0_17\db/lib/derbytools.jar
OS name: Windows Vista
OS architecture: amd64
OS version: 6.0
---> As you can see, somehow more information is added to the previous classpath, and the derbytools.jar and derby.jar appear twice?? combined with inverted slashes??
When debugging through NetBeans, the exception comes from this line in the DriverManager.java file:
Connection con = aDriver.driver.connect(url, info); <--------------- here
if (con != null) {
// Success!
println("getConnection returning " + aDriver.driver.getClass().getName());
return (con);
}
the url is correct: jdbc:derby:CoffeeDB;create=true but the connection comes back null and throws the SQLexception. Any ideas?
The exception message "No suitable driver found for ..." means that none of the loaded JDBC drivers accepted the URL. This makes it very likely that the JDBC driver simply isn't included in the classpath of the application
The environment variable CLASSPATH is almost always ignored when a java application is run from an IDE, and always if run from an executable jar. Make sure that the build-path in the IDE actually contains derby.jar, or if it is an executable jar, that it is listed in the META-INF/manifest.mf in the Class-Path attribute.
you can right click the project and do the following steps...Build -> Configure Build Path -> Libraries -> Add External Jar... now you have to specify the path to the *.jar file.
simple example https://github.com/mraab89/Tutorial_Java_Database_Connectivity_JDBC
Related
I have windows 10 machine, and JDeveloper 12.2.1.4.0 , when i try to run the weblogic server for the first time i get this error :
Adding environment variable to WLST script USER_MEM_ARGS = -Xms32m -Xmx1024m -XX:MaxPermSize=384m
Log File: C:\Users\OSMOHAME\AppData\Roaming\JDeveloper\system12.2.1.4.42.190911.2248\o.j2ee.adrs\BuildDefaultDomain.log
Label: JDEVADF_PT.12.2.1.4.0_GENERIC_190911.2248.S
Product Home: D:\Oracle\Middleware\BPM_12.4\jdeveloper\jdev\
Domain: C:\Users\OSMOHAME\AppData\Roaming\JDeveloper\system12.2.1.4.42.190911.2248\DefaultDomain
BuildDefaultDomain1.py 2020-06-05 09:14:45
cmd.exe /c ""D:\Oracle\Middleware\BPM_12.4\oracle_common\common\bin\wlst.cmd" "C:\Users\OSMOHAME\AppData\Roaming\JDeveloper\system12.2.1.4.42.190911.2248\o.j2ee.adrs\BuildDefaultDomain1.py""
Cannot run program "cmd.exe" (in directory "D:\Oracle\Middleware\BPM_12.4\oracle_common\common\bin"): Malformed argument has embedded quote: "D:\Oracle\Middleware\BPM_12.4\oracle_common\common\bin\wlst.cmd" "C:\Users\OSMOHAME\AppData\Roaming\JDeveloper\system12.2.1.4.42.190911.2248\o.j2ee.adrs\BuildDefaultDomain1.py"
java.io.IOException: Cannot run program "cmd.exe" (in directory "D:\Oracle\Middleware\BPM_12.4\oracle_common\common\bin"): Malformed argument has embedded quote: "D:\Oracle\Middleware\BPM_12.4\oracle_common\common\bin\wlst.cmd" "C:\Users\OSMOHAME\AppData\Roaming\JDeveloper\system12.2.1.4.42.190911.2248\o.j2ee.adrs\BuildDefaultDomain1.py"
at java.lang.ProcessBuilder.start(ProcessBuilder.java:1048)
at oracle.jdevimpl.adrs.weblogic.wlst.ScriptRunnerImpl.runScript(ScriptRunnerImpl.java:106)
at oracle.jdevimpl.adrs.weblogic.builder.DomainScriptRunnerImpl.runScript(DomainScriptRunnerImpl.java:146)
at oracle.jdevimpl.adrs.weblogic.builder.DefaultDomainBuilder.createDomain(DefaultDomainBuilder.java:606)
at oracle.jdevimpl.adrs.weblogic.builder.DefaultDomainBuilder.build(DefaultDomainBuilder.java:274)
at oracle.jdevimpl.adrs.weblogic.builder.DefaultDomainBuilder$1.run(DefaultDomainBuilder.java:225)
at org.openide.util.RequestProcessor$Task.run(RequestProcessor.java:1443)
at org.netbeans.modules.openide.util.GlobalLookup.execute(GlobalLookup.java:68)
at org.openide.util.lookup.Lookups.executeWith(Lookups.java:303)
at org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java:2058)
Caused by: java.lang.IllegalArgumentException: Malformed argument has embedded quote: "D:\Oracle\Middleware\BPM_12.4\oracle_common\common\bin\wlst.cmd" "C:\Users\OSMOHAME\AppData\Roaming\JDeveloper\system12.2.1.4.42.190911.2248\o.j2ee.adrs\BuildDefaultDomain1.py"
at java.lang.ProcessImpl.needsEscaping(ProcessImpl.java:279)
at java.lang.ProcessImpl.createCommandLine(ProcessImpl.java:202)
at java.lang.ProcessImpl.<init>(ProcessImpl.java:436)
at java.lang.ProcessImpl.start(ProcessImpl.java:140)
at java.lang.ProcessBuilder.start(ProcessBuilder.java:1029)
... 9 more
i did some research and most people tell that the solution in the following url is fixing the problem
http://unversioned.blogspot.com/2015/12/jdeveloper-12c-generic-installer-cannot-create-weblogic-domain.html
but the problem is when i open the javashell.py file , i don't find an entry for
_osTypeMap =
it Doesn't Exist in the file
Also , another solution the people said it worked is by adding this line
Djdk.lang.Process.allowAmbiguousCommands=true
but they didn't said where to add it and what is the exact steps !
There is a known issue with JDeveloper, WLS 12.2.1.4 and JDK 8 opened at My Oracle Support : Bug 30670839 : INTEGRATED WLS CANNOT BE CREATED WHEN USING JDK1.8.0_231
There is no patch available for now but you can try the workaround provided in the bug note : Revert back to JDK shipped with JDeveloper
If we see, problem is with the type of command that JDeveloper executes to start the weblogic instance is old and therefore does not work correctly, however below solution is working. It did solve the issue in my machine
We must modify this file:
C:<JDEVELOPER Install Path>\ide\bin\ide.conf
Add the following line:
AddVMOption -Djdk.lang.Process.allowAmbiguousCommands = true
Post modification, save the file.
Restart the Jdeveloper, compile and launch the weblogic server.
I have a bunch of unit tests which contain code like:
File file = new File("src/main/java/com/pany/Foo.java");
assertTrue("Missing file: " + file.getAbsolutePath(), file.exists());
This test is suddenly failing when running it with Maven Surefire and -DforkCount=0. With -DforkCount=1, it works.
Things I tried so far:
The file does exist. Windows Explorer, command line (copy & paste), text editors, Cygwin can all find it and show the contents. That's why I think it's not a permission problem.
It's not modified by the unit tests or anything else. Git shows no modifications for the last two months.
I've checked the file system, it's clean.
I've tried other versions of Java 8, namely 8u171 and 8u181. Same problem.
I've run Maven from within Cygwin and the command prompt. Same result.
Reboot :-) No effect :-(
More details:
When I see this problem, I start to see the "The forked VM terminated without properly saying goodbye. VM crash or System.exit called?" in other projects. That's why I tried forkCount=0 which often helps in this case to find out why the forked VM crashed.
This has started recently, maybe around the October 2018 update of Windows 10. Before that, the builds were rock solid for about three years. My machine was switched to Windows 10 late 2017, I think.
I'm using Maven 3.6 and can't easily try an older version because of an important bug that was fixed with it. I did see the VM crash above with Maven 3.5.2 as well.
It's always the same files which fail (so it's stable).
ulimit (from Cygwin) says:
$ ulimit -a
core file size (blocks, -c) unlimited
data seg size (kbytes, -d) unlimited
file size (blocks, -f) unlimited
open files (-n) 256
pipe size (512 bytes, -p) 8
stack size (kbytes, -s) 2032
cpu time (seconds, -t) unlimited
max user processes (-u) 256
virtual memory (kbytes, -v) unlimited
I'm wondering if the "open files" limit of 256 only applied to Cygwin processes or whether that's something which Cygwin reads from Windows.
Let me know if you need anything else. I'm running out of ideas what I could try.
Update 1
Bernhard asked me to print absolute names. My answer was that I was already using absolute names but I was wrong. The actual code was:
File file = new File("src/main/java/com/pany/Foo.java");
if (!file.exists()) {
log.debug("Missing file {}", file.getAbsolutePath());
... fail ...
}
... do something with file...
I have now changed this to:
File file = new File("src/main/java/com/pany/Foo.java").getAbsoluteFile();
if (!file.exists()) {
log.debug("Missing file {}", file);
}
and that fixed the problem. I just can't understand why.
When Maven creates a forked VM to run the tests with Surefire, then it can change the current directory. So in this case, it would make sense that the tests work when forked but fail when running in the same VM (since the VM was created in the root folder of the multi-module build). But why is making the path absolute before the call to exists() fixing the issue?
Some background. Each process has a notion of "current directory". When started from the command line, then it's the directory in which the command was executed. When started from the UI, it's usually the folder in which the program (the .exe file) is.
In the command prompt or BASH, you can change this folder with cd for the process which runs the command prompt.
When Maven builds a multi-module project, it has to change this for each module (so that the relative path src/main/java/ always points to the right place). Unfortunately, Java doesn't have a "set current directory" method anywhere. You can only specify one when creating a new process and you can modify the system property user.dir.
That's why new File("a").exists() and new File("a").getAbsoluteFile().exists() work differently.
The latter will use new File(System.getProperty("user.dir"), "a") to determine the path and the former will use the Windows API function _wgetdcwd (docs) which in turn uses a field of the Windows process to get the current directory - in our case, that's always the folder in which Maven was originally started because Java doesn't update the field in the process when someone changes user.dir and Maven can only change this property to "simulate" changing folders.
WinNTFileSystem_md.c calls fileToNTPath(). That's defined in io_util_md.c and calls pathToNTPath(). For relative paths, it will call currentDirLength() which calls currentDir() which calls _wgetdcwd().
See also:
https://github.com/openjdk-mirror/jdk7u-jdk/blob/jdk7u6-b08/src/windows/native/java/io/WinNTFileSystem_md.c
https://github.com/openjdk-mirror/jdk7u-jdk/blob/jdk7u6-b08/src/windows/native/java/io/io_util_md.c
and here is the place where the Surefire plugin modifies the Property user.dir: https://github.com/apache/maven-surefire/blob/56d41b4c903b6c134c5e1a2891f9f08be7e5039f/maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java#L1060
When not forking, it's copied into the current VM's System properties: https://github.com/apache/maven-surefire/blob/56d41b4c903b6c134c5e1a2891f9f08be7e5039f/maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java#L1133
So I have checked via printing out the system properties with some simple tests.
During the tests via maven-surefire-plugin the user.dir will be changed to the root of the appropriate module in a multi module build.
But as I mentioned already there is a system property available basedir which can be used to correctly handle the location for tests which needs to access them via File...The basedir is pointed to the location of the pom.xml of the appropriate module.
But unfortunately the basedir property is not set by IDEA IntelliJ during the test run.
But this can be solved by a setup like this:
private String basedir;
#Before
public void before() {
this.basedir = System.getProperty("basedir", System.getProperty("user.dir", "Need to think about the default value"));
}
#Test
public void testX() {
File file = new File(this.basedir, "src/main/java/com/pany/Foo.java");
assertTrue("Missing file: " + file.getAbsolutePath(), file.exists());
}
This will work in Maven Surefire with -DforkCount=0 as well as -DforkCount=1 and in IDE's (checked only IDEA IntelliJ).
And yes that is an issue in Maven Surefire plugin changing the user.dir.
We might convince IDE's to support the basedir property as well ?
Aaron, we develop the Surefire. We can help you if you provide the path for this:
assertTrue("Missing file: " + file.getAbsolutePath(), file.exists());
Pls post the actual path, expected path and basedir where your POM resides.
The theory would not help here. We are testing all the spectrum of JDKs 7-12 but we do not have the combination Cygwin+Windows which must be considered.
The code setting user.dir in Surefire you mentioned exists a decade.
I have experience UnsatisfiedLinkError when I tried to use
flink-s3-fs-hadoop to sink to s3 in my local Windows machine.
I googled and tried several solutions like download hadoop.dll and
winutils.exe, set up HADOOP_HOME and PATH environment variables, copy hadoop.dll to C:\Windows\System32, but none of them worked.
I also tried to load the hadoop library myself in the code by using
System.loadlibrary("hadoop"), it succeed, but the error still happen,
anything additional step I am missing?
Here is my code (the 2nd and 3rd line is just trying to debug and it will succeed on the 2nd line but throw the UnSatisfiedLink exception in 3rd line):
public static void main(String[] args) throws Exception {
System.loadLibrary("hadoop");
NativeIO.Windows.access(null, NativeIO.Windows.AccessRight.ACCESS_READ);
StreamExecutionEnvironment env = StreamExecutionEnvironment.getExecutionEnvironment();
env.setParallelism(1);
DataStream<String> ds = env.readTextFile("s3://fts-test/test/input.csv");
ds.print();
ds.writeAsText("s3://fts-test/test/output.csv");
env.execute();
}
By the way I am using Window 7 64 bit, flink 1.5.
Our J2EE based application is run on Websphere Applicaiton Server- AIX server with 2 versions of DB2 Client installed (Db2v9.5, Db2v9.7).
I have a db SAMPLE which is remotely cataloged in both the two DB2 client versions with the same alias name SAMPLE.
If I uncatalog the DB from DB2v9.5 , the application goes down. However if I drop it from DB2v9.7 client the application is not impacted.
From this above test , we understand that some how DB2v9.5 is being used by default.
My objective now is to make the SAMPLE be pointed to only DB2v9.7 and the App must work without the sample DB in DB2v9.5.
Any suggestions on how to do it ?
The JDBC string used is "jdbc:db2:sample" (Note: there is no port for DB2 Client)
I have already tried to point $LIBPATH & $LD_LIBRARY_PATH to DB2v9.7 native lib32 path,
and also pointed the AIX user ID's .profile to DB2v9.7/sqllib/db2profile ,But no luck.
Regards,
Chandru
You have to check the default environment where Java is running, you will detect which Client is using. You could do that by executing "env" via Runtime, and see the defaults.
For example, with a small app like this:
import java.lang.*;
import java.io.*;
public class Test {
public static void main (String[] args) throws Exception {
Process p = Runtime.getRuntime().exec("env");
String line;
BufferedReader input = new BufferedReader(new InputStreamReader(p.getInputStream()));
while ((line = input.readLine()) != null) {
System.out.println(line);
}
input.close();
System.out.println("library " + System.getProperty("java.library.path"));
}
}
You call it with the same parameters you call your other application (JDBC driver included), and then check the output.
java <your params, classpath to db2java.zip> Test
Check the parameters like DB2INSTANCE, PATH, CLASSPATH.
More information in http://www.ibm.com/developerworks/data/library/techarticle/dm-0512kokkat/
List the files in /usr/lib and /usr/include. Do you see any file that points to DB2?
ls -l /usr/lib
ls -l /usr/include
Probably, you executed a db2ln, and that created links to a specific DB2 Client (9.5). Each time you execute the Java application, the LIBPATH takes precedence over /usr/lib, than the specified DB2 version
LIBPATH=/usr/lib:/lib:/opt/IBM/db2/V9.7/lib32
You can run the db2rmln command to remove the links.
Take a look at this page: http://publib.boulder.ibm.com/infocenter/db2luw/v9r5/topic/com.ibm.db2.luw.qb.server.doc/doc/t0006747.html
This issue was resolved by completely killing all the JVM that is running from the same version and path of java and starting them back. (In our case an AIX JVM pConsole was running behind even after putting Dmgr,Node & CL down. Both pConsole and WAS uses the same java)
That was the reason that the updated shared native libraries didn't reflect in the WAS. But after killing&starting back each instance of java, including the ones apart from WAS the native libraries got reflected in the logs .
Sorry about updating the answer after so long.
My VS2010 database deploy is failing on my build server, which has SQL Server 2008 R2 installed on it. Here's the output that's relevant:
Creating Acme.Database...
D:\TeamCity\BuildAgent\Work\da2fc5ebd5805d44\src\Acme.Database\sql\Acme.Database.sql(30,0): Error SQL01268: .Net SqlClient Data Provider: Msg 5133, Level 16, State 1, Line 1 Directory lookup for the file "C:\Program Files\Microsoft SQL Server**MSSQL10.MSSQLSERVER**\MSSQL\DATA\Acme_Database_log.ldf" failed with the operating system error 3(The system cannot find the path specified.).
D:\TeamCity\BuildAgent\Work\da2fc5ebd5805d44\src\Acme.Database\sql\Acme.Database.sql(30,0): Error SQL01268: .Net SqlClient Data Provider: Msg 1802, Level 16, State 1, Line 1 CREATE DATABASE failed. Some file names listed could not be created. Check related errors.
An error occurred while the batch was being executed.
The actual path is here:
C:\Program Files\Microsoft SQL Server**MSSQL10_50.MSSQLSERVER**\MSSQL\DATA\Acme_Database.mdf
The only reference to the path I could find in the database project was in the root folder, a file called:
PRIMARY.Acme_Database.sqlfile.sql
It includes an ALTER DATABASE statement that I changed to use the _50 path, but this did not fix the issue.
I'm not sure why the db project needs to know where the actual database MDF file is located in any case - I would have thought it could just connect to it vis TSQL, but in any case I can't get the project to deploy with this error and would appreciate any help.
Turns out if you specify a "file" in Schema Objects\Database Level Objects\Storage\Files (use Add Item, File) the values specified in the path override those looked up from the Server. If you must specify them use the variables from sqlcmdvariables $(DefaultdataPath)$(Databasename) to fill things out.
Take a look at the default file path on the server itself.
Screencast: http://screencast.com/t/OWM5ODFjZj
The fact that you don't have a path specified could likely be the issue.
[Update]
The reason I suggest this is that during the creation of the deployment script, if you have not specified the settings in the Project Settings -> Deployment tab, the DefaultDataPath is looked up from the target server's path.
I don't know anything about TeamCity really so this may be a stupid question, but how are you doing the deployment? It looks like the MSBuild deploy task for a DB project can take a property that gives the data path:
http://www.codewrecks.com/blog/index.php/2009/10/06/deploy-a-database-project-with-tfs-build/
Can you set the path that way?
I had the same error, but a different solution.
For me everything was correct (as far as I can tell), but the generated deploy script set the path variables before the databasename variable - resulting in a reference to a variable that did not exist. I updated Database.sqlcmdvars to hardcode the database name value - not best practice, but a sufficient workaround for my needs.