I am curious about following error :
Publishing to JBoss 7.1 runtime server - MyEAP has encountered problem
Error renaming C:\(some path) to (MyEAR proj path)\(my war file)\META-INF\MANIFEST.MF
you can change these settings in server etc...
I have created a simple EAR project along with a dynamic web project with stuts2. I am deploying EAR file and everything is working fine but whenever I make changes to any file and save I get this error message. What is the exact meaning of this message?
Thanks
Maybe the problem to be that it is necessary to configure a scanner for external deployments.
See: 'Publishing to JBoss 7.1 Runtime Server...' has encountered a problem
In previous versions of JBossAS, there was an exposed JMX server with
an option to mark a folder as one that the deployment scanner should
look at. This option still exists in AS7, but, we haven't integrated
with the management ability yet. THis means we can't do it on the fly,
currently, in the current toolset is a bit hurt by this missing
feature.
It is still possible in the raw configuration of the server, howerver.
This means you can mark your server directly to scan some external folder by modifying
your configuration and adding a deployment scanner. The instructions for it are over here:
https://community.jboss.org/wiki/DeployingAnApplicationFromAnExternalDeploymentLocation
To make use of this, double-click your jboss-7 server inside eclipse
to open the server editor. You can then switch over to the second
page, "Deployments", where you can change the deployment method to
"custom" and set any folder that's on the same filesystem as your
eclipse installation. Once this is done, you can add that folder to
your server's deployment scanner lists as per the wiki above.
Related
I suppose same problem as described in question MSAL for Java quickstart sample app throws exception. When using IDE and deploying to embedded tomcat, app works. After spending one day, I figured out what is the problem.
Application AuthPageController specifies #RequestMapping("/msal4jsample/secure/aad"). This works with embedded tomcat. When deployed to tomcat server, tomcat removes application name from path since it is deployment information and exploded folder name depends on war file name. Same application can be deployed multiple times to different folders. Tomcat maps url as /secure/aad and request in this case is never handled. To fix problem, I created array of request mappings #RequestMapping(value = {"/msal4jsample/secure/aad", "/secure/aad"}).
I forked MS Azure repository and made changes. Please take a look at zdenko-s/ms-identity-java-webapp
There are other fixes too.
War file name is specified in pom.xml, no need to rename it. Removed rename step from documentation also
.gitignore wrongly specifies exclude target. Should be */target
Sharing info. Fix in my forked branch
I am unable to find another article that solves my problem but am happy to hear about one if you know the answer.
I have a RESTful service built in Java with Eclipse. It uses Spring and all of its bells and whistles.
After much work with configuration files, I am able to build the service into a war file, deploy it to my Tomcat webapps folder, and run it from standalone Tomcat. However, it still throws several errors on start when I try to start it from a service defined within Eclipse. The errors are the same errors that I was seeing before I got the config files correct for standalone Tomcat. The errors are about the inability to create the required beans because of references to properties that can't be found.
How did I get it running in Tomcat? I added a couple of .properties files to define properties needed by the beans that get launched at startup and then added a 'set CLASSPATH=...' line to the setenv.bat file in the Tomcat bin folder. This new line adds the properties files into the CLASSPATH. That seems to have fixed everything from standalone Tomcat.
So, my question is, "How do I make these same changes inside my Eclipse server?" I have added the properties folder with the property files under the config folder in Eclipse, just like it is in my native Tomcat folders, but I do not know how to modify the CLASSPATH string to specifically point to my .properties files (as I have done in the setenv.bat file for standalone Tomcat).
I think I understand the problem, but have no idea about the solution.
Thanks for listening.
Dave
Eclipse does not use any *.sh/*.bat files to startup Tomcat. In order to modify the way the server is started you have to open the configuration UI of the server by double-clicking on the server in the Servers view.
From there you will be able to modify the classpath of the system classloader through "Open launch configuration".
Another important setting is "Server path" which tells Eclipse, the value of $CATALINA_BASE. You can modify it only after removing all modules and cleaning the server. It is useful to set it to an easily accessible directory: this way you can verify directly that Eclipse didn't mess up your application deployment (sometimes it "forgets" to copy some libraries).
The "Configuration path" setting tells Eclipse where to find the files (but not subdirectories) that will be copied into $CATALINA_BASE/conf.
Remark: if your application requires you to add libraries to the top classloader, there is probably a problem in your project. The "missing" libraries should be added to WEB-INF/lib of your application instead: look into the "Deployment assembly" of your Eclipse project configuration.
I am using Jenkins (v1.4.87) and have the deploy plugin (v1.10) to create a job that deploys a built war file into tomcat 6.
The deployment is running successfully, the war is being deployed ok.
Here is the plugin configuration part of the job:
(I have not included the real server details for obvious reasons)
The problem is that somewhere along the way, the application context file is renamed to appname.xml.bak and left in that state. Therefore the application fails to start because tomcat cannot find the context file it expects for the application any longer.
To remedy this I have to log into the server where the context file is located and rename the backup back to its original file name appname.xml.
It feels like the deploy plugin may be getting to a point where it should handle this. I would expect it to either make a copy of the context file called appname.xml.bak or rename the backup back to the correct file name.
I cannot find any documentation that lists out the phases that the plugin goes through so I cannot confirm if this behavior is expected or not. I am left with the only option to download the plugin code from Github and figure it out myself.
Have I missed something obvious maybe?
UPDATED:
I have since updated to Jenkins v2.32.3 and I have the same issue with the deploy plugin. Any help would be great thanks.
I am new to web applications in java and need a bit of help with this. I have a multi module project set up in eclipse, which also contains WEB-INF/lib directory of the WAR.
In the non-web version i can debug though it fine however when i deploy it to weblogic i am encountering errors which i dont get on my local workspace, so i'm trying to deploy it using tomcat. I installed tomcat and deployed the war file onto it. I see a blank page (which is normal - essentially the application has a listener, i send it a jms message and that kicks off the process afterwards) but i dont know how to put a break point so i can step though the code - line by line - if this is possible?. Would appreciate some references / reading material.
I am using Tomcat 6.x and Eclipse J2EE Kepler. For reasons mentioned in my other question, I sometimes need to delete the Tomcat from the Servers list and re-add it.
The weird thing is: after I re-add the server, two configuration files server.xml and context.xml revert to a previous state! let's call it S. I cannot really tell what S is - it definitely is a state I once had, but it lacks some newer changes. For this reason my webapp does not work and I have to revert these two files in the workspace/Servers folder.
I'd love to fix this by updating S. However, I am unable to find the source of S, where Eclipse takes it from - I tried fulltext-searching my computer for files that look like the server.xml and context.xml, but to no avail. Specifically, I updated these two files in the conf/ folder of my Tomcat installation, but it did not help.
Where could Eclipse be keeping S? In some weird DB in the workspace metadata? Could it be using the local history?...
Thanks for any insights!
If you are working on Eclipse then there should be a folder called Servers in your workspace. When you start your server for the first time, it copies over the tomcat conf files into this eclipse project. So no matter if you change your actual context.xml from outside, eclipse will override it with what is stored in the 'Servers' folder.
If you still need the eclipse to take control of your tomcat installation directory, you need to primarily update this file from within the eclipse.