On a clean installation of Eclipse Kepler 4.3.2, with an installation not including anything like JPA aspects, Spring, whatever - just plain Java, I keep encountering this weird issue.
Upon building the project, but not running it even once, the file bin/META-INF/persistence.xml is constantly in use. Eclipse refuses to rebuild the project because of it, and I can't delete the file while Eclipse is running.
This locking does not happen to any other (XML) file in the same folder, or any file in any other folder. Just that one file. Since Eclipse without any Hibernate or JPA tools installed should have no concept of the importance of this file, why does this happen? Not even the original source file is locked!
How can I debug this?
I presume you use Windows. Like jpangamarca mentioned, I have the same problem with Eclipse Luna and came up with a temporary solution before it is addressed by Eclipse itself.
How can I debug this?
I used Process Explorer to find out which process is locking my xml files. In the application, go to menu Find -> Find Handle or DLL... (Ctrl + F), fill in your file path, it will list all processes using your file. It is likely eclipse.exe in this case. You can then go back to the main screen, select the file in the lower panel and right click then choose Close Handle (or hit Delete).
I wrote a little batch file to do this conveniently whenever I feel necessary:
#echo off
for /f "tokens=3,6,8 delims=: " %%i in ('handle -p eclipse e:\git\ ^| grep ".xml\|.xmi\|.htm"') do echo Releasing %%k & handle -c %%j -y -p %%i
(replace e:\git\ with your path to limit scope of damage, using grep to only release locks on specific file types)
For the batch to work, you need the following utilities available in your system path:
Handle
grep
For windows with UAC (win 7/8), you will need to run it as administrator. Or else it will tell you to.
This happened to me and in my case the root cause was Hibernate JPA 2 Metamodel Generator: https://docs.jboss.org/hibernate/jpamodelgen/1.0/reference/en-US/html_single/
The only solution I found is to use EclipseLink's Canonical Model Generation https://wiki.eclipse.org/UserGuide/JPA/Using_the_Canonical_Model_Generator_%28ELUG%29
What worked for me (I'm working with an EAR project > EJB module) was moving all configuration files from prj-root/src/META-INF to a prj-root/resources/META-INF folder, then I modified my Ant script accordingly to generate the assemblies.
EDIT: This happens when using hibernate-jpamodelgen to generate the entities' static metamodel. Upgrade to at least 4.3.9 and you'll get rid of the problem (see https://hibernate.atlassian.net/browse/HHH-9528).
The handle script worked for me, but maybe it was my process i had to search for javaw instead of eclipse.
Related
Im using the following config the debug jar file that under my root project, when I click on debug the program start to run but doesnt stopes since I didn't set any break-point(as this is jar file :) ) , In node.js there is option to do it with --inspect-brk info which stops on the first statement but not sure How to do it on jar file
My questions are
How can I stops in the first line of the program jar ?
Does my config are OK?
Oterwise , how can you able to debug jar if you cannot set a break-point ...
EDIT:
I've tried with the suggestion of crazycoder and it's not working, any idea?
What I tried is to create under my root project decomplie folder and run the following command
java -jar fernflower.jar zte.jar + decomplie/
I got erorr of course of not found
I've also tried with
java -cp java-decompiler.jar org.jetbrains.java.decompiler.main.decompiler.ConsoleDecompiler zte.jar + decomplie/
Could not find or load main class
org.jetbrains.java.decompiler.main.decompiler.ConsoleDecompiler
How to I get this jar (fernflower.jar ) or the path to it ?
EDIT2
My project is like this
-myjavaproj
--zte.jar
--decomile
---zte.jar
---com.proj.cli
----appmain.java
For your specific project that is one jar file (zte.jar) which contains deps.zip inside which in turn contains other .jar dependencies and no sources at all and also uses reflection and custom classloader in order to load and use the .jar files in deps.zip; for the debugger to work, you have to unpack all the jars from the deps.zip into some location, then make a new IntelliJ IDEA project and add all the jars (including the root zte.jar and all the jars unpacked from deps.zip) into the module dependencies.
Browse to CliExecutor inside the self.jar, in the project view, IntelliJ IDEA will decompile it, place the breakpoints, debug it.
Your config is a little strange, but correct. The VM options you provide tell the JVM to wait with running the zte.jar until a debugger is attached.
So you won't automatically stop on the first line, you need to add break-points in IDEA and attach it manually to the JVM process. This is explained here How to remote debug JVM
Keep in mind you are doing one thing sort of wrong. You do not need to setup the debug options in the VM options. Just select the JAR you want to debug, place break-points and start in debug mode (that is the bug like icon in IDEA).
I'm trying to Play 2 application on Windows Server Server 2012 using the "stage" task, with the goal of wrapping this up in a service so the application will automatically run when the server gets restarted. However, when running the app I get the following message:
The input line is too long.
The syntax of the command is incorrect.
This is because Windows has a limit of around 8000 characters for command line instructions but it seems like the Play stage command is exceeding this by passing the classpath as an argument.
Copying the "stage" folder to c:\ might fix the issue (as it'll reduce the size of the classpath) but I was hoping there would be a more elegant solution.
Has anyone found a way around this? Alternatively, do people have any suggestions for running a Play application on Windows so that it will automatically run when the server is restarted.
Thanks.
I also had the same issue and I wasn't satisfied with the solutions that you provided.
I have found a simpler solution.
Add the following line to the build.sbt file
lazy val root = (project in file(".")).enablePlugins(PlayScala, LauncherJarPlugin)
Now if you generate your production application with:
sbt dist
or run a production mode with
sbt start
The LauncherJarPlugin plugin will take care for generating proper bash/batch run scrips.
To get to know more about LauncherJarPlugin please read the documentation:
Sbt documentation about long classpath
How to enable plugin in build sbt
UPDATE: sbt native packager now comes with a number of built in solutions to this, see NieMaszNic's answer below.
This is a known issue, being tracked in the SBT native packager (which generates the start script) here:
https://github.com/sbt/sbt-native-packager/issues/72
My recommendation to work around this issue would be to write your own start batch script that uses a wildcard classpath matcher. You can put this script in the dist directory in your Play project, and it will end up being packaged up with your application. That script might look like this:
java %1 -cp "./lib/*;" play.core.server.NettyServer .
Note that if you use a wildcard classpath matcher, you can no longer rely on classpath ordering to be the same as in dev mode. You shouldn't rely on classpath ordering anyway, but people inevitably do.
Taking James's suggestions into account, the following solution works for a Play 2 application.
CD into the app and run play clean stage
Copy [your_app]/target/universal/stage/bin/[YOUR_APP].bat to [your_app]/dist (you may need to create the "dist" directory). I renamed the file as [your_app]_windows.bat to make it clear but the name doesn't really matter. Files in the "dist" directory get copied across with your app the next time you run the stage task (thanks James).
Open your new bat file in a text editor.
Files put in the "dist" directory are put in the "universal" directory (not "bin") so you'll need to change the home variable, i.e. remove the two full stops at the end so it doesn't navigate to the parent directory (on line 11 at present),
e.g.
if "%WEB_PORTAL_HOME%"=="" set "WEB_PORTAL_HOME=%~dp0\\.."
becomes:
if "%WEB_PORTAL_HOME%"=="" set "WEB_PORTAL_HOME=%~dp0"
You then need to change the class path, as per James's instructions, to use a wildcard rather than explicitly listing all the JAR files (at the moment this is on line 91)
e.g.
set "APP_CLASSPATH=%APP_LIB_DIR%\web-portal.web-portal-1.0-SNAPSHOT.jar;%APP_LIB_DIR%\commons-c.....
becomes:
set "APP_CLASSPATH=%APP_LIB_DIR%\web-portal.web-portal-1.0-SNAPSHOT.jar;%APP_LIB_DIR%\\*"
You can then run your new script (which is copied into the [your_app]/target/stage/universal directory).
Important: I'd recommend re-creating this file every time you upgrade
Play just in case the build script changes in future releases.
Change the longest line in your bat file with:
set "APP_CLASSPATH=%APP_LIB_DIR%\..\conf\;%APP_LIB_DIR%\*"
just before
set "APP_MAIN_CLASS=play.core.server.ProdServerStart"
Enable LauncherJarPlugin first
lazy val root = (project in file(".")).enablePlugins(PlayJava, PlayEbean, LauncherJarPlugin)
Then if you want just to start play with production mode you can use activator :
activator clean compile stage testProd
or fast version :
activator testProd
This will run play in production mode, i'm not sure if you have to addstage to command because i'm pretty sure that its already building with testProd, but its better to make sure you built the stage version.
This is probably a trivial question, but I am having trouble installing a Java API called JPIB_Windows into eclipse which should allow me to control external devices connected via GPIB.
This is the contents of the folder that I downloaded.
I created a new project in Eclipse, right clicked the project and went to build path -> configure build path.
I then clicked on add external libraries and added the JPIB.jar file. The file was added, but I am still not able to use the classes in the API.
Is there something else that I need to do to be able to use the API? Is there a better way of importing this API into my project?
You jar file is installed correctly. JPIB (and many other Java libraries) is just wrapper for low-level routines. So it is mandatory to load corresponding native libraries before using Java classes.
In Eclipse go to the Run > Run Configurations... > Arguments tab, select configuration for, perhaps, main method. Then specify in VM arguments field:
-Djava.library.path=C:\path\to\jpib\dll
Then add at the beginning of main() the following line:
System.loadLibrary("jpib_32");
Then run already edited configuration. Everything should be OK. But in case of failure you can examine path to DLL:
System.out.println("Libary path: " + System.getProperty("java.library.path"));
Also working directory can be specified in the same tab, avoiding absolute path, but for the first time absolute path is simple and less error-prone.
Also note that Java may not recognize Windows-specific issues (missing drivers, insufficient user privileges, wrong DLL version) and will report about general error.
I have a very strange problem, that I can't figure out, the thing is that my aplication runs perfectly on the IDE (Eclipse), but not when exported, when I run the jar (double click) the aplication start but some functionality is missing (loading from a template file, but this does not happend when loading from a normal file), when I try to run it from console (java - jar my.jar) in order to see any error message it turns out that my aplication works perfectly fine! :S ...
Some more info:
My app is running over windows 7
I start the task manager, and I noticed that when I start my aplication using double click its under the name java.exe *32, and when I do it from command line its under the name java.exe (without "*32"), as far as I know I programmed nothing related to a 32 or 64 bits functionallity.
"Solved"
Well I was not able to solve it the way I wanted, as far as I was able to find, i found that there were a problem between the 2 java versions I was running x32 & x64, I deleted the 32 bit version and it start working as a charm, but I'm still not sure about what happend, I give my thanks to #Sajal Dutta one of its comments help me to understand part of the problem, thanks to all of you anyway, I'll keep searching until I find the problem...
When you create a jar from Eclipse, your assets don't get copied over to jar or location is not preserved. Open the jar and check if you have your templates in the right location or you have it at all.
To have the exported jar include your assets/resources-
Right click on your project in Eclipse. Then New -> Source Folder.
Name the source folder anything. e.g. template_src.
Copy or drag the entire directory of your template to template_src. Then make the jar.
Since it works via the command line but not when double-clicking the jar, it is likely that the working directory is different (and that you're loading the template with a relative path). When you run an executable jar by double-clicking, on some operating systems, the working directory is the home directory whereas when you run from the command line, it's the directory you're currently in.
The "files" in the jar are not handled by File, but are resources;
URL url = getClass().getResource("...");
InputStream in = getClass().getResourceAsStream("...");
Then, the file paths inside a jar, or on a non-Windows platform are case-sensitive.
"Template_A.xml"
is not
"template_a.xml"
Also you might inspect the jar with 7zip or WinZip.
I am trying a sample project to rename a file using Eclipse. First, I did a commit and pushed to GitHub. The file was Samplemain.java. If I rename that file to SampleMain.java and if I try to commit the renamed file using TortoiseGit, I'm unable to commit. Instead, it's showing an error with a small dialog.
Please let me know the solutions for renaming files with case-sensitive in Git.
I am using Windows, the error dialog is shown below.
This is a problem with TortoiseGit, not with Git itself. If you commit using the command line it will work, I checked it now. Note that renaming still takes 2 git mv commands, but only one git commit, as it should.
Another alternative is to rename the file on GitHub: when editing a file on GitHub notice at the top that you can change the name. After that you can pull from it.
Run following command in Windows command line (MINGW console). It should fix the case detection problem.
git config core.ignorecase false
Two-stage rename... name it to something like 'z.tmp' then back to the name your really want.
I know with Subversion I have to commit between two-step renames, but with Mercurial I don't.
Not sure if Git needs it or not.
There's a utility made for this apparently: https://github.com/tawman/git-unite
I haven't been able to try it myself yet, as the author doesn't provide the final exe files, and I had an issue when trying to run the build script. But it seems to be a utility that would solve this issue more easily.
It searches for name-casing mismatches between repo and folders, and updates the repo to match the folder, letting you then commit with only one version of the files. So just change the names in Windows explorer to what you want, then run the utility, I believe. (maybe followed by a commit -- not sure)