Everytimes, I change the java coding in java class under Eclipse. I click the run-as, it requires to restart the embedded Tomcat server in order to make the change effective. How can I test the change without the need to restart the Tomcat server. Because it is very time-consuming, if I need to restart the embedded Tomcat server whenever I change some coding. It will spend one minute for testing a little change.
Thanks
What you need is a hot deploy:
Hot-deployable services are those which can be added to or removed
from the running server. It is the ability to change ON-THE-FLY what’s
currently deployed without redeploying it.
Hot deployment is VERY hot for development. The time savings realized
when your developers can simply run their build and have the new code
auto-deploy instead of build, shutdown, startup is massive.
And good news there is a hot deploy in Eclipse. Just Follow the Eclipse tutorial for this
This process is called hot swap or also hot deploy. There are tools that do this process for you. One open source tool that you can check is HotSwapAgent. One paid alternative would be JRebel.
Obviously goes without saying that these two are far from comparable in terms of features and efficiency. But if it is just for testing purposes the open source alternative is just fine. In industry, not that much(we have tried it in my company and didn't fit our expectations).
If i am not wrong there is a option to do that. I am pretty sure that you have seen that.
I've created my first Play application. Which is the most suitable deployment method for production? Should i copy the whole project to the production server and run play start? or should i make a war out of my application and deploy in tomcat / jboss? Which is the most recommended way? Getting confused with it comparing to its rails type of behavior. Note that this is supposed to be a big data application and also it may server loaded requests later on. So we are thinking of scalability, availability, performance aspects too. This application is decided to be deployed in a cloud.
Thanks.
As others have stated, using the dist command is the easiest way to deploy Play for a one-off application. However, to elaborate, I have here some other options and my experience with them:
When I have an app that I update frequently, I usually install Play on the server and perform updates through Git. Doing so, after every update, I simply run play stop (to stop the running server), sometimes I then run play clean to clear out any potentially corrupted libraries or binaries, then I run play stage to ensure all prerequisites are present and to perform compilation, and then finally play start to run the server for the updated app. It seems like a lot, but it is easy to automate via a quick bash script.
Another method is to deploy Play behind a front-end web server such as Apache, Nginx, etc. This is mostly useful if you want to perform some sort of load balancing, but not required as Play comes bundled with its own server. Docs: http://www.playframework.com/documentation/2.1.1/HTTPServer
Creating a WAR archive using the play2war plugin is another way to deploy, but I wouldn't recommend it unless you are giving it to someone who already has a major infrastructure built upon these servlet containers you mentioned (as many large companies do). Using a servlet containers adds a level of complexity that Play is supposed to remove by nature (hence the integrated server). There are no notable performance gains that I am aware of using this method over the two previously described.
Of course, there is always the play dist which creates the package for you, which you upload to your server and run play start from there. This is probably the easiest option. Docs: http://www.playframework.com/documentation/2.1.1/ProductionDist
For performance and scalability, the Netty server in Play will function very adequately to exceptional for what you require. Here's a reputable link showing Netty with the fastest performance of all frameworks and a "stock" Play app as coming in somewhere in the middle of the field, but way ahead of Rails/Django in terms of performance: http://www.techempower.com/blog/2013/04/05/frameworks-round-2/.
Don't forget, you can always change your deployment architecture down the road to run behind a front-end server as described above if you need more load balancing and such for availability. That is a trivial change with Play. I still would not recommend the WAR deployment option unless, like I said, you already have a large installed base of servlet containers in use that someone is forcing you to serve your app with.
Scalability and performance also has a lot more to do with other factors as well, such as your use of caching, the database configuration, use of concurrency (which Play is good at) and the quality of the underlying hardware or cloud platform. For instance, Instagram and Pinterest serve millions of people every day on a Python/Django stack which has mediocre performance by all popular benchmarks. They mitigate that with lots of caching and high-performing databases (which is usually the bottleneck in large applications).
At the risk of making this answer too long, I'll just add one last thing. I, too, used to fret over performance and scalability, thinking I needed the most powerful stack and configuration around to run my apps. That just isn't the case any more unless you're talking like Google or Facebook scale where every algorithm has to be finely tuned as it will be bombarded a billion times every day. Hardware (or cloud) resources are cheap but developer/sysadmin time isn't. You should consider ease of use and maintainability for deployment of your app over raw performance comparisons, even though in the case of Play the best performing deployment configuration is arguably the easiest option as well.
You don't need to use Play's console for running application, it consumes some resources and it's main goal is fast launch while development stage.
The best option is using dist command as described in the doc. Thanks to this, you don't even need to install Play on the target machine, as dist creates ready to use stand-alone application containing all required elements (also build-in server, so you don't need to deploy it with WAR in any container).
If you planning to use a cloud you should also check offers ie. from Heroku, or CloudBees, which allows you to deploy your application just by... pushing changes via git repository, which is very comfortable way, check the documentation's home, scroll down to links: Deploying to... for more details.
I've been using java + spring on tomcat for the past 2 years and my app is getting notably huge. Start up time is now almost 3 minutes and it consumes a lot of resources during the development.
So I am interested in ideas how to make developing a software fun again. I've looked at Spring DM/Gemini blueprint to make it a modular but the experience was not convenient.
Now more modules are about to be added, thinking about developing it another web application and use Spring integration for messaging. Apparently, this will be a very painful experience to develop it on one desktop computer.
Has anybody any experience with cloud development? How do I improve all these time and resource consuming tasks? Will developing in the cloud help me?
It is very common problem with typical java+spring web apps. With age they start getting bloated and Context Loading starts becoming painful. I can suggest a few pointers to mitigate the issue, but only you will be able to judge best for you depending on the what exactly goes in your app.
Don't depend heavily on server while doing development. Write Unit tests and run them outside the servlet container. Spring has excellent support for this.
Split you business logic in Rest/Soap web-services (judiciously and carefully). This gives you freedom of developing and testing the UI independent of core business logic.
If using maven/gradle, try jetty plugin. It can keep scanning for changes and reloads the webapp automatically (I think tomcat plugin can do the same). It has ability to store session between restarts, so you are not affected by restarts. Please see this for more details How can I speed up Maven and Netbeans
[Paid Option] may try JRebel.
Use CI server, that keeps on integrating/testing/deploying your app, taking some load off your developers machines.
First, take care of the bottlenecks. They have a tendency to creep into projects as they grow. The original design has been compromised again and again to meet insane deadlines and now bloat has killed a once lively application.
Do not guess at the problem but use real data to determine what is making you app slow. Use a profiler such as jProfiler: http://www.ej-technologies.com/products/jprofiler/overview.html
Next, use what you've learned to make the new modules more efficient. The bottom line is changing technology is not a fix all, as all technologies can present bottlenecks. You must find the reason behind the problem and fix that.
Once you fix the bottlenecks, you could create some test projects on a new technology to see if it is faster, easier, does what you need. But, chances are just fixing the problems on your current stack is all that is needed.
The ide used is :IBM Rational® Software Architect™ for WebSphere® Software
Version: 7.5.5.3
The app server used is Wbesphere 6.1.
I am posting this question because my server takes about 7 to 8 minutes to start.
So even if i make a small change ,i have to wait 10 minutes to test the change in my application.So is there a way where i can make changes to my java code and test them without restarting the server.
Suggestions appreciated !!!
Note:
I am not supposed to use any build tool in my environment.
There is a plugin called JRebel that let's you do changes without restarting the server.
Dynamic Code Evolution VM is open source alternative to JRebel you can try for reloading classes. It will do entire class redefinition, even reloads changes done to class hierarchy.
Theoretically reloading classes is build into the JVM, although most implementations (specifically Oracle's) only reload (hot swap) as long as you only change code inside the body of a method.
The other problem is that in Eclipse the WTP adapter has to cooperate and only deploy the changed class definition (incremental deploy). GlassFish for some reason has always been a big opponent of incremental deployments, and hence its WTP adapter restarts the server after making even the most tiny change.
JBoss used to be a proponent of incremental deployments, but after AS 7 ("everything has to be different"), they are now a follower of the "restart the server" school as well.
Yet another issue is that plain class loading is often only one part of the story. In EJB, JSF, JPA and many other frameworks classes also have to be re-registered by the framework, caches have to be cleared, etc
This all is where something like JRebel comes it. It reloads nearly all kinds of changes to classes. It also works independently from the WTP adapter thus freeing you from the whims of the server vendors regarding if restarting is hip today and lame tomorrow or exactly the other way around. JRebel also has knowledge and plugins for many frameworks.
Unfortunately JRebel is not perfect and occasionally things will just fail, but overall it works pretty well.
One other piece of advice: most modern application servers start up in a second on relative fast hardware and with a small application or a some 10 seconds for a larger app. With those and session serialization you almost don't need things like JRebel anymore.
Our company is using eclipse since several years now (we are using WTP since release 0.7)
I am currently evaluating eclipse 3.6.2 with WTP 3.2.3 which should replace eclipse 3.4.2 with WTP 3.0.4 as being our main IDE.
And I have to say that once again I am quite disappointed in concerns of performance:
WTP 3.2.3 seems to be much slower than 3.0.4.
In fact I am really wondering why WTP gets slower with each release.
One of our applications (dynamic web project) contain about 4000 java classes and 700 jsps/jsp fragments. We only need basic WTP functionality for developing jsps, xmls and xsd. We don't need high sophistic features like Dali (should JPA tools really covered by a webtools project?), Libra or a visual xml editor in the first place.
Another interesting point is that WTP seems to slow down the whole IDE.
SWT is non-reponsive for some fraction of seconds, cpu usage is very high (especially after a built took place - if you look at the system jobs, several jsp/javascript indexers are doing work for some minutes, even if all WTP build validators have been disabled), opening new files are slower, navigating through the project etc.
This can be especially seen on older machines which do contains only a single core cpu.
The worst thing is that I've got the feeling that the WTP dev team does not care much about performance
(e.g. have a look at the http://wiki.eclipse.org/WTP_Performance_Tests page - last update took place in 2008).
Bug reports and Newsgroup posts regarding to performance of basic features (e.g. jsp editing/validating) are often ignored or closed after some time, some examples: here, here, and here.
Quo vadis, WTP?
Please don't get me wrong:
I don't want to blame WTP.
In fact I believe that WTP is a good open-source project developed by a talented team.
But obviously the project has a problem with its quality assurance, especially in terms of performance which affects usability and user acceptance.
I just want to point out that the team should focus on the things which are essential to most of the users in the first place and afterwards work on implementing super-duper-features.
My Questions
What are your experiences with WTP, especially the most recent releases?
Can you confirm or disprove my observations?
Are there better alternatives?
Did you switch from or to WTP and why?
Do you have some best practices to speed it up, especially for upper-mid-sized like ours?
UPDATE
I'd like to make an update on this question to reflect the current answers and
to sum up the current results:
Many users complain about more or less on the same issues so I see those issues as confirmed.
BTW, this question is also mentioned on a news post on theserverside.com with additional comments.
The responsible WTP project lead, nitind, made a notable post on the current situation of WTP, which I like to cite:
"The simple fact is that we don't spend much time on performance tests because we lack resources for doing that."
"Of course we'd like to be proactive about it rather than reactive, but we tend to allocate our time to functional problems first."
So this question turns a little bit into some kind of an open letter from the community to the WTP team:
Dear WTP team,
it's obvious that WTP is suffering from major quality/performance issues
which you try to play down or to ignore.
Please invest some time to improve the current situation
at the cost of new features and do everything what's required
to solve the current problems.
E.g. revive the performance team, do some regression tests between
previous releases or ask the community for (precise defined) help.
I am sure that they are enough people willing and able to help here.
If you like, do some kind of poll to get a feeling what should be
the most important scopes of future's WTP releases.
Please, please, listen to your community.
To respond, I'm the lead for the projects that supply the JSP, XML, and JavaScript source editing functionality in WTP. The simple fact is that we don't spend much time on performance tests because we lack resources for doing that. Of course we'd like to be proactive about it rather than reactive, but we tend to allocate our time to functional problems first. We do have an adopter product running performance regression tests regularly, but I expect that tests are run on multi-core machines by now--and we haven't had any new red flags reported to us for some time.
Of the 3 bugs you linked to, 2 predate the 3.0.4 version you laud and the third is either a formatting performance issue (since addressed) or one with as-you-type validation specific to XML files (the fixing of which would have triggered a memory leak in Xerces, iirc, hence us not putting it in at that time). If you have concrete projects that you can attach to a bug and say "doing X is slower in 3.2 by Y amount", we'll do what we can to figure out where there's a regression.
As for the indexers, they should at least eventually complete. The on-disk information that is stored has changed between WTP versions, and those files need to be reprocessed so they're again included in search and (where implemented) refactoring operations. Once the initial indexing is complete, it should act incrementally and be virtually unnoticeable. One architectural change you may be running into is that for JSPs, the entire workspace needs to be indexed in a single workbench session for that index to be considered "up to date". Shutting down Eclipse out of frustration will only prolong the impact of that reprocessing.
It sounds like your company's standard install includes the entirety of WTP rather than rolling your own custom distribution. I urge you to check the Startup and Shutdown preference page and turn off early startup of any functionality you're not interested in using. Nothing you've mentioned interest in makes use of that facility, but there are other areas of WTP and the Platform that do. Anything you're not interested in validating is fair game on the Validation preference page, as well as the setting to validate JSP fragments by default on the Web / JSP Files / Validation preference page.
We have the same problem with WTP 3.2.3 here, too. We use it in our product for several years, too but the acceptance of our developers and customers in this tool is decreasing every year because in every newer release it is slower and slower.
I would like to use it if I could disable all "advanced" features but as you mentioned you cannot disable the indexers at all. Also you cannot stop the validator of JSP files if it is already running (you can test this if you have that many files as you have and we also have around 1000 JSP files and many tag files in our project).
I also can prove that increasing the memory does not help. It only prevents crashes of the whole eclipse but it does not reduce the UI blocking internal operations of WTP.
In the newest version 3.2.3 I got many hangs when I start Tomcat from within the servers view. The UI just hangs about 1 minute. It's not only me who has the hangs, it's all my colleagues who work on Windows have the same problem. On Linux I do not know about this problem.
Also there are problems in WTP when you have no access to the internet. It seems there are request to some registries to download schemas or such things and if you do not have a connection then it just hangs and waits for the time out.
I don't know who's to blame: WTP or JBoss Tools.
The fact is that, as I work with GWT (minimal JSP), I went the opposite way: No WTP at all!!! I'm now using plain Eclipse for Java, and use a run configuration to deploy (programatically invoking ANT) and start the server, and I never looked back!!!
Eclipse used to take ~1.5GB and crashed several times. Now, it sits on ~800MB, and the whole environment became more stable.
I have seen similar effects, here's one solution that might be suitable in some project environments...
To guarantee fast and responsible Eclipse Web project environment, consider this:
Use Eclipse IDE for Java Developers
98MB version is leaner than 200MB EE version
from General / Startup and Shutdown, disable all but "Eclipse UI"
from Validation, disable validators which you do not need
these probably prevent some performance issues (YMMW)
Use Jetty
you do not need WTP or any other plugins, it's pure Java
like Tomcat but very quick & simple to install into any IDE / environment
embed directly into your project files, configure once for every developer
works in any IDE (Eclipse, IDEA, JDeveloper..)
start Servlet Container with "Debug As" / "Run As"
shutdown Servlet Container by clicking red box on Eclipse console
IDE Console, debugging & hot code replacement & JRebel works fine
Result: fast & responsive Eclipse when compared to many other Eclipse installations that use Eclipse EE version with WTP stuff.
Why? It might be that some Eclipse feature or plugin contains bugs or simply uses resources in a bad way and this makes Eclipse UI sluggish.
Non-Java EE Eclipse is good enough even for many Java EE project environments, it all depends on your architecture and what tools you are using..
Here's a quick tutorial to get started in case you wish to try Jetty Servlet Container out with Eclipse. See https://vaadin.com/web/jani/home/-/blogs/vaadin-for-everyone-how-to-get-started . Download VaadinProjectForAnyIDE.zip, it's an Eclipse project. Just ignore that Vaadin stuff and replace HelloWorldApplication.java with your own servlet and edit web.xml accordingly.
One more thing. With Eclipse EE version, you might also wish to try J2EE preview server which actually is Jetty embedded into Eclipse bundle. However, this also uses WTP mechanism.
I also think the stability and performance of Eclipse/WTP is somewhat alarming. I'm using Eclipse since mid 2003 and have been trying WTP since its very first releases.
At first the quality was absolute abysmal, but for a 0.x version I couldn't complain of course. While waiting for WTP to mature, I used MyEclipse, which was sort of okay but had its flaws too (and being partially based on WTP, inherited some of WTP).
When MyEclipse became heavier and heavier, slower and slower and we ran into several stability issues, we switched to 'pure WTP'. All we were using was really the basic JSP/JSF editor and deployer.
Since WTP doesn't do incremental deployment (at least not for the JBoss server runtime) we added the separate server runtime from JBoss tools. When we adopted Facelets, we also switched to the editor from JBoss tools.
We do however run into a lot of problems we also had with MyEclipse. There are unexplainable slowdowns, but much worse are various stability problems. There are lots of awkward exceptions and crashes. A typical .log file on many different workstations I examined is chockfull of exceptions. A small selection of the last 10 exceptions in my log:
1.
java.lang.NullPointerException
at org.eclipse.jst.jsp.core.internal.validation.JSPActionValidator.isElIgnored(JSPActionValidator.java:147)
2.
java.lang.RuntimeException
at org.eclipse.jface.viewers.ColumnViewer.checkBusy(ColumnViewer.java:763)
3.
java.lang.ArrayIndexOutOfBoundsException: 38
at org.eclipse.debug.internal.ui.viewers.model.FilterTransform$Node.addFilter(FilterTransform.java:67)
4.
org.eclipse.jdi.TimeoutException: Timeout occurred while waiting for packet 302111.
at org.eclipse.jdi.internal.connect.PacketReceiveManager.getReply(PacketReceiveManager.java:171)
5.
java.lang.NullPointerException
at org.eclipse.jst.jsf.facelet.core.internal.cm.ElementCMAdapter.getLength(ElementCMAdapter.java:109)
6.
Caused by: java.lang.NullPointerException
at org.eclipse.jst.jsf.facelet.core.internal.registry.taglib.WebappConfiguration.getConfigFilesFromContextParam(WebappConfiguration.java:184)
7.
org.eclipse.emf.ecore.resource.Resource$IOWrappedException: Feature 'span' not found. (file:///mysystem/Eclipse.app/Contents/MacOS/com
/sun/faces/metadata/taglib/facelets_jsf_core.taglib.xml, 453, 52)
at org.eclipse.emf.ecore.xmi.impl.XMLLoadImpl.handleErrors(XMLLoadImpl.java:83)
...
at org.eclipse.jst.jsf.facelet.core.internal.registry.taglib.TagModelLoader.loadFromInputStream(TagModelLoader.java:100)
8.
java.lang.NullPointerException: No IModelProvider exists for project P/my_project of version: Utility Module
at org.eclipse.jst.j2ee.model.ModelProviderManager.getModelProvider(ModelProviderManager.java:101
9.
java.lang.NullPointerException
at org.eclipse.jst.j2ee.internal.deployables.J2EEDeployableFactory.clearCache(J2EEDeployableFactory.java:238)
10.
org.eclipse.jst.jee.model.internal.mergers.ModelException: java.util.ConcurrentModificationException
at org.eclipse.jst.jee.model.internal.mergers.EjbJarMerger.process(EjbJarMerger.java:79)
Note that these are just the last 10, there are many, many more exceptions.
The casual reaction would be: "Your Eclipse install is corrupted! You have a local problem!" Yes, I might have a local problem, but this "local problem" seems widespread as many Eclipse installs I inspected seem to have this stuff in their logs.
I'm also having problems with deployments like reported at the following link in various incarnations: http://community.jboss.org/thread/158611 It may be JBoss tools specific or it may be based on the underlying WTP or even Eclipse code. I don't know, but I do know it's a nasty problem. Every WTP and JBoss tools version there is 'something' fixed, and every version a problem like that resurfaces in a slightly different form.
Between the stability problems I'm able to get some work done and I love the auto completion and navigate-into features the editors offer me (which keeps me from switching to a text editor and building completely on the command line), but I sure would love some increased stability.
By far the best way for speeding up my projects has been to precompile code that I am not currently using. We have about 20 projects that make up our system and when working on any specific problem I'm only touching a specific subset of those java files. Compiling most of the code that I won't be touching and throwing it into some .jar's, then using that as the source instead of including the projects has proven to speed up things by quite a bit. I imagine it will help you as well if you have 4k+ files.
Each project just has a little build.xml that will make a jar out of it to include.
As for the mind numbing slowness in the JSP editing. I have the same problems, it's just so dam slow. I don't have many more than 100 jsp files but I have the same issues as you. My solution has just been to throw money at hardware, which I must admit I enjoy doing :P.
To answer the following question:
Do you have some best practices to speed it up, especially for upper-mid-sized like ours?
Turning off validation and auto-building after file-saving is a good start to increase performance.
I've disabled the WTP JSP editor for the reasons you mentioned above: It just needs too many resources. Some more things you should consider:
Edit JSPs in the normal HTML editor. That means you don't get code completion which is a good thing. IMO, Mixing Java and HTML is a mistake in the first place and an editor can't fix that. Put all Java code into helper beans (which you can then test easily) and just access the beans from JSP. This should get rid of 99% of all the <% %> tags and solve most of your problems already.
Consider using Spring to be able to build more complex beans and inject them into your JSPs using these patterns:
How to inject spring beans into a jsp 2.0 SimpleTag?
Use SpringBeanAutowiringSupport:
<%!
#Autowired
private Bean bean;
public void jspInit() {
SpringBeanAutowiringSupport
.processInjectionBasedOnServletContext(
this, getServletContext()
);
}
%>
Try a different VM. WTP editors creates huge amounts of objects and now all VMs (GC implementations) can handle that equally well. If you use Sun's Java, try JRockit or IBMs J9. Also play with the GC settings. Increasing RAM won't help because if you have GC issues, more RAM usually only makes it worse (since the GC will have to process more data).
Precompile as much code as possible. You don't need 4000 classes open at all times on your workspace. Cut your huge project into manageable chunks.
Replace JSPs with plain Java servlets and use HTML rendering libraries like rendersnake or use a programming language which plays more nice with HTML (like Groovy).
Get some decent hardware. A new PC with a quad core and 8GB RAM costs $1000. If you save ten minutes every day, the investment will be paid up in 50 days (at the rate of 1 person costs $1000/day all in all).
Try MyEclipse which has much better web editors. The JSP editor is better than WTP (code completion works most of the time, for example) but it's still sluggish.
WTP (3.2.3) is slow for me too. I belive I have found some ways to make it not so slow:
We use maven, so there is a target directory which contains a copy of all JSP's and some other XML's. I have recognized that they are sometimes scanned by the WTP validators. But this is not necessary, so I have excluded them from validation (Project/Properties/Validation/XXX/Exclude Group/). (You should be able to gain the same effect when marking the target directory as derived, but that does not work for me some times ;-( )
I have made the (not scientifically proven) observation, that WTP seems to be faster with JSPX than JSP files.
If you need barebones Java EE then you are better off with Netbeans, if you need everything but just working you are better off with IDEA. It is as simple as that.
Couldn't comment so I will just put my comment in to this answer.
Have you tried upping Eclipse's memory allocation, I know it used to crash all the time when I used it on Mac OS X awhile ago. There is a config file that has the base RAM allocation in it, once I modified that file and gave it an extra 128 megabytes of memory it behaved better. Not sure if this will affect WTP, I am commenting more in regards to the core Eclipse application itself.