I have a third party application which has lot of servlets and jsp. I wanted to debug that by putting breakpoints on my local jboss server. How do I know that, for a particular request, the request is being processed by particular java classes and jsp, so that I can put breakpoints in the right files? I am thinking of going through the code, before setting the breakpoints, to know where to put them. But I feel this is not an efficient way to do it (as it is a very big application). Can you please suggest if there is any better way to do this?
Thanks in advance.
The web.xml file contains servlet-mapping elements indicating which servlets are mapped to which URLs. So if you know the URL, you should easily find the corresponding servlet. Now you can read the servlet code to see which other classes are involved.
I think fastest way for debugging applications like this, is profiling application for specific usecase, in this way you can understand which classes used for this scenario and after finding classes, you can debug these classes.
for profiling application there are lots of tools.
commercial: Yourkit, JProfiler, JProbe
open source:VisualVM, Javacalltracer (create run-time sequence diagram)
Related
Specifically, if we have an original .war file deployed in a application server, can one deploy a .war which provides different implementations of classes in the original file without having to modify the base code to support this?
Edit. I've formulated the problem wrongly, it's actually simpler I think. We want to expose actions from two distinct WARs in the same base path, rather than a different path for each WAR. Can it be done at the container configuration level?, or do you recommend employing something like URL rewriting?
Not easily. Generally, a deployed WAR becomes a discrete webapp within a Java EE server, and it gets its own classloader. Your second deployment will get another classloader, and although they will definitely share some ancestry, it won't be possible to reimplement things from the other WAR - your second deployment won't be able to 'see' it, because of the way the classloaders are chained together.
It is possible to rewrite running classes using a Java agent, although this is nontrivial. You can transform (rewrite incoming) classes and you should be able to rewrite live (instantiated) classes, although the problem there is that there may be objects on the heap using the old and new code.
Class rewriting is how Eclipse's Hot Code Replace works, and also how JRebel's fast redployment solution functions.
You might be able to use an AOP system like AspectJ if you really want to pursue this - but it sounds like you're trying to solve a build or deploy problem, rather than a problem where AOP would be a more fitting solution.
I have started using tomcat 7 for few days. I have tried executing many JAVA BASED web application with it. I actually want to check the flow of the java based web applications. That means in which sequence the methods of web application get executed. To do this I profile tomcat server with java profiler.
My profiler works like this:
I deploy war file of an application into web Apps dir of tomcat.
I start the server by ./startup.sh
I access the application in browser and execute it.
I stop the server by ./shutdown.sh.
and after I stop the server, the profiler dumps the output in xml format(it shows heirarchy of methods as calling context tree).(MY profiler basically profiles methods of java classes.)
As you know, may be because Tomcat is based on servlet, for 2 exactly same runs of an application(I follow above 4 steps 2 times and have 2 different output for 2 same runs), profiler gives different outputs. Q.1) I dont exactly know why this happens would be very curious to know the reason behind it.
Also the output is very large (around 200 MB) even for simple application. To limit the size of the output and to have same outputs for 2 exactly same runs, I have excluded methods of org.apache.* from profiling. Because I am ultimately interested in knowing the flow of the web application itself.(to know in which sequence methods of web application get executed). For this scenario I have following questions.
Q.2) Running application by deploying war file and running it by fetching it form the directory itself can make difference in the output of the profiler ? or can it affect a sequence of methods in which they execute in both the cases ?
Q.3) I would like to know what happens when I execute jsp page of an application ? I mean how does tomcat execute them? step wise please....
Q.4) when I check the output of the profiler after executing an application, I see large no of methods from org/eclipse/jdt/internal/... get executed. So what do this classes do actually ? Why do I have them in my output ?
Please let me know if I have failed to explain my questions. I kiind of searched a lot but could not find very precise answers to my questions.
I would really appreciate your responses..
Thanks you.
I strongly recommend to read a bit about tomcat works. In short
Q.2 Shouldn't make any difference.
Q.3 JSPs are compiled to servlet classes when they get called. If there is no Servlet class for the JSP tomcat makes one. If there is a corresponding servlet class, tomcat looks which one is younger, the JSP or the servlet. If the JSP is younger it does a new compilation, if not it uses the servlet.
Q.1 Not sure. Could be a multithreading/timing thing, Maybe it's the way your profiler works.
Q.4 Not sure. Could a be classes from the profiler or libraries used by your servlet code?
EDIT: For Q.4 look at Ian Roberts' comment to the question.
What profiler do you use? How about going stepwise through the code by debugging it?
before asking, please understand that my english is not good.
I'm using Class.forName(...) class in a servlet programming. when I access the servlet, I get a row of detailed controller information from Database indicating which controller to use.
This is Class.forName(...) I coded:
Class c = Class.forName(row.getControllerInfo);
c.newInstance();
This works fine, but there's a problem, i'm using Eclipse. The problem is that when I modified the Controller file, the changed contents were not applied to the server.,,.
Probably the easiest way is not to support dynamic loading. Much better to achieve something like dynamic update by supporting multiple servers. For development, you could get around redeploy delays by using JRebel (there might be others).
If you really do want dynamic loading of classes then the answer is "class loaders". I suggest having a look at those, and come back with any specific questions.
If I understood your problem true,
When you change any file of your project, you must deploy your project to server. If you use server from eclipse, republish may solve your problem.
have you tried clean - re-built and then deploying your application?
I'm playing with a GWT/GAE project which will have three different "pages", although it is not really pages in a GWT sense. The top views (one for each page) will have completely different layouts, but some of the widgets will be shared.
One of the pages is the main page which is loaded by the default url (http://www.site.com), but the other two needs additional URL information to differentiate the page type. They also need a name parameter, (like http://www.site.com/project/project-name. There are at least two solutions to this that I'm aware of.
Use GWT history mechanism and let page type and parameters (such as project name) be part of the history token.
Use servlets with url-mapping patterns (like /project/*)
The first choice might seem obvious at first, but it has several drawbacks. First, a user should be able to easily remember and type URL directly to a project. It is hard to produce a human friendly URL with history tokens. Second, I'm using gwt-presenter and this approach would mean that we need to support subplaces in one token, which I'd rather avoid. Third, a user will typically stay at one page, so it makes more sense that the page information is part of the "static" URL.
Using servlets solves all these problems, but also creates other ones.
So my first questions is, what is the best solution here?
If I would go for the servlet solution, new questions pop up.
It might make sense to split the GWT app into three separate modules, each with an entry point. Each servlet that is mapped to a certain page would then simply forward the request to the GWT module that handles that page. Since a user typically stays at one page, the browser only needs to load the js for that page. Based on what I've read, this solution is not really recommended.
I could also stick with one module, but then GWT needs to find out which page it should display. It could either query the server or parse the URL itself.
If I stick with one GWT module, I need to keep the page information stored on server side. Naturally I thought about sessions, but I'm not sure if its a good idea to mix page information with user data. A session usually lives between user login and logout, but in this case it would need different behavior. Would it be bad practise to handle this via sessions?
The one GWT module + servlet solution also leads to another problem. If a user goes from a project page to the main page, how will GWT know that this has happened? The app will not be reloaded, so it will be treated as a simple state change. It seems rather ineffecient to have to check page info for every state change.
Anyone care to guide me out of the foggy darkness that surrounds me? :-)
I'd go with History tokens. It's the standard way of handling such situations. I don't understand though, what you mean by "It is hard to produce a human friendly URL with history tokens" - they seem pretty human friendly to me :) And if you use servlets for handling urls, I think that would cause the whole page to be reloaded - something which I think you'd rather want to avoid.
Second, I'm using gwt-presenter and
this approach would mean that we need
to support subplaces in one token,
which I'd rather avoid.
If you are not satisfied with gwt-presenter (like I was :)), roll out your own classes to help with MVP - it's really easy (you can start from scratch or modify the gwt-presenter classes) and you'll get a solution suited to your needs. I did precisely that, because gwt-presenter seemed to "complicated"/complex to me - to generic, when all I needed was a subset of what it offered (or try to offer).
As for the multiple modules idea - it's a good one, but I'd recommend using Code Splitting - this type of situation (pages/apps that can be divided into "standalone" modules/blocks) is just what it's meant to be used for, plus you bootstrap your application only once, so no extra code downloaded when switching between pages. Plus, it should be easier to share state that way (via event bus, for example).
Based on what you have posted I presume you come from building websites using a server side framework: JSP, JSF, Wicket, PHP or similar. GWT is not the solution for building page-based navigational websites, like you would with the aforementioned frameworks. With GWT, you load a webapp in the browser and stay there. Handle user events, talk with the server and update widgets; using gwt-presenter is a good thing here as you are forced to think about separation of controller logic and view state.
You can really exploit all features of GWT to build a high-performance app-in-the-browser, but it is definately not meant for building websites (using hyperlinked pages that transfer request parameters via the server session).
This is by far the most widely asked question about GWT here # StackOverflow :)
"How do I define pages and navigation between them in GWT?" Short answer: "You don't."
Use Wicket instead, it runs on the App Engine just fine and enables you to define page bookmarks and all stuff you mentioned above. Look here: http://stronglytypedblog.blogspot.com/2009/04/wicket-on-google-app-engine.html
In our web apps the first load of some pages takes a small but noticeable extra about of time due to class loading. Does anyone have any clever ways of preloading web app classes in the JVM on start up?
Update: What we do now is store a bunch (700) of full class names in a db table. We read the table at startup and do Class.forName(). It works fine but I thought there might be a more clever approach. We determined the 700 classes that were referenced at startup by using a profiler.
Well, it's not very clever as it's part of the specification, but you can have your servlets be started when the Web App is started by adding the load-on-startup element to the servlet definition in web.xml:
<servlet>
<description>....</description>
<display-name>....</display-name>
<servlet-name>....</servlet-name>
<servlet-class>....t</servlet-class>
<load-on-startup>1</load-on-startup>
</servlet>
If you do this for a representative set of services -- or perhaps just one servlet that can preload everything needed -- then you'll achieve your goal.
If this isn't sufficient, if you want to load classes from JAR files, for example, without actually initializing them in a meaningful way, and if you know where your JAR files are or can figure out where your JAR files are, then you can use something like the code at this JCP forum post "List classes in package" or some of the later posts in that thread. From the list of classes, you can get the Class objects, which will help load the classes without actually having to instantiate an instance.
You might try writing static initializer code in a single dummy class and then load that class at startup. Its static initializer would create a few key objects that cause other classes to be loaded (and you could do this recursively to improve code modularity). I'd bet this is much shorter and simpler (and you have no DB issues to worry about).
A better approach probably is to write a servlet that on startup hits a few of your slow-loading pages and throws away the results. This forces class loads. Loading these pages many times each will increase the amount just-in-time compilation done (both speeding up your code and getting JIT compilation costs out of the way). There are other advantages too: this is a "power-on self-test", it causes one-time startup tasks to be done, and it may also prime various caches to some noticable degree.
Class.forName() is about the only thing I can think of. I'd certainly be interested in hearing more clever alternatives.
Another option would be to select a set of URLs and run a script on startup to hit those URLs.
The Class.forName inside of a thread would potentially speed things up. Start with the ones that are on the first page likely to be hit.
Threading it should make the startup quicker (it'll return earlier) and since you start loading the more likely classes first they will hopefully be loaded by the time the page gets hit. For the others same deal, hopefully loaded before the page gets hit.
You could also take it further and start a thread for each group of classes (those classes needed on a given page would be a group). Which might speed things up since you could parallelize the reading from disk (but that might also slow it down).
This doesn't grantee that things won't slow down on the first load of a page, but it is worth investigating.
You could always use a third party jsp compiler, such as Jasper, to precompile your JSP pages before you deploy them.
May be you can try converting the 700 classes to a jar file and apply some methods for preloading,probably by putting the jar in boot class path (I am not sure if it works ..but just giving a hint ).