I am using ActiveMQ 5.16.0 downloaded from Apache. I see a few of the jars are older versions which have vulnerabilities, e.g.:
com.google.guava_guava 19.0
core_jackson-databind 2.9.10.4
shiro-core 1.5.3
log4j-1.2.17
I see all above vulnerable jars are located under apache-activemq-5.16.0\lib\optional\. What is use of jars under the optional directory? Is there any latest release of ActiveMQ which has all latest dependencies?
Optional dependencies are just that: Optional.
Using Shiro in your case as reference.
Optional Dependencies: Typically an optional dependency is not required for the core functionality of the library you are referencing. In this case, Shiro is only required if you intend to make use of Apache Shiro features or functionality. Shiro is used for security and therefore makes sense that it will not be used by everyone making use of ActiveMQ.
Versions: Many times (not always) optional dependency versions are not set in stone and it may be possible to use newer versions without breaking the functionality. This is not always the case, so if you aim to do this, start with the preferred version and only upgrade after the functionality is working to test.
Vulnerabilities: Simply because a vulnerability exists, does not make it applicable to your use case. Just because there is a known vulnerability in a dependency that can do XYZ, it will likely not affect you if your use case does not make use of XYZ. A security report such as the Apache Shiro one could help in understanding this.
Additionally: I would suggest that you look into Maven or Gradle for your Java projects. This will take away some of the need to worry about these types of dependency management issues as optional dependecies are not included in the dependecy hierarchy by default.
Related
Trying to figure out how will the JVM decide which dependency to use:
We have a gradle compiled fatJar, containing several dependencies, i.e. Jackson X version etc.
My app is a Play framework 1.x app, using the the fatJar artifact from stage 1, and other dependencies, including aws java sdk which uses Jackson itself, newer than X version.
How can I tell which Jackson version is used in runtime?
[It seems that on 1 env it uses the correct one, and on the other, aws sdk is using the incorrect Jackson]
In simple case when you provide classpath to java and do not use any classloader the answer is simple. It will search classpath in order you provide.
I strongly discourage you from relying on that behavior.
There is solutions for you problem. One of them to use OSGi it allows to use multiple version of libraries, but i must mention that it is heavy framework.
I am relatively new to Maven and the JVM and am curious how Spring's approach to releases actually works? What is a BOM?
For example, the Spring Cloud page says Use your dependency management tools to control the version. If you are using Maven remember that the first version declared wins, so declare the BOMs in order, with the first one usually being the most recent (e.g. if you want to use Spring Boot 1.3.6 with Brixton.RELEASE, put the Boot BOM first).
Can someone give an example of what this means in practice?
You detected the Maven concept of Dependency Management. The Maven documentation illustrates that concept quite well. You will also find information anbout the Bill Of Materials (BOM) in the Maven documentation.
In short a BOM defines dependencies (with versions) and projects that import this BOM will get the version information for the atrifacts they depend on from the BOM. Thus a BOM can ensure that a set of dependencies is used with versions that are "compatible" with each other.
I'm building a library that uses Spring 4.2.4 and am planning to bundle Spring with the library, to make a self sufficient jar with all dependencies included because some of my clients don't use Maven.
However, some of the clients using the library could be using a different version of Spring already in their applications, some as old as Spring 2.5. In this case, they would exclude the bundled version of Spring. Then how do I handle feature compatibility issues? For example, Spring 4 can have multiple PropertySources, and this is not supported in earlier versions.
Only if you really need to, you can bundle the libraries you want in your library and alter their packages to make sure that no collision or class loader conflicts happens in scenarios such as what you describe happens. If Maven is your build system, you could use the Shade plugin to accomplish this. Such an approach is taken in such popular libraries as Jersey 2 where the guava library classes are included in the distribution with modified package name.
I'm a student with quite some experience in Java but totally new to Maven.
I was trying to implement a RESTful service provider and client with jersey-server and jersey-client. Both also depends on jersey-json, to make use of automatic conversion between POJO and JSON. Both of them also depend on a service model I implemented myself, where the POJO definition resides.
However, the code doesn't work for me. I spent quite a few hours looking for solutions everywhere on the Internet. It turns out the reason of the failure is that I accidentally specified version of jersey-server and jersey-client as 1.14, but jersey-json as 1.9.1.
The server doesn't work at the beginning, but at some point suddenly starts working. (I have no idea how this happened.) The client never worked until I change jersey-json version to 1.14.
Why do I need to have the same version for these different dependencies?
Because one depends on the other or otherwise has a compatibility issue. This is what dependency management is all about. Run mvn dependency:tree to see exactly how these libraries relate to each other.
In this case, it seems Jersey libraries are all released together as a "bundle" - and you need to use the versions from those bundles together. See: http://jersey.java.net/nonav/documentation/latest/chapter_deps.html
Note that this is an attribute of the Jersey libraries, not Maven.
Often different jars from the same distribution are tested together and given the same version number.
If you try to mix different versions it might work, or it might not, as its not a combination which was intended or tested.
Why would you want to declare JAXB as a dependency of your Java application since it's anyway shipped with the JRE and cannot be overriden in your applications classpath?
Using the jersey-json as an example, in their POM file they declare a dependency to jaxb-impl without specifying the exact version even. What are they gaining by doing this?
And also, when I add a dependency to jersey-json in my own POM file, I end up having jaxb-api.jar and jaxb-impl.jar in my classpath. Why would I want this to happen? Isn't the default JVM implementation anyway getting loaded if I don't put the files to the endorsed libraries directory?
I'm seeing in the linked pom:
<dependency>
<groupId>com.sun.xml.bind</groupId>
<artifactId>jaxb-impl</artifactId>
</dependency>
But there is also a parent pom, so you might want to follow that trail up, to see if an actual version and/or scope was specified there (and propagated down).
But if it isn't, then I'm guessing the Jersey team felt that the JAXB 2 API is mature enough to allow them to specify a loose dependency on the JAXB implementation.
The JRE ships with a specific implementation of the JAXB impl, which was equivalent to JAXB RI 2.1.7 for the longest time. But at the same time, there is a mechanism to easily swap out for another implementation of your choice, in your apps.
Sure you can use the built-in JRE JAXB implementation, and if it works for your app, you surely should try.
Nonetheless, some reasons that could lead you to want a separate JAXB implementation include : a left-over bug (addressed in a newer release); need a newer JAXB API such as JAXB 2.2.x (which comes in more recent version of the JRE); want to use a different implementation altogether (because it happens to have a better API and/or performance for your particular usage), etc...
So back to your jersey question, I'm guessing again that they wanted to give developers the flexibility to pull in their JAXB impl of choice. I'd think they have some level of recommendations somewhere in their guides.
However, the fact that the JAXB RI is specifically marked as a dependency, undercuts the argument.
That sound like the jersey people defined their dependency wrong. If a dependency is provided by the environment where you run it should be defined with the scope "provided".