- This topic has 13 replies, 5 voices, and was last updated 19 years, 9 months ago by
.
-
Posts
-
It would be useful to be able to deploy the precompiled JSP pages. They are currently being deleted.
Precompiling JSP pages is typically a production concern rather than a development concern since it implies that speed of initial page loading is more important than the flexibility to modify and reload the page. Can you help us understand the importance of this to you by providing more information around its usage cases for development? This would also allow our other users to determine if such an enhancement would be useful for them also.
Thanks Scott, i find it useful to precomile even when developing so that testing can be done much faster. Precompiling does not negate the flexibility to modify or reload the page. It allows one to navigate to the point of testing much faster. Many times I will redeploy my app and then have to navigate through several jsp’s before being able to see my changes. At this point I have already used your tool to compile them, why depend on the server to do so again. Also, as you stated this is important in production. Your tool is much easier to use to compile the jsp’s than builing the ant script to do so.
The issue with JSP precompilation and deployment is that binary JSPs are not portable between servers. Internally JSP validation is performed by an tightly integrated version of BEJY Tiger by Stefan Franke. Therefore the only option that we deemed possible is to use the precompilation option specified in the web.xml file, see load-on-startup.
Since MyEclipse let me deploy and test on the ‘development’ app server (e.g. Tomcat5, JBoss 3,…), why cannot it let me ‘ship’ the precompiled jsp code? I thought if I get an exploded or a war file, I already get precompiled jsp pages. When I deploy the war file into a JBoss server, even with load on start set, the first access to the jsp pages still take quite long… I am confused…
MyEclipse has never supported the deployment of precompiled JSP pages. Users that have needed it have worked around this by way of an Ant script that will compile and deploy their JSP pages for them as needed.
@cardsharp wrote:
The most important feature I can think of is the “multiple deployments for one web server” feature that’s been oft requested. I develop using exploded archives and desperately need a way to package up the WAR on the fly, whenever I need one. I used to use JBuilder and miss being able to simply right-click on the Web app and generate a WAR with exactly the same configuration as the exploded app.
I just found the quote above posted about 8 months ago. I’m not alone on this request. Ant is great, but since MyEclipse already provided deployment and testing on the target app server, why cannot it also package the war files on the fly for the exact app server the war was being deployed and tested? Isn’t it an easy thing to do?
Isn’t it an easy thing to do?
You can either use a packaged deployment OR File > Export > As WAR File
@support-rkalla wrote:
Isn’t it an easy thing to do?
You can either use a packaged deployment OR File > Export > As WAR File
I am using them. But does this include precompiled jsp classes? What I’m experiencing is that it takes awefully long time the first time accessing the jsp pages in the app, using either Tomcat or JBoss. I’ve set load on start to 0 in the web.xml file
See, in my mind, packaging precompiled jsp classes should be fairly easy thing to do from an IDE, and there are lots of requests for that. Would it be a feature in the near future? Or MyEclipse would just say ‘screw you, use ant instead’?
Or MyEclipse would just say ‘screw you, use ant instead’?
Hah, no MyEclipse would never say that. You are absolutely right that this shouldn’t be *that* hard to do, and it is actually filed in our issue tracker, but that isn’t the issue (no pun intended). The issue is resource allocation; we are a relatively small and agile company, so we can switch gears pretty quickly when trying to deliver a release. At any given release we usually balance around 100-150 issues that we want to close out, 10-20 of which are usually major efforts. With our registered site user base climbing up to 100k, you can imagine that while precompiled binaries is important to you, and the 3 other users that have asked for it very loudy, there are 5k users alone from corporation XYZ telling us that they need visual DB tools immediately… so you see when it comes time to juggle the development resources, the precompiled JSP stuff will quickly bubble down to the bottom of the todo list.
Now, with that said, as fast as precompiled JSPs can bubble down, if enough users wanted it, it would bubble right back up to the top of the pile. That is how all that flexible project support AND deployment enhancements got in… none of those were on our immediately todo lists, but users asked for it and I think within 2 releases (3.8.0 to 3.8.2) all of them were implemented.
So in closing, we love you guys, but please cut us some slack. If we don’t jump up at your suggestion it isn’t because we are ignoring it, we are likely just getting crushed by our current workload (EclipseCon & 3.9 release at end of March) and don’t have the bandwidth to address your suggestion.
I appreciate your answer. Hopefully, it will bubble up one of these days… By the way, keep up with the good job 🙂
