I'm working on a Java EE project made by someone else. They put this project in a VM and I can access to it to run the app. But the problem is that I can't find all the files of the project. Indeed, the project is using the model-view-controller and I find only the .jsp files (view). The app uses JBoss, Tomcat, Maven and Catalina. I have to start JBoss and Tomcat and then, in localhost, the app is running. So it works. I'm asking myself if there is a place defined by one of those technologies where I can find the other files. Because, they should be on the VM because the project is running well.
Can someone know if there is a global repertory for those files ?
Your VM will most likely contain only a runtime environment for the web application, consisting of a JBoss installation (including Tomcat) and the deployed application (in webapps folder), typically as a decompressed (exploded) WAR. See Deployment for an in-depth description of the web application's structure.
If you plan on modifying the application, the runtime environment will not help you much, because it typically does not contain the Java sources, but only their class files. You will instead need a development environment, consisting of your favourite IDE and the web application project, checked out from some revision control system (CVS, SVN, Git etc.) at best. This is the place where you can write/change code and JSPs and eventually build a WAR (e.g. using Maven) for deployment in the runtime environment.
Seems to me you should rather look for your files in a development environment.
Related
Some facts about the application:
It consists of several modules, one of which is a GWT client module
Spring 3
GWT 2.6.1 (+ compatible GXT)
Is packaged as .war and can be deployed to a standalone Tomcat
Chrome add-on does not work anymore, so until recently I had to rely on Eclipse + embedded Jetty + Firefox 24 to be able to launch the app in DevMode and debug it
The other day I decided to try to launch it in IntelliJ IDEA and see if the debugging would work there.
Observations after deploying the app via a local Tomcat configuration in IntelliJ:
The app is deployed just fine (wither using war or exploded war artifact). Basically, Intellij takes the work directory from the standalone Tomcat installation and moves it into its installation folder (eg. .IntelliJIdea2019.1/system/Tomcat/Unnamed_MYAPP). Config files get also copied to the config dir.
The webapps dir of Tomcat stays within the original Tomcat installation and the app is deployed there
At first I thought the breakpoints are not recognized at all. However, it turned out that I was testing breaking only within the GWT client module; when I later tried some other module - the execution stopped as expected.
Now, what's interesting is that when I would develop and debug with Jetty, if I made a change to the GWT client-module, I could simply reload the page and it would appear.
With Intellij and Tomcat, it's the opposite. Breakpoints do not work as mentioned, but also refreshing, eg. via Update classes (instead of full redeployment) does not work, whereas for the other module it does.
Is there a way to somehow adjust my artifact so that GWT module as well can be debugged?
My exploded war artifact looks like this:
< output root >
META-INF
MANIFEST.MF
WEB-INF
classes
GWT module compile output
lib
web.xml
webapp directory contents
GWT client module GWT compiler output
Actually, it was a silly situation - I was expecting the execution to stop at the breakpoints set in the Java code of the gwt-aware module -- but since it was already transpiled to Javascript -- that was impossible.
The only way for breakpoints to stop in such a module is to use the DevMode.
We are using STS 3.4 to develop Spring portlets for Liferay 6.1.2. When we deploy the project onto the server by droping that on the server view, the deployment never gets completed.
It says the deployment is complete and portlets are ready to use but it again reinitiates the deployment process.
Any idea why this endless deployment loop is happening?
I'm not sure if STS is aware of Liferay's additional deployment process (or if you need/use it): Liferay typically processes a WAR file before actual deployment to tomcat, thus you should drop your WAR file to Liferay's deploy folder. This might add some libraries from Liferay itself (depending on your configuration in liferay-*.xml files or some other necessities that I don't remember.
Especially if you use Liferay's Plugins SDK (you don't state if you do or if you don't). If you indeed use it, you might want to try the Ant target direct-deploy for building the WAR file: The result of this should be able to deploy directly to tomcat. I'm assuming that STS omits the Liferay deployment process (and direct-deploy would mimic it). I hope (from memory) that it was available on 6.1 already.
Can't go without the hint that you should upgrade.
We are using some library that doesn't work for some reason if the WAR is expanded under the apps folder. When the eclipse tooling publishes the WAR to a remote server, the WAR is expanded. How do I prevent the server from unzipping the published WAR?
If an app doesn't work when expanded, but the exact same app works as a binary, then that indicates something wrong in the server. I'm not aware of specific cases where we wouldn't support an expanded EAR instead of an EAR binary.
It sounds like you're this far already, but the first thing to check is if you're using resources inside of the workspace or inside of the server. You can check this by looking at the server on disk and seeing if the apps directory has either something like TestWar.war.xml or TestWar.war (directory).
To move the resources to the server, if you are using something like WDT (the Eclipse tooling you get from dragging the icon on wasdev.net into your Eclipse workspace) you can modify the Liberty server settings to do this.
In the Servers tab, double-click the WebSphere Application Server Liberty entry and you should see the Overview configuration screen. Uncheck Run applications directly from the workspace and now if you look at the server on disk you will see the files directly inside of the server.
But, to answer your question, it's not so much that we're unzipping the published WAR so much as we're not zipping it to begin with. If you right-click the EAR project and go to Export that's a one-off way to make an EAR binary, but otherwise you may want to look at a simple build description system through Ant or Gradle or Maven along with similar standards to build the archives.
I am trying to get JRebel working with a fairly large enterprise web application which uses Ant + Ivy for building/dependency management, Spring 2.0 framework and Spring MVC, and all this has to be built and deployed to Tomcat.
I have JRebel enabled on Tomcat and the Project itself. Remoting is not enabled as I assume that if Tomcat and the project are on the same machine, this is not needed. When I start the Tomcat server from within STS, JRebel appears to load fine and I see no (apparent) significant errors.
However, any changes to the project do nothing with regard to deployment, and I see no JRebel messages in the console. The project itself is a somewhat nonstandard layout and does not have the traditional WEB-INF/src structure. When I enabled JRebel on it within STS, it just dumped a rebel.xml file in the root directory.
For reference, the project is based on this codebase and has the same general structure: https://github.com/NCIP/c3pr/tree/master/codebase
While the JRebel guides are good, they only show JRebel being used with very simple projects and do not go into very much depth into exactly how the service works.
Any suggestions, resources, or ideas are greatly appreciated.
thanks
Did you actually recompile (doesn't matter if you use Eclipse or javac) those classes that you changed? It might be a good idea to check if you have "Build automatically" enabled under the "Project" menu.
They way how JRebel works is that it actually monitors the compiler output folder (usually "bin" folder or "build/classes" or something similar).
This folder (or folders) is specified in the rebel.xml file and the file must be in the classpath of your application while you run it (WEB-INF/classes or on the jar file root or in the exploded dir).
Can you make sure, that rebel.xml is actually in the applications classpath?
Also, you should see the message in the console that says something like:
"JRebel: Directory '/path/to/project/bin' will be monitored for changes.".
And also, if you see the JRebel banner in your console, it is useful to check if the license is found (if it is not found then JRebel will not work).
Sometimes there may also be some mismatch when your Eclipse compiles classes to the "bin" folder and your build scripts compile them to under "build/classes" and only one of these locations is specified in the rebel.xml file. In this case, JRebel will monitor only one of them and then it is confusing too.
Wishing the best,
Sigmar
I'm trying to build portlets for websphere in Eclipse Juno. Everything works so far, building and running the WAR files on WPS7 is ok.
But in my JSP editor I get a lot of warnings:
Can not find the tag library descriptor for "/WEB-INF/tld/portal.tld"
In my JSP file I'm using the usual taglib line:
<%#taglib uri="http://java.sun.com/portlet" prefix="portlet"%>
Now I wonder if I have to bring the actual JAR file that defines this tag into my eclipse or if there is something else that I missed.
The reason you are getting this error message has nothing to do with the taglib declaration you had quoted. The latter refers to the standard Portlet tag library (JSR-168), whereas the former has to do with WebSphere Portal's proprietary tags, needed to use WebSphere Portal-specific facilities.
I am guessing that portal.tld is referred-to by your web.xml.
When developing portlets under RAD, IBM's RAD plugins ensure that this TLD file is known to the JSP compiler, by virtue of attaching the WebSphere Portal runtime - in its entirety - to the Dynamic Web Project's classpath.
Under Eclipse Juno, this isn't done for you. You will have to find the JAR file that contains it (which might vary from one WebSphere Portal release to another) and add it to your compile-time classpath.
Having said that, you may want to consider why you need that web.xml declaration in the first place. With Portal 7.0, most of IBM's tag libraries can be referred to by their URI's, rather than having to specifically mention the TLD file.
I'm using a Portal 8 installation but the structure should be similar.
I found a jar containing portal.tld at [Portal Install root]\Portal Server\base\wp.engine.tags\shared\app\wp.engine.tags.jar
Though as a more complete solution you might want to include the whole base folder into your classpath. The server runtime RAD adds to my portlet project include lots of jars from that folder as part of the basic setup. It also includes many jars from [WAS Install root]\App Server\plugins. Since you're just using Eclipse instead of RAD (which would help manage the Portal server jars) you'll probably want to create a user library to manage all these jars.
In RAD/Eclipse, assuming you have the Portal 8 Stubs and Developer Tools installed, you can go to Project->Project Properties -> Java Build Path, to the Libraries tab, Go to Add Library -> Server Runtime , and you should see "Websphere Portal 8" or whichever version you have installed ... once that library is added your URI problems should be resolved.This essentially adds every jar file in the entire portal installation to the build path. If you do not have the stubs and development tools installed, or if you are using another IDE, you will need to add the jar files manually to the build path ....