I am preparing to use jdbc for the first time and am in the process of installing the jdbc driver for MySQL.
However, it is unclear to me which of these files to move to the WEB_INF/lib folder in Eclipse. They both seem to contain the same content and are included together in the downloaded zip file for the MySQL connector.
I have searched everywhere but have been unable to find any documentation to explain which of these files to use.
I thought you were joking, but I just downloaded the zip from https://dev.mysql.com/downloads/connector/j/ and, indeed, it contains both.
The mysql-connector-java-5.1.46.jar and mysql-connector-java-5.1.46-bin.jar are binary identical, except for the META-INF/INDEX.LIST (which contains the actual jar filename). I have unzipped both and compared them using kdiff3.
In short: you can use either: whatever you prefer.
This change is mentioned in CHANGES as:
- Fix for Bug#27231383, PROVIDE MAVEN-FRIENDLY COMMERCIAL PACKAGES WITHOUT "-BIN".
Interestingly, there is no bug 27231383 in the MySQL bug tracker (the number is too high for the 'normal' bugs listed), so maybe it is from another system within Oracle.
In addition, the online Connector/J 5.1.46 release notes mentions:
The bundle for Connector/J 5.1 delivered by Oracle now contains an
additional jar package with the name mysql-connector-java-5.1.ver.jar
(mysql-connector-java-commercial-5.1.ver.jar for commercial
bundles). It is identical with the other jar package with the original
package named mysql-connector-java-5.1.ver-bin.jar
(mysql-connector-java-commercial-5.1.ver-bin.jar for commercial
bundles), except for its more Maven-friendly file name. (Bug #27231383)
Presumably, given the closer match to Maven naming conventions, this makes it easier to install the library in local/company Maven repositories (eg if you don't want, or legally can't, use Maven Central).
But to repeat: they are the same, and you can use either one.
Building a spring-boot app, we are depending on a 3rd party jar-file,
that expects to find a properties-file with hardcoded filename (say xyz.properties) on the classpath,
and will read its properties from that.
We need, though, to "switch in" different version of this properties-file, depending on in which environment we deploy the jar-file.
So would need, preferably, to add to the classpath a directory external to the jar-file, where we can put the properties-file.
Googling this, I find other people having similar issue,
but not a simple, clean solution for it.
It seems to me, the spring properties-model assumes you only care abt the property-names and their values
(picking them up from System.getProperties())
and really dont care abt from which property-file each value comes.
This may be fine when building your own code along that model,
but may fit not so well when depending on 3rd party solutions, like our use-case.
The simplest workaround I found is to "explode" the spring jar file,
then copy desired property-files into WEB-INF/classes,
then start with the JarLauncher.
Just wondering if there is a better way, without need to "explode" it?
Is my understanding above correct, or have I just overlooked some spring-feature that already supports this use-case?
Hopefully it still works - but with some trick you can set your own classpath:
java -cp "./conf/:yourBoot.jar" org.springframework.boot.loader.JarLauncher
and then you can place your config in external dir (as you already suggested).
See original question: Add jar file to spring-boot classpath at runtime
As of Java 7u45 an applet will display a warning message (even if signed with a trusted cert) if a webpage tries to interact with it via javascript and that page isn't listed in the manifest's Caller-Allowable-Codebase attribute.
Release notes about this change: http://www.oracle.com/technetwork/java/javase/7u45-relnotes-2016950.html
Oracle blog post about this bug: https://blogs.oracle.com/java-platform-group/entry/7u45_caller_allowable_codebase_and
Attribute description: http://docs.oracle.com/javase/7/docs/technotes/guides/jweb/manifest.html#caller_allowable
I have tried just a wildcard (*), but I still get the warning.
Is there a way around this other than listing all codebases it may run at?
The reason this is a problem for me is that this applet runs on many different machines and networks, but always on intranets at various locations. This applet also needs to communicate with javascript because it talks to local USB scales and displays results and interacts with the page.
Applet in question: https://github.com/JaggedJax/CIO_Scale
My findings are the same:
This prevents warnings with Java 7u21 - 7u40:
Manifest-Version: 1.0
Trusted-Library: true
This exclusivly prevents warnings with Java 7u45:
Manifest-Version: 1.0
Application-Library-Allowable-Codebase: *
Caller-Allowable-Codebase: *
Mixing both won't work in 7u45.
Now what?
Did anyone find a way to allow SIGNED applets with "all-permissions" to run without warnings in both JRE-versions?
What the hell is wrong with oracle?
Removing the Trusted-Library attribute seems to be mandatory to get Caller-Allowable-Codebase working, no more warnings. However, this breaks Java 7 Update 21 - 40 which treated JavaScript code that calls code within a signed applet running with all permissions as mixed code and warning dialogs are raised if the signed JAR files are not tagged with the Trusted-Library=true attribute.
This will be fixed in a future release, according to the oracle blog post:
https://blogs.oracle.com/java-platform-group/entry/7u45_caller_allowable_codebase_and
They recognize the error "Both of these attributes should work together to support the various versions of client installations". But for now, their solution is: "The current work-around would be to favor using Caller-Allowable-Codebase over the old Trusted-Library call. "
I had the same issue. Solution for me was using same parameters in manifest as Oracle used on donwload page in applet for verify java version http://www.java.com/en/download/installed.jsp
Their applet does not popup any warnings.
so solution is:
Manifest-Version: 1.0
Codebase: *
Permissions: all-permissions
Application-Library-Allowable-Codebase: *
Caller-Allowable-Codebase: *
Application-Name: APPNAME
it works on:
1.7.0_17-b02
1.7.0_25-b17
1.7.0_45-b18
from oracle:
Area: Deployment/Plugin
Synopsis: Caller-Allowable-Codebase may be ignored when used with Trusted-Library.
If a trusted, signed jar is using the Caller-Allowable-Codebase manifest attribute along with Trusted-Library then the Caller-Allowable-Codebase manifest entry will be ignored and, as a result, a JavaScript -> Java call will show the native LiveConnect warning. The workaround is to remove the Trusted-Library manifest entry.
http://www.oracle.com/technetwork/java/javase/7u45-relnotes-2016950.html
The only solution that I can think of that works with 7u45 and the Trusted-Library versions (7u21, 7u25 and 7u40) is to create two different JARs with different manifests and then detecting the user's version and loading the right one.
The main version served to versions before 7u21 and 7u45 and up will have the new Caller-Allowable-Codebase and no Trusted-Library entry. The second version produced will have Trusted-Library and will be served only to 7u21, 7u25 and 7u40.
Here is an ant macro to create the new jar with the modified manifest:
<macrodef name="addtrustedlibrarytojar">
<attribute name="jarpath" />
<attribute name="newjarpath" />
<sequential>
<echo>Unzipping #{jarpath} to add Trusted-Library</echo>
<mkdir dir="build/temp_trusted_library" />
<unjar src="#{jarpath}" dest="build/temp_trusted_library" />
<echo>Inserting Trusted-Library in manifest</echo>
<replaceregexp match="^" replace="Trusted-Library: true${line.separator}" flags="s">
<fileset dir="build/temp_trusted_library/META-INF" includes="MANIFEST.MF"/>
</replaceregexp>
<echo>Creating #{newjarpath}</echo>
<zip file="#{newjarpath}" basedir="build/temp_trusted_library" />
<echo>Deleting build/temp_trusted_library directory</echo>
<delete dir="build/temp_trusted_library" />
</sequential>
</macrodef>
Call the macro like this for each JAR that needs the change made:
<addtrustedlibrarytojar jarpath="dist/myapplet.jar" newjarpath="dist/myapplet_tl.jar" />
Remember to sign the new JAR. If it was signed already this change will invalidate the signature.
We use the PluginDetect library to detect the version of Java. Just extract PluginDetect_Java_Simple.js and getJavaInfo.jar. This code will get the java version:
<script type="text/javascript" src="js/PluginDetect_Java_Simple.js"></script>
<script type="text/javascript">
var javaVersionDetected = '0';
function javaDetectionDone(pd) {
javaVersionDetected = pd.getVersion("Java");
if (console) console.info('Detected java version: ' + javaVersionDetected);
}
PluginDetect.onDetectionDone("Java", javaDetectionDone, "js/getJavaInfo.jar", null);
</script>
We use javascript to launch our applets so we use this to decide between the standard and trusted-library applets:
if (javaVersionDetected === '1,7,0,21' || javaVersionDetected === '1,7,0,25' || javaVersionDetected === '1,7,0,40') {
if (console) console.debug('Using TL applet');
attribs['archive'] = 'applets/myapplet_tl.jar';
}
else {
if (console) console.debug('Using normal applet');
attribs['archive'] = 'applets/myapplet.jar';
}
I had the same issue, So I remove Trusted-Library=true from my MANIFEST.MF, work Caller-Allowable-Codebase attribute fine.
For update 1.7.0_25 (and probably 21-40), setting the security settings to Medium in the Java Control Panel -> Security tab removes prompting when using the manifest tags for update 1.7.0_45.
This set of attributes allows the applet to load without warnings in Java 7u45:
Application-Name: ...
Main-Class: com...
Sealed: true
Codebase: *
Caller-Allowable-Codebase: *
Permissions: all-permissions
We have tested on the following JVMs:
Java 6u20 (OK, well duh!)
Java 7u21 - must include Trusted-Library to avoid warning
Java 7u25 - must include Trusted-Library to avoid warning
Java 7u40 - must include Trusted-Library to avoid warning
Java 7u45
So the long and short is we have a dilemma; to have no warning on 7u21, 7u25 and 7u40 you must include Trusted-Library:true, and to have no warning on 7u45 you must omit this property.
Thanks Oracle for a Kobayashi Maru - we love you.
I'm finding now that some of my users still get this "mixed signed and unsigned code" warning (due to LiveConnect calls in the web page to the applet) even though I've set Caller-Allowable-Codebase correctly, and the difference between those that get it and those that don't get it is whether they have applet .jar file caching enabled in the client host. Those that allow Java to keep temporary files on the client (i.e., allow applet .jar files to be cached) get the warning, and those that turned caching off (because applet caching has never worked quite right) don't get the warning. Go figure.
Without using Trusted-Library and setting:
Application-Library-Allowable-Codebase: *
Caller-Allowable-Codebase: *
Doesn't work for me, and i still see the warning.
Update: Tried also with http://... but didn't work either.
Update2: Seems even worse. I didnt update 7u40 (to 7u45) but Java console (full debug) shows the "LiveConnect 1.7.45" text. After that, my Javascript->Java calls are blocked.
Update 3: I noticed my warning shows Application and Publisher = UNKNOWN. Altought i have:
Application-Name: MyApplet
Implementation-Vendor: MyCompany
I tried using JDK7u45 instead of JDK7u5 i was using.
To disable this "Security Warning" popup and other related popups using the Java 8 Update 45 JRE.
Trusted-Library: true
Caller-Allowable-Codebase: *.mycompany.com
Note: security warning popup was not disabled with wildcards * and *.com.
We had this problem too - we were building with 1.4.2, on the theory that clients might not have an updated JRE plugin. Despite putting in the new manifest attributes, we still got the popup warnings in the 1.7_u45 JRE. We rebuilt with 1.6, and the warnings went away.
EDIT: As it turns out, our app was doing something different if the file was in a different directory -- specifically, it wasn't attempting to access the applet signed jar manifests. So the fact that the file was in a different directory was irrelevant. So the below information is not accurate. I've decided to detail the real reason for the warning in a new question: As of Java 7 update 45, one can no longer lookup manifest information without triggering a warning?
Unfortunately, the workaround given by Oracle and others here for getting around the update 45 problem does NOT work if your app needs to access files in a different directory than where the app is being run from.
With my web start app, everything worked fine and dandy with the "Trusted-Library" attribute that needed to be added for 7u21. With 7u45, removing the "Trusted-Library" attribute and adding in all the additional attributes talked about in the other answers will NOT work -- I will get the same warning that you would get if you were running 7u21 without the Trusted-Library attribute (stating the application contains both signed and unsigned code).
It took me FOREVER to figure this out, because for very inexplicable reasons Oracle has decided not to print out ANY indication of what the "unsigned" code is in its console, even when running at maximum tracing (level 5). But basically, our app needs access to a configuration file which can be used by the user to configure application properties (for example, the logging level of our app). This configuration file is a plain old text file. And we store the config file in a directory co-located to where the app runs from: ..\config\app.properties. We access this file as a part of the main jar's init routine. It is here where the warning occurs.
The workaround here? Move app.properties into the same directory where the app is running from (and change the reference in the jar to just "app.properties"). Voila, it works -- no more warnings (as long as using the aforementioned codebase attributes). What the hell Oracle???
Unfortunately, because our app allows customized config files on a per-user basis, it is not as simple for us to just put the config file in the app's startup directory -- since that is NOT customized on a per-user basis, we would only be able to allow one user per machine to use the app simultaneously.
I've been looking over Java's manifest documentation to see if there is some way I can make the config file directory "safe" such that loading up of this file doesn't cause the warning. The only thing I can think of is either being able to use the Class-Path attribute or a combination of the Extension attributes (http://docs.oracle.com/javase/7/docs/technotes/guides/plugin/developer_guide/extensions.html), however these all seem designed around the purpose of jars, not just regular files...
Any ideas? And since Oracle intends to fix the Trusted-Library issue anyway, is coming up with a (potentially) grandiose workaround-solution around this even worth the effort? Grrr....
I found some strange thing with MANIFEST.MF file in scope of last Java security issue with new attribute "Caller-Allowable-Codebase".
I had some issues, why this new attribute wasn't helpful for me and started investigation
(Attention!: it may be related only to my local computer configuration - because I had never seen such troubles over stackoverlow).
Manifest file had been upgraded according to new security feature:
Manifest-Version: 1.0
Application-Library-Allowable-Codebase: *
Caller-Allowable-Codebase: *
and *.jar was build, but without signing.
So, then I unpacked my *.jar file and looked in folder META-INF in MANIFEST.MF, where source manifest.mf should be generated.
And I was embarrassed by absence of last line, it looked this:
Manifest-Version: 1.0
Application-Library-Allowable-Codebase: *
I tested this behavior several times and found out, that last line always was exchanged to the whitespace.
So, if it will be helpfull for someone, just append in the end of MANIFEST.MF file some unmeaningful attribute, like Codebase: *, which will be cutted during *.jar build.
if you make a Manifest patch file remember to live an empty line in the end, otherwise it won´t work.
For example you can make a patch like:
Permissions: all-permissions
Codebase: *
Application-Library-Allowable-Codebase: *
Caller-Allowable-Codebase: *
But you need to add an empty line (in the example 5 lines instead of four!)
And then add it to the manifest:
jar uvfm jarName.jar permissions.txt
EDIT This question is not about how to solve dependencies using Ant / Maven / Gradle or whatnots.
I'm trying to use Neo4j and I'm a bit confused by the docs as to what I need to embed a very simple "Hello, world!" Neo4j example in an app.
I've read in several places that Neo4j was lightweight and that only one (and now two) jars where needed.
For example here: http://highscalability.com/neo4j-graph-database-kicks-buttox
we can read: "Small footprint. Neo4j is a single <500k jar with one dependency (the Java Transaction API)."
This is precisely one of the reason I'm interested in Neo4j to embed it...
So I downloaded the community edition (GPL) of Neo4j and read the explanation here:
http://docs.neo4j.org/chunked/stable/tutorials-java-embedded-setup.html
which says: "Extract a Neo4j download zip/tarball, and use the jar files found in the lib/ directory."
Now that's more than concise and I've found old messages saying that the "wording was changed". At one point all that Neo4j needed was one jar apparently (which is one of the reason I was interested in embedding Neo4j btw). But now apparently it's two, because there's a dependency on some Java Transaction API (which one? a .jar shipped with neo4j?)
The problem is that if I look in that lib/ dir I've got quite some things:
1115454 lib/neo4j-kernel-1.6.1.jar
153707 lib/neo4j-graph-algo-1.6.1.jar
222791 lib/neo4j-shell-1.6.1.jar
8865464 lib/scala-library-2.9.0-1.jar
43530 lib/neo4j-jmx-1.6.1.jar
590503 lib/neo4j-kernel-1.6.1-tests.jar
23954 lib/neo4j-community-1.6.1.jar
28023 lib/neo4j-udc-1.6.1.jar
1517975 lib/neo4j-cypher-1.6.1.jar
51662 lib/neo4j-graph-matching-1.6.1.jar
16030 lib/geronimo-jta_1.1_spec-1.1.1.jar
143177 lib/neo4j-lucene-index-1.6.1.jar
1466301 lib/lucene-core-3.5.0.jar
118875 lib/server-api-1.6.1.jar
92850 lib/org.apache.servicemix.bundles.jline-0.9.94_1.jar
And in system/lib:
27461 system/lib/blueprints-neo4j-graph-1.1.jar
72650 system/lib/jettison-1.3.jar
628626 system/lib/rrd4j-2.0.7.jar
17985 system/lib/asm-analysis-3.2.jar
177174 system/lib/jetty-util-6.1.25.jar
109043 system/lib/commons-io-1.4.jar
755981 system/lib/neo4j-server-1.6.1.jar
35910 system/lib/gremlin-java-1.4.jar
46367 system/lib/jsr311-api-1.1.1.jar
36551 system/lib/asm-util-3.2.jar
206035 system/lib/commons-beanutils-core-1.8.0.jar
227122 system/lib/jackson-core-asl-1.8.3.jar
33094 system/lib/asm-commons-3.2.jar
17308 system/lib/jcl-over-slf4j-1.6.1.jar
21878 system/lib/asm-tree-3.2.jar
12359 system/lib/log4j-over-slf4j-1.6.1.jar
.
. (skipped a few jars from system/lib here)
.
If my Emacs-fu is strong enough the jars above weight at nearly 17 MB (not that "embeddable")... And I didn't even paste all the jars from system/lib/.
So what is the minimum number of .jar (and which are they) do I need so that I can embed Neo4j and run a simple "Hello, world!" example?
I'm confused by the official doc saying: "... use the jar files found in the lib/ directory".
Surely I don't need all of them right?
Basically, you need only neo4j-kernel-1.6.1.jar (and the mentioned transaction API geronimo-jta_1.1_spec).
However, this will give you only the basic functionality. If you want to use other parts, like indexing, querying, management tools, etc., you would need other jars.
The absolute minimum to run the kernel is
neo4j-kernel.jar
jta.jar
The rest is Cypher, Lucene indexing and other stuff.
I am working with development of an application which, among other pieces of code, contains a number of servlets. The development environment I use is Eclipse (3.2.1, which is rather old) in which I run a Tomcat server (5.5.23, rather old as well) using the Eclipse Tomcat Wrapper plug-in for the task. All this runs on a RedHat 5.2 Linux system.
The Java runtime I use is JDK 1.6.0(21), which I upgraded to (from a previous JDK 1.5 version) quite recently and as far as I can recall, the software combination above (together with the application I'm working with) did actually work: I could start the Tomcat server, it got up without errors or complaints and the application's servlets were available on port 8080.
However, something has changed somewhere (could be in the application jarfiles themselves, I'm suspicious of essentially everything on the host to be the root cause of this). Now, when I try to start up the Tomcat server, I get the error sun.misc.InvalidJarIndexException in the console output. This happens for the following classes and methods:
org.apache.commons.modeler.Registry registerComponent (happens 3 times)
org.apache.catalina.core.StandardServer initialize (happens once)
org.apache.catalina.connector.Connector start (happens twice)
I did find this stack overflow question regarding how to find the JAR of a Java Class useful and I did run find /usr -name \*name-of-suspected-jar\*.jar a few times to track down a number of suggested offending JARS. I also tried to check the runtime configuration of the Tomcat server in Eclipse, but could really not match the JAR files on the system with the CLASSPATH of neither the Tomcat runtime setup (or with the CLASSPATH used in the environment when starting Eclipse). That effort probably requires some more rigor on my part but before doing that (and that is why I right now don't post all the gory details regarding CLASSPATHs here), I did a read up on exactly what InvalidJarIndexException really is about.
So, JAR files may contain an optional INDEX.LIST file which contains information about what classes (and methods?) to find in the JAR file. The idea is to short-circuit the search throughout all JARS in the CLASSPATH which is useful in a number of circumstances. Problem is when the INDEX.LIST file happens to be corrupt (or, is believed to be corrupt), that causes the loading of the class to be completely given up (the class loader does not fall back to searching all JARs in the CLASSPATH) and the error InvalidJarIndexException to be thrown. To make things more messy, the order in which JARs are searched might affect how the class loader treats the INDEX.LIST file: the INDEX.LIST file of one JAR might refer to other JARS and if those referred to JARS are not in sync with the first JAR's INDEX.LIST file, the class loader fails with this InvalidJarIndexException error.
So (according to this StackOverflow question), it seems like this error can be thrown not only because a JAR file has a corrupt INDEX.LIST, it seems it can even be thrown on a JAR even if the JAR has a valid INDEX.LIST or legitimately is lacking a INDEX.LIST simply because a previously searched JAR has confused the class loader. (To put in another way, as things are, this exception might be thrown even for "innocent" non-corrupted JAR files due to offenders elsewhere on the system).
So, after writing a mere novel, here comes my main set of questions:
What is the best way to track down the precise .jar file for which each InvalidJarIndexException is thrown?
What is the best way check if a randomly picked .jar file has an INDEX.LIST file and if so, if said file is valid (that is, non-corrupt)? What tools exist for this task?
Is there an efficient way to automatically deduce the search order of .jar files? I can try to follow the CLASSPATH manually but to be honest, that is error prone and tedious.
Is there an efficient way to figure out what .jar file there is in a search order which might confuse the class loader to accuse innocent, non-corrupt .jar files later in the search to have incorrect INDEX.LIST files?
Disclaimer: I know I run old versions software (even if I have the latest updates of my Redhat 5.2 installed though) and I know a knee-jerk reaction for many people is to suggest that I don't put any effort whatsoever in debugging this but instead upgrade to a more recent version of Tomcat, Eclipse and Linux (Java is recent though). The reason I would prefer not to is that after looking into things, I've found it rather messy to do an upgrade or to try to install a separate modern Tomcat or Eclipse next to the RHEL5.2 provided Tomcat/Eclipse I use today. Also, I consider this kind of troubleshooting an opportunity to learn some useful nitty gritty details about Java and it's associated tools and features. Figuring out how the class loading works and what causes it to throw this InvalidJarIndexException on my system would be very educating!
(But if this troubleshooting fails, I'll seriously consider to use a modern Linux, Eclipse and Tomcat... I promise)
Take the following steps to diagnose the problem:
Add an exception breakpoint in Eclipse (it's the J with an
exclamation mark icon), and set it to halt for caught and uncaught
exceptions, of type InvalidJarIndexException.
Start debugging your program.
Eclipse will halt at your exception breakpoint, when the InvalidJarIndexException is thrown. Even without the source for URLClassPath, you will still be able to inspect the variables on the stack leading to the exception, including the name of the class that URLClassPath is attempting to locate. Knowing the name of the class should significantly narrow the list of JAR's you need to examine.
Perhaps you've locally added a new class to a package and the contents of that package are described by the index file in a stale JAR on your classpath?
Try Tattletale which is a good reporting tool for jars. What I have done in this case was to eliminate INDEX.LIST from jars one by one until I did not get InvalidJarIndexException any more