In my spring web app, I'm using logback.
I want to put all log files to application's root folder, i.e.
{MyApplicationFolderPath}/output/logs
where {MyApplicationFolderPath}, depending on the platform of server, may be placed anywhere.
I have this definition in the logback.xml:
<property name="LOG_HOME" value="../output/logs" />
But when I am on a windows platform, I can't find where the folder goes to. In java code, I would use something like:
{someClass}.getClass().getClassLoader().getResource("").getPath()
But I don't know how to do this in the logback.xml.
If you are using just /output/logs then it must be printing logs under C:/output/logs (C -> Drive Letter).
If you are on Linux and want the Logs to be printed inside your Project Directory then you can change it to ../output/logs instead.
If you are on Windows then you can provide the absolute path to your base directory or do something like ./output/logs/MyLogs.log. Latter should create the output/logs/ directory under your Project Directory at src level.
I've found other questions using Python and app.yaml, but I'm working in Java using Eclipse. I've tried every permutation I could possibly think of including forward slashes, backslashes, opening with dots. I've tried putting the image itself in the root directory of the project. I've found similar questions on here, but they usually referenced an app.yaml. I know this should be very simple, but nothing I've tried has worked. I'm sure that I'm missing something in a configuration file somewhere. This is the first App Engine app I've tried, so I'm still feeling my way around it.
This tag:
<img src="images/CTT_placeholder.png" />
Yields this warning:
Jun 03, 2014 12:53:13 PM om.google.appengine.tools.development.LocalResourceFileServlet doGet
WARNING: No file found for: /images/CTT_placeholder.png
The images folder is in the root of the project.
You need to create images directory in the war directory of your project
/war/images
and put your images there. Then your tag will work:
<img src="images/CTT_placeholder.png" />
I recently set up my build server (Jenkins) to generate Javadocs for Ant builds. However, no matter what I do, I can't get it to include links to external libraries. When I attempt to use an online link, Ant returns:
[javadoc] javadoc: warning - Error fetching URL: http://docs.oracle.com/javase/6/docs/api/package-list
When I use an offline link and reference a local copy of a package list, it gives no warnings, but doesn't generate links either. This occurs for every library I attempt to link, not just Java SE. Here are the respective lines for links in my build.xml:
<link offline="true" href="http://docs.oracle.com/javase/6/docs/api/" packagelistLoc="javadoc/javase6/package-list" />
and:
<link href="http://docs.oracle.com/javase/6/docs/api/" />
It's worth mentioning that the internet connection of the server doesn't have a particularly unusual configuration. After a bit of research, I found that the warning I received is common when using a proxy, but I couldn't find any cases where it was returned on a server with a direct connection.
I'd also like to mention that I've verified that my offline package list is in the proper location and accessible via a relative path from the build file.
Edit #1: This is apparently an issue on Maven as well, suggesting that the Javadoc tool itself is broken.
Edit #2: It's worth mentioning that I'm using JDK 1.6 update 45 to compile.
<link offline="true" href="http://docs.oracle.com/javase/6/docs/api/"
packagelistLoc="javadoc/javase6/package-list" />
should be:
<link offline="true" href="http://docs.oracle.com/javase/6/docs/api/"
packagelistLoc="javadoc/javase6/" />
packagelistLoc is a path to directory containing package-list file.
It works fine, but for clarity, you need to download the package-list file from the Oracle website first, e.g. http://docs.oracle.com/javase/6/docs/api/package-list, and save that file to the folder you specified.
I have been working on a Java web application using wicket framework on Netbeans 7.2 and out of a sudden I encountered this problem. I tried cleaning the build-impl.xml then restarting the IDE and I should say I have fairly low knowledge on this. Can someone please tell me why it is giving an error and how I can fix that?
The lines 1024, 1025 and 1026 are :
<target if="netbeans.home" name="-run-deploy-nb">
<nbdeploy clientUrlPart="${client.urlPart}" debugmode="false" forceRedeploy="${forceRedeploy}"/>
</target>
The error message says :
nbproject/build-impl.xml:1025: The module has not been deployed.
See the server log for details.
BUILD FAILED (total time: 4 seconds)
I came up with a solution by myself, I cloned the project and changed the project's directory name back to original, that worked fine for me. But it seems to have a better and proper solution, though.
/* START BY RESTARTING YOUR GLASSFISH SERVER */
1-add DBMS(ex:oracle,MySQL,MsSQL..) jdbc connector jar to domain
"glassfish directory/domain/{yourDomain}/lib"
2-add connection pool in glassfish server "JDBC-->ConnectionPool"
3-add your JNDI "JDBC-->jdbc ressource"
4-Test connection
5-add additional properties
IF YOU HAVE NO PASSWORD ON YOUR DATABASE ACCOUNT YOU CAN EASILY
6- glassfish/config/domain.xml change password value to "" in your jdbc-connection-pool
may its so late but the response useful for others so : Sometimes, when you don't specify a server or servlet container at the creation of the project, NetBeans fails to create a context.xml file.
In your project under Web Pages, create a folder called META-INF.
Do this by right mouse button clicking on Web pages, and select:
New->Other->Other->File Folder
Name the folder META-INF. Case is important, even on Windows.
Create a file called context.xml in the META-INF folder.
Do this by right mouse button clicking on the new META-INF folder, and select:
New->Other->XML->XML Document
Name it context (NetBeans adds the .xml) Select Well-formed Document Press Finish
Edit the new document (context.xml), and add the following:
<?xml version="1.0" encoding="UTF-8"?>
<Context antiJARLocking="true" path="/app-name"/>
Replace app-name with the name of your application.
Now your in-place deployment should work. If not, make sure that the file can be read by everyone.
The context.xml file is specific to Tomcat. For more information about that file, see the Tomcat documentation at tomcat.apache.org.
In Java, you often see a META-INF folder containing some meta files. What is the purpose of this folder and what can I put there?
From the official JAR File Specification (link goes to the Java 7 version, but the text hasn't changed since at least v1.3):
The META-INF directory
The following files/directories in the META-INF directory are recognized and interpreted by the Java 2 Platform to configure applications, extensions, class loaders and services:
MANIFEST.MF
The manifest file that is used to define extension and package related data.
INDEX.LIST
This file is generated by the new "-i" option of the jar tool, which contains location information for packages defined in an application or extension. It is part of the JarIndex implementation and used by class loaders to speed up their class loading process.
x.SF
The signature file for the JAR file. 'x' stands for the base file name.
x.DSA
The signature block file associated with the signature file with the same base file name. This file stores the digital signature of the corresponding signature file.
services/
This directory stores all the service provider configuration files.
New since Java 9 implementing JEP 238 are multi-release JARs. One will see a sub folder versions. This is a feature which allows to package classes which are meant for different Java version in one jar.
Generally speaking, you should not put anything into META-INF yourself. Instead, you should rely upon whatever you use to package up your JAR. This is one of the areas where I think Ant really excels: specifying JAR file manifest attributes. It's very easy to say something like:
<jar ...>
<manifest>
<attribute name="Main-Class" value="MyApplication"/>
</manifest>
</jar>
At least, I think that's easy... :-)
The point is that META-INF should be considered an internal Java meta directory. Don't mess with it! Any files you want to include with your JAR should be placed in some other sub-directory or at the root of the JAR itself.
I've noticed that some Java libraries have started using META-INF as a directory in which to include configuration files that should be packaged and included in the CLASSPATH along with JARs. For example, Spring allows you to import XML Files that are on the classpath using:
<import resource="classpath:/META-INF/cxf/cxf.xml" />
<import resource="classpath:/META-INF/cxf/cxf-extensions-*.xml" />
In this example, I'm quoting straight out of the Apache CXF User Guide. On a project I worked on in which we had to allow multiple levels of configuration via Spring, we followed this convention and put our configuration files in META-INF.
When I reflect on this decision, I don't know what exactly would be wrong with simply including the configuration files in a specific Java package, rather than in META-INF. But it seems to be an emerging de facto standard; either that, or an emerging anti-pattern :-)
The META-INF folder is the home for the MANIFEST.MF file. This file contains meta data about the contents of the JAR. For example, there is an entry called Main-Class that specifies the name of the Java class with the static main() for executable JAR files.
META-INF in Maven
In Maven the META-INF folder is understood because of the Standard Directory Layout, which by name convention package your project resources within JARs: any directories or files placed within the ${basedir}/src/main/resources directory are packaged into your JAR with the exact same structure starting at the base of the JAR.
The Folder ${basedir}/src/main/resources/META-INF usually contains .properties files while in the jar contains a generated MANIFEST.MF, pom.properties, the pom.xml, among other files. Also frameworks like Spring use classpath:/META-INF/resources/ to serve web resources.
For more information see How do I add resources to my Maven Project.
You can also place static resources in there.
In example:
META-INF/resources/button.jpg
and get them in web3.0-container via
http://localhost/myapp/button.jpg
> Read more
The /META-INF/MANIFEST.MF has a special meaning:
If you run a jar using java -jar myjar.jar org.myserver.MyMainClass you can move the main class definition into the jar so you can shrink the call into java -jar myjar.jar.
You can define Metainformations to packages if you use java.lang.Package.getPackage("org.myserver").getImplementationTitle().
You can reference digital certificates you like to use in Applet/Webstart mode.
Adding to the information here, the META-INF is a special folder which the ClassLoader treats differently from other folders in the jar.
Elements nested inside the META-INF folder are not mixed with the elements outside of it.
Think of it like another root. From the Enumerator<URL> ClassLoader#getSystemResources(String path) method et al perspective:
When the given path starts with "META-INF", the method searches for resources that are nested inside the META-INF folders of all the jars in the class path.
When the given path doesn't start with "META-INF", the method searches for resources in all the other folders (outside the META-INF) of all the jars and directories in the class path.
If you know about another folder name that the getSystemResources method treats specially, please comment about it.
Just to add to the information here, in case of a WAR file, the META-INF/MANIFEST.MF file provides the developer a facility to initiate a deploy time check by the container which ensures that the container can find all the classes your application depends on. This ensures that in case you missed a JAR, you don't have to wait till your application blows at runtime to realize that it's missing.
I have been thinking about this issue recently. There really doesn't seem to be any restriction on use of META-INF. There are certain strictures, of course, about the necessity of putting the manifest there, but there don't appear to be any prohibitions about putting other stuff there.
Why is this the case?
The cxf case may be legit. Here's another place where this non-standard is recommended to get around a nasty bug in JBoss-ws that prevents server-side validation against the schema of a wsdl.
http://community.jboss.org/message/570377#570377
But there really don't seem to be any standards, any thou-shalt-nots. Usually these things are very rigorously defined, but for some reason, it seems there are no standards here. Odd. It seems like META-INF has become a catchall place for any needed configuration that can't easily be handled some other way.
If you're using JPA1, you might have to drop a persistence.xml file in there which specifies the name of a persistence-unit you might want to use. A persistence-unit provides a convenient way of specifying a set of metadata files, and classes, and jars that contain all classes to be persisted in a grouping.
import javax.persistence.EntityManagerFactory;
import javax.persistence.Persistence;
// ...
EntityManagerFactory emf =
Persistence.createEntityManagerFactory(persistenceUnitName);
See more here:
http://www.datanucleus.org/products/datanucleus/jpa/emf.html
All answers are correct. Meta-inf has many purposes. In addition, here is an example about using tomcat container.
Go to
Tomcat Doc and check
" Standard Implementation > copyXML " attribute.
Description is below.
Set to true if you want a context XML descriptor embedded inside the application (located at /META-INF/context.xml) to be copied to the owning Host's xmlBase when the application is deployed. On subsequent starts, the copied context XML descriptor will be used in preference to any context XML descriptor embedded inside the application even if the descriptor embedded inside the application is more recent. The flag's value defaults to false. Note if the deployXML attribute of the owning Host is false or if the copyXML attribute of the owning Host is true, this attribute will have no effect.
You have MANIFEST.MF file inside your META-INF folder. You can define optional or external dependencies that you must have access to.
Example:
Consider you have deployed your app and your container(at run time) found out that your app requires a newer version of a library which is not inside lib folder, in that case if you have defined the optional newer version in MANIFEST.MF then your app will refer to dependency from there (and will not crash).
Source: Head First Jsp & Servlet
As an addition the META-INF folder is now also used for multi-release jars. This is a feature which allows to package classes which are meant for different Java version in one jar, e.g. include a class for Java 11 with new features offered by Java 11 in a jar also working for Java 8, where a different class for Java 8 with less features in contained. E.g this can be useful if a newer Java version is offering enhanced, different or new API methods which would not work in earlier version due to API violations. One will see a sub folder versions then.