Weld, Tomcat: missing "beans.xml" in META-INF - java

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).

Related

Tomcat6 refuses to recognize the classes in WEB-INF/classes folder

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

JBoss 6 unpacks jars from WEB-INF/lib of war

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...

Installing Solr onto a hosted tomcat server

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).

Can Jetty pick up changes to WEB-INF/lib on hot deployment? How?

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

Some Tomcat webapps not opening

I downloaded a couple of webapps and placed them in my /webapps folder.
Some of them I could open by going to http://localhost:8080/app1 and it would open.
However, some others I would do the exact same thing and go to http://localhost:8080/app2 and it will display "HTTP Status 404 - /app2/", even though I am sure it is there. I've checked that it contains a WEB-INF folder just like app1, and I've even restarted Tomcat to be sure.
My question is: is there anything (perhaps in the web.xml file) that specifies what the URL has to be to start the webapp? Or is it simply just http://localhost:8080/<folder name> ?
P.S. If you want to know exactly what app1 and app2 I am refering to:
app1 (works) = http://assets.devx.com/sourcecode/11237.zip
app2 (doesn't work) = http://www.laliluna.de/download/eclipse-spring-jdbc-tutorial.zip
I've tried a few others as well, some work, some don't. I'm just wondering if I'm missing something.
I usually debug this by going the the manager page and making sure that all of the contexts are deployed (http://localhost:8080/manager/html).
It sounds like app2 has not been deployed properly or is not starting up because of some other error.
I would look at the logs. There may be a bunch of information in there but usually it explains what is broken.
The second app (the directory named WebRoot) can also be deployed correctly but you get a 404 by going to it because there is not an "index.jsp" or "index.html" file in the root directory.
Try putting a file there with any of those names, and the 404 is gone.
A servlet mapping in the web.xml is not strictly necessary for this to work.
The first zip file you mention has a .war file as part of the zip. The second one is just the source code and it needs to be built into a .war file.
It looks like it is setup to have that done in Eclipse. Try the File>>Export option and select War file as the export type.
The second requires the spring framework. The only runnable things I could find were a client in eclipse-spring-jdbc-tutorial.zip\SpringJdbc\src\test\de\laliluna\library\TestClient.java and one in eclipse-spring-jdbc-tutorial.zip\SpringJdbc\src\de\laliluna\library\sample\MyApplication.java. If you open it in eclipse (it is an eclipse project), and compile, provided the Spring framework is installed, you should be able to run both.
Are you familiar with log4j? Spring puts a lot of often-useful information into the logs created via log4j. When I have a SpringMVC application that won't startup correctly or otherwise isn't running I check my log4j and potentially turn up the Spring log level to INFO or even DEBUG.
If "/" is not accessible it means that there is no "index.html", "index.jsp" or whatever is defined in the welcome-files list of the web.xml
Also no Servlet-Mapping for the context ROOT directory is present.
Check the web.xml for Servlet-Mappings or try to figure out the name of the jsp/html /... file being in the context root

Categories

Resources