When deploying an EJb jar as part of the EAR, i understand that the runtime jar dependencies of the EJb (i.e log4j) need to be specified in the EJB jar's MANIFEST.MF. But why is this? If I put the log4j in the same directory as the ejb jar, then it should automatically be included in the runtime classpath, no?
Why do i need to specify the log4j in the MANIFEST.MF again? On the same vein, what jars are automatically available to my EJB jar at runtime without having to specify them in MANIFEST? Just the jars shipped with websphere?
You don't have to specify dependencies in manifest starting with Java EE 5. The location of libraries can be specified through <library-directory> element in application.xml. It defaults to lib.
Java EE 5 is supported by WAS 7.0 and higher.
Related
I created one jar file and in that i have class files, .classpath file, .project file In sample on github, i see apiproxy, callout and lib folder. when i deploy it, i getting error that traffic can't flow , i get error like traffic.How to upload dependencies jar in lib folder However when i upload my main jar file in resources folder, i don't see any lib folder for dependencies jars. Should i place all jars in one resources folder. in my .classpath file, i can see all lib jars like message-flow-1.0.0.jar, expressions-1.0.0.jar and itextpdf-5.5.6.jar. However in documentation, its given to deploy by maven but i don't know maven, from UI how should i create lib folder and upload jars there.
Okay, in my understanding of your point.
You can upload jar file into apigee from Scripts > import file > in file type choose "JAR" > select jar file from your work space > and finally, define your jar name and then use policy Java Callout to call your jar.
If you have to modified your jar and want to deploy it, delete your existing jar in apigee and upload the new jar by following 1. In case of new jar has the same name of existing jar, you do not need to do anything with Java Callout policy. But the new jar has the different name, don't forget to modified Java Callout for refer to your new jar.
Please create the single jar file which contains jars like message-flow-1.0.0.jar, expressions-1.0.0.jar and itextpdf-5.5.6.jar. As per the apigee doc in create a Java Callout policy and make sure you have mentioned the package name & class name in Java Callout Poliy
<ClassName>package.ClassName</ClassName
<ResourceURL>java://SingleJar.jar</ResourceURL>
In the hope of finding the solution on Google as it seems a very general task, I've been trying to do this past few weeks but strangely I couldn't find anything!
What I'm doing:
I am writing an small application, It will be at most a 20KB JAR file in the end. However it has many dependencies, Hibernate and SLF4J to name a few. Directly including these dependencies with the jar file will make it 9Mb.
What is used:
Gradle is used as the build tool. the custom task fatJar creates the jar including all required dependency jar files from (the original) maven repository.
The problem
with my slow internet connection I'd rather not to directly include dependencies, but download these them on the server and not my local production site. What would be the Gradle task like to:
Read the dependencies from jar file
Download them (I know how to do it during Gradle build task).
Add them to class path
Add classpath defined in MANIFEST.mf too
run the jar, by main class defined in MANIFEST.mf
I've read gradle documentation over and over, but no help.
I am using sbt-osgi to repackage some library dependencies into OSGi packages, and that works well, until I started using scalajs as well. The library dependencies are defined as normal projects something like this:
lazy val bonecp = OsgiProject("com.jolbox.bonecp", buddyPolicy = Some("global")) settings
(libraryDependencies += "com.jolbox" % "bonecp" % "0.8.0-rc1")
The OsgiProject function has default OSGi settings plus some implicits for determining what path the project has. When the bundle task is run on these projects, a new jar with OSGi stuff is created based on the OSGiProject settings. This project just rebundles the bonecp library as an OSGi jar and has no sources. The problem here is that since there's no source, theres no files in target/scala-2.11. This causes sbt-osgi to spit out a ton of ignorable errors, but scalajs is not as forgiving and refuses to do anything with these projects. Is there any good way to unpack the downloaded libraryDependency jars into target/scala-<scalaVersion>?
In the manifest file for an eclipse plugin its possible to add jar files and
folders to the classpath (on the Runtime tab).
In the root of my plugin I have a folder lib containing a-1.0.1.jar, b-1.0.0-SNAPSHOT.jar. But only when I select each jar separately:
Bundle-ClassPath: .,
lib/a-1.0.1.jar,
lib/b-1.0.0-SNAPSHOT.jar
...can they be used inside my project. Why is it not possible to add them to the classpath by adding the common root folder only:
Bundle-ClassPath: .,
lib/
?
No, you can't. Eclipse is based on OSGi, which is the platform providing MANIFEST.MF support to build plugins.
When you set values under Bundle-ClassPath, OSGi search into each one to find class files. So you can put folders containing Java packages and class files. When you put a jar file, it is uncompressed in memory and viewed by OSGi as a regular folder, still searching for class files.
Unfortunately, there is no way to load all jar from a folder. No wildcard mechanism or something like that is allowed here.
I created simple Java Servlet: WelcomeServlet.java.
Than, I tried compile this file via:
javac WelcomeServlet.java
In result I see compile error:
package javax.servlet doesn't exit
I try find solution for this error with Google. And I find first part of answer: java compiler doesnt see servlet-api.jar file.
I know, that Apache Tomcat in it lib folder contains servlet-api.jar file.
So, I have this file, but where I must copy this file??
I try different folders:
echo %JAVA_HOME%
C:\Program Files\Java\jdk1.6.0_26
%PATH% contains this line: C:\Program Files\Java\jdk1.6.0_26\bin
So, I copy in:
%JAVA_HOME%\bin
%JAVA_HOME%\lib
%JAVA_HOME%\jre\lib
And in result same error.
And only after I copy servlet-api.jar in directory:
%JAVA_HOME%\jre\lib\ext
compilation complite sucessful.
My question: Why? Why I must copy in folder %JAVA_HOME%\jre\lib\ext ??
Where This moment describe in documentation?
And other question we have some official docs or specifications that describe folder structure for jdk folder??
You'll need to specify the directory or directories you want the compiler to search by using the -classpath command line option when running javac. The reason the compiler found your .jar in %JAVA_HOME%\jre\lib\ext is because it searches the extension directories by default.
This is for Java 1.5, but I believe it is more or less still correct:
http://docs.oracle.com/javase/1.5.0/docs/tooldocs/findingclasses.html
The link Shaun provides is a more complete answer. But in short, using the classpath is the best way to introduce 3rd party or external (to the JDK/JRE) libraries. The classpath is a concept much like the %PATH% or the $PATH variables, but specifies locations for java to use for lookup rather than the shell to use for lookup of executables.
The classpath provides the java compiler or java virtual machine a list of items to use when searching for resources. This "path" may include directories or files. It will typically include jar files and sometimes locations of configuration files. Many Java based lookup schemes for files configuration or otherwise use some variant of what is accomplished by [Class#getResourceAsStream()][1]'s use of walking the Classpath.
I have rarely seen an incident where putting a jar file in the lib/ext location was preferred to utilizing the Classpath.
The classpath is typically an environment variable (%CLASSPATH% or $CLASSPATH) or specified on the command line when running java or javac (e.g. -cp or -classpath see the help from the executable you are running).
Build tools such as Ant and Maven will also provide abstractions to defining the list of jars to be utilized by your applications and are highly recommended to be used for any length of repetitive change code, build, test, run cycles.