when I start JBoss 6 I see that it unpacks all jar files from WEB-INF/lib in tmp/vfs/automountXXX folder. E.g. jackrabbit-server.war contains library asm-3.1.jar, then in tmp folder I see the following folders with files:
asm-3.1.jar-83dc35ead0d41d41/asm-3.1.jar
asm-3.1.jar-2a48f1c13ec7f25d/contents/"unpacked asm-3.1.jar"
it does not take files from my.ear/lib only WEB-INF/lib... Why is it so? And is here any way to prevent it doing so? It just slows down application server starting (and stopping), what is not that comfortable at development... btw. repacking war to ear structure that way, gave me the same working application and saved 1 minute while application server starts... 1 minute is good enough... I hope there is simpler way, wihtout repacking in development mode.
If it is somehow related to JavaEE 6 specification and ejb-jars, which can be located now in WEB-INF/lib, so I don't have such libraries in my war files...
UPDATE: actually when I repack jackrabbit-server.war to jackrabbit-server.ear which contains jackrabbit-server.war and moved all its libraries to jackrabbit-server.ear/lib then I still see two folders in tmp:
asm-3.1.jar-215a36131ebb088e/asm-3.1.jar
asm-3.1.jar-14695f157664f00/contents/
but in this case last folder is empty. So it still creates two folders, but does not unpack my library.
Also I use exploded deployment so the question is only about jar files, not unpacking ear/war.
It will be unpacking EARs also, just not in the same place. You'll have to hunt around to find where they get unpacked, but they are there.
It does this for performance reasons. If it didn't, then classloading would be extremely slow, since it would have to recurse through nested ZIP files looking for what it needs.
So you may feel that the unpacking slows you down, but it's actually making things faster.
According to discussion on JBoss AS Forum it can be a bug. And there is no workaround to fix/avoid/configure it now.
The only idea I got was to repack my applications: inside EAR I moved libraries from WEB-INF\lib of WAR to EAR\lib (only struts was left in WAR, otherwise it won't work), and another WAR application I made as EAR and all its libraries I could move to EAR\lib. In development mode I can easy use this structure, and it saves me 2+ minutes to boot application server and that's a lot... Now JBoss takes 1:50 minutes to start, in comparing to 4 minutes before...
Related
I know many similar questions have already been asked (ex. this, this, etc.), but none of them could help me, so I decided to bring it up again - been struggling for hours and I've really run out of ideas.
I have a Java EE project, whith simple servlet that accepts data from HTML form, performs a few queries in external services (with REST and JAX-RS) and returns results. My goal now is to deploy it on standalone Tomcat server. The way I'm trying to achieve it is by exporting WAR artifact and copying it to Tomcat's webapps directory.
It works up to the moment of sending REST request with JAX-RS - then I always get the error:
WELD-ENV-000016: Missing beans.xml file in META-INF
I'm not using this file at all, but as I read, it must be there, even if empty... so I've tried to put it at any location I could think of/read about, including:
/web/META-INF
/web/WEB-INF
/src/main/webapp/META-INF
/src/main/webapp/WEB-INF
/src/main/resources/META-INF
/src/main/resources/WEB-INF
When I check the output .war file or directories created by Tomcat after deployment, beans.xml is present in both META-INF and WEB-INF directories.
Initializing Weld and performing those queries works well in unit tests inside Intellij IDE - the only requirement here was to mark directory containing WEB-INF and META-INF as "Resources Root".
In my facet configuration, I mark directory containing WEB-INF and META-INF as "Web Resource Directory", and *'Web' facet resources' is included in my artifact.
Any ideas? Am I fundamentally misunderstanding something, does this inner Weld here require different, separate META-INF or something?
As nobody answered, I'll at least share my conclusion - the simplest way is to switch to TomEE (if that is acceptable).
I'm working with a dynamic web project in Eclipse and I'm planning on a Java JAX-RS RESTful back-end with a JavaScript single-page app front-end using a framework of the Angular/Durandal/Aurelia flavor. With that said, the typical way to deploy in the Java world is to bundle things up as a WAR file - which is essentially a JAR file. The trouble is, including the node_modules blows up the size of the WAR file considerably. On the other hand, I can execute 'npm install' after deployment. However, on my development machine, where I'm constantly deploying, that will take too much time. I would prefer if I can prepare the install directory on the web server with the 'npm install' modules and then deploy the WAR file on top of it. The trouble is, it seems the WAR file deployment enjoys wiping out folders if they are not contained in the WAR file.
I'm using GlassFish 4.1 application server. The ideal solution for me would be a way to 'cloak' directory in the WAR file by modifying the MANIFEST.MF file such that when it is expanded the cloaked directories are not overwritten. This would be the most parsimonious solution to my problem. However, I know of no cloaking manifest entries for JAR/WAR file manifest.
There may also be creative solutions arrived at using the 'npm link' command. Any suggestions are welcome.
Perhaps this, among other reasons, speaks to why once people gets started with npm on the client-side they start looking at node and express on the server-side. However, I'm not convinced they can't play nice together and I would like to keep the option of all the old school open source Java libraries at my disposal.
I know this question is almost two years old, but perhaps someone will still need an answer.
Put simply, you need to bundle your JavaScript. You should never be wrapping up your node_modules folder in a war, or even deploying it as-is to the server. Mainly because of exactly the issue you were having. It's... not the smallest.
In front-end development, you're expected to use a tool like webpack to gather up all your JS files into a single app.js file. This process will only take the actual files you directly require or import in your own JavaScript (and the files that those files require, etc), leaving out all the rest. Most importantly for this discussion, leaving out all your devDependencies!
Webpack will also bundle up files other than js. Importing your css files will tell webpack to also bundle those up, creating an app.css file alongside your app.js (though you will need to use an appropriate loader to tell Webpack what it means to import 'main.css').
Getting started is a fairly straightforward matter of adding a config file to your project, adding a new devDependency, and figuring out how to get your Java-based build tool to trigger the bundler. The frontend-maven-plugin, for instance, or the gradle-node-plugin.
These days, webpack and its ilk are even smarter. If your node_modules contains ES6 native modules, bundlers can perform tree-shaking on these files to only bundle the exports that are actually imported. This reduces the bundle size even more.
They can also pull out parts of the bundle into a separate file in order to create, say, a vendor.js file that contains the code for Angular, jQuery, etc. Or you can tell the bundler to treat those imports as external, meaning that they are assumed to have been included elsewhere in the web app. But this is all getting into more advanced features than you need at first. Just give webpack's getting started guide a go, see the difference it immediately makes to your war size, and go from there.
If you are using a nodejs build tool like Grunt (but probably not), then it's likely the devDependencies that's taking up so much space. If so, just copy your runtime dependencies out of node_modules.
If not: you don't have to deploy a .war; you can also deploy an 'exploded' directory. You could copy only changed files and touch .reload
Plus to mentioned above tools to pack NPM resources, let me also mention JNPM: https://github.com/OrienteerBAP/JNPM
It provides maven plugin (jnpm-maven-plugin) to download, filter and pack required NPM packages into your JAR/WAR. So in you case you should publish your client code as NPM package and then pack it into your WAR through this plugin.
Instead of using a certain jar in my WEB-INF/lib folder, I want to use its source code (same directory structure and everything) in my WEB-INF/classes folder, so that I may be able to modify its classes more story.
Yet (re)starting my tomcat after deleting the original jar and uploading the corresponding directory into WEB-INF/classes gives me the following error:
SEVERE: Error configuring application listener of class no.something.something1.http.LifecycleListener
java.lang.ClassNotFoundException: no.something.something1.http.LifecycleListener
I am certain that the directory path is the same as the one inside the jar. Also, I have previously tried using classes in my WEB-INF folder for this web application, and tomcat has also been unable to load them, for some reason.
Does anyone know how I go about troubleshooting this error?
Tomcat can only load .class files, it doesn't know what to do with raw source code files. Tomcat doesn't do hot loading of .class files like that anyway. You would have to restart the application or server after you recompiled them either way, packaging them as a .war isn't that much of a burden either way once you automate it.
If you take the time to automate the build and deployment of a proper .war you can just rebuild the .war and it will automagically undeploy and redeploy the application itself, which is many times faster than restarting the entire server.
You can't do what you are trying to do the way you are trying to do it. Tools like JRebel address these issues, but I don't find them as useful as their marketing makes them sound.
You could use embedded tomcat (or embedded jetty) to map directory structure of the application as you like. It probably will require some tinkering if you need some JNDI resources within your application but still worth the trouble.
Here's an example
I have installed and configured tomcat+solr on my personal linux machine and windows as well. I was able to get them working fine. I'm very new to Java and how the file structure works. (i.e. knowing where to put war files and what WEB-INF is) So now that I am ready to install solr and configure it on my clients shared hosting plan, the directions are different from what I did before. I dont want to mess this up and apparently the webserver reboots daily and I dont think I can do it manually which means I have one shot at this every day.
Here is the directions for installing a tomcat servlet on his hosting provider:
http://www.apluskb.com/scripts/Where_do_I_put_my_answer1186.html
As you can see I need to install solr under the html/WEB-INF directory, but read what it says.. its very confusing:
"All Servlets should be uploaded in the /html/WEB-INF/classes directory. Any unpacked custom classes and resources should be uploaded in the /html/WEB-INF/classes directory, while classes and resources packed in Jar files should be uploaded to /html/WEB-INF/lib."
uhh... so which is it? /classes? or /lib? I dont think they explain that very well and I'm a little confused by this statement. Also what exactly do I install? With a normal solr install, solr is put somewhere else, the war file is copied into tomcat and the rest of solr is referenced using some kind of XML configuration file.
Also, since I'm a little new to Java and servlets, can someone explain the tomcat file structure to me (in great detail will definitely get you a +1 from me) and where things should go and why?
Thanks in advance!
Web application structure is defined by J2EE spec, it's not limited (or specific) to Tomcat per se. Here is a detailed tutorial covering its layout. Briefly, however, it's as follows:
There a base (root, home, whatever you want to call it) folder which serves as root of web application, everything else goes under it.
All public stuff (html, images, CSS, javascript, JSP, what have you) goes under that folder (directly or via subfolders).
There's one special folder, also located directly under root, called WEB-INF. It contains non-public stuff, like application descriptor (web.xml), classes (which go into WEB-INF/classes folder), libraries (WEB-INF/lib) and possibly configuration files.
Application can be deployed either using expanded structure above or as WAR (web archive) which is basically an archive containing everything above starting at root folder level (but not including root).
The distinction between classes and lib folders is simple: all packaged libraries (JAR files) need to go into lib; all unpackaged classes (and resource files that need to be in classpath) have to go into classes preserving their directory structure (e.g. com.mypackage.Blah class should go into classes/com/mypackage/)
In your case, it looks like you can only have one web application deployed and it has to be deployed to /html folder. If you're deploying a war file, you need to extract it to that directory (e.g. from within that /html folder run jar xvf solr.war or whatever it's called).
I am running several webapps on Jetty 6 through Apache. They are set to hot deploy using .xml files in the contexts/ directory. Those .xml files simply define WebAppContext instances and tell them where to look for a WAR file. `touch'-ing their contexts/.xml files picks up changes to JSPs defined in the relavnt WAR file, which is great.
The problem is that changes to the JARs contained in the WAR file's WEB-INF/lib folder are not picked up. I assume that this is because these JARs are cached somewhere. That assumption is based on the fact that restarting Jetty picks up the changes.
So, the question is: Is it possible to turn off this caching behavior or in some other way get WebAppContext instances to pick up library changes? If so, how?
JBoss hot deploy scanning doesn't check the lib folder:
http://community.jboss.org/wiki/HotDeployLibDirectory
Not sure if Jetty has the same behaviour, but, you could try moving one of your jars into the same folder as one of your jsps to see if this is the case.
If that's not an option then this might help:
http://www.jroller.com/larrywilliams/entry/jetty_hot_deploy
You need to set the scanInterval property to a number larger than zero.
See more here