hot restart with torquebox-lite? - torquebox

Is hot restarting possible with the torquebox-lite gem? I don't see anything about it on the github page but I'd be surprised if it wasn't possible, can anybody tell me how to do it or if it is possible at all?

Hot deployment (redeploying without restarting the server)
touch $APP_ROOT/torquebox-lite/deployments/<app_name>-knob.yml.dodeploy
The app_name is usually the name of the application's directory
https://github.com/torquebox/torquebox-lite

Related

Eclipse needs to be closed to save settings

I'm making a web app in eclipse, when i make the changes they are not reflecting on my next run.
I'm doing the below.
save changes-> Stop Server-> start server-> run program
but the error appeared before is up again.
I use Kepler 32-bit. please let me know how i can fix this.
Thanks
You need to build your app after saving. If you don't have auto build on then your changes will not be reflected also make sure you publish to server too. Although Since you are restarting the server that may not be needed.

Glassfish taking 20s to do hot deployment, is that right?

I'm working in a JSF project with Eclipse and Glassfish 3.1.2.
Every time I did a minor change and save it, Glassfish do the hot deployment, but is taking too much time to do that, about 20s, at least.
Can I do something do deacrease this time ? Is horrible develop something where you have to wait all time time everytime I change something.
UPDATE
This is how my project settings.
Just open the folder below, this surprise me, is this so many .jar files, is this correct ?
And this one:
My Glassfish configuration :
Any idea ?
There are several ways to deploy a GlassFish application. To speed up development/debuging we need a way to instantly deploy web applications. One of the ways is to use hot deployment feature, another lesser known feature is ‘directory deployment’. You simply point GlassFish to your development directory and let it pick up and deploy application from there. No packaging and re-deoploying hassles. The catch is whenever you want to re-deploy your application you just need to touch a file called .reload which should be present in your web folder.
Following is the command and directory structure you can use.
–|myproj
–|–|src
–|–|web
–|–|–|WEB-INF
–|–|–|–lib
–|–|–|–classes
–|–|–|–web.xml
–|–|.reload
GLASS_FISH_HOME/bin/asadmin deploydir full_path_to_you_web_folder

How to diagnose metro app deployment errors?

When trying to debug a Metro project from VS, I came across this error:
DEP0700 : Registration of the app failed. Another user has already installed a packaged version of this app. An unpackaged version cannot replace this. The conflicting package is PACKAGENAME and it was published by CN=some Guid. (0x80073cf9)
But I have already uninstalled the app from the Start page, also, I can confirm that there is no entry left in Add/Remove program.
And since the access to the "%PROGRAMFILES%\WindowsApps" folder where the app files reside in is blocked, so I have no way to see if the app is still there.
However, I can still find many 'PACKAGENAME' occurances in the registry.
How to diagnose this? How to get rid of the "packaged version" so I can start debugging from VS?
Try installing the app from the windows store again, and then uninstall it from the start page. It appears that when Visual Studio does the uninstall it doesn't do it right.
1) Go to your Package.appxmanifest file in your solution
2) Go to the identity tag.
<Identity Name="xxxxxxx-yyyy-zzzz-tttt-bbbbbbbbbbbbb"
Publisher="CN=bigbob"
Version="1.0.0.0" />
3) Change the value of the Identity Name (Ex from ...bbbbb to ...bbbbc)
4) Rebuild and run
Source:
http://www.sempf.net/post/MetroUIAnother-user-has-already-installed-an-unpackaged-version-of-this-application.aspx
Are you sure you didn't just unpin the app? Try doing a search for it and see if it is still there.
I find a solution to the problem. It's said it is a "staged package" that does not show up in my start page so I can not uninstall it in normal way. I follow the steps, and successfully get rid of that "un-uninstallable" :) package.
This blog post was helpful, although after an hour or so of troubleshooting it turns out that I had indeed installed the package under another user account. After switching accounts and uninstalling from the start screen it worked fine.

Failed to launch simulated application: iOS Simulator failed to install the application

When I create a new window based application, I get:
Failed to launch simulated
application: iOS Simulator failed to
install the application.
I tried to do what this post suggest, but didn't work
Any suggestions? I haven't tried re-installing xcode yet.
Choose Reset Content and Settings in the File menu of the Simulator.
Build Clean in Xcode
Then try again.
I'm not sure why, but rebooting my machine seemed to fix it.
I had the same problem. A reboot also did the trick, but then I realized that the directory
~/Library/Application Support/iPhone Simulator/6.1/
looked "different" after the reboot (Directory "Root" was missing). So I tried to reproduce the error by deleting the directory or parts of it. The simulator each time recreated the directory and worked fine. Maybe the reboot is not really needed just recreating the mentioned directory would also help.
Try to delete project.xcworkspace file and xcuserdata dirctory in your project
It seems that the processes don't get cleaned up properly each time you stop the app with ps aux in Terminal showing a large number of processes representing your app on the simulator.
I expect some kind of upper limit is reached with the number of processes / memory. (Indeed I have found that XCode will fail to build because some posix resource can't be found because there isn't memory to load it)
A machine restart clears all of these dead processes and allows room for new ones. For me, I only have to do this after about 2-3 weeks of not turning my computer off, but I suppose what resources you have and how often you use the Simulator will affect it.
If someone knows how to clear all these dead processes without restarting, that would be useful please, killall ... doesn't seem to have worked for me, but feel free to add to this answer.
Simply go the info.plist file property and set 'Copy to Output Directory' to 'Copy Always' it will resolve your problem.

Eclipse 3.5 Cache Problem

I am using eclipse 3.5 with google app engine + spring framework to develop application. My problem is when I change the code and build the project, the new code doesn't come in to effect. I even deleted the old file but at runtime, the old version gets display in the browser. Why?
Your description is not explicit, so following are my assumptions:
You are changing jsp/js or view related files
You have Google app engine plugin for eclipse to deploy the code
Following might be one of the reasons:
Your view files are cached in the browser, so try deleting the browser cache
Google app engine might have cached your files, so try deleting the temp folder
Eclipse IDE wouldn't have deployed your changed code, so check the timestamp, if it still shows the old timestamp, then find out how to configure eclipse to detect your changes.
I found 3 workarounds for similar issue (changes to a servlet (.java file) were not taking effect).
Before editing the .java file, stop the application. It seems that if you edit it while running, the issue occurs, even if you edit it, stop then re-start.
Delete items in Temp folder e.g, (C:\Users\username\AppData\Local\Temp), then stop and re-start the app.
I think the culprit folder in the Temp folder is this:Jetty_127_0_0_1_8888_war__.g0qk00
Right click in in the console area and select 'Remove All Terminated'. Sometimes that reveals there are other instances running, which need to be stopped by clicking the terminate button.
I got the similar issue and the problem was due to not stopping the running server.
What i was doing was running the server, editing the java file, saving and again running the server. This created two instances of the server running and when checking into the browsers the old code was executed from the first instances.
So, the solution is terminate and relaunch the server, and your new changes will be in effect.