How to stop only one app? - jetty

Jetty is running 3 sites from webapps. On of which is a "static" angular site, another is a huge java app.
Typically, I use Ctrl + c to stop Jetty, make changes on my angular site, and start Jetty with
java -jar start.jar -DCommon.properties.path=C:\Jetty
If I try to edit the files while Jetty is running, random, buggy code is injected, breaking the site.
So this process is extremely tedious. The java app takes 15-20 seconds to load. So if I forget a slash, it takes about a min to shut it down and restart it.
Is there a way I can just stop/start only one of the webapps instead of all 3 at once?

You seem to be using Windows.
The problems you are having relate to the traditionally wonky FileSystem locking behavior that is unique to Microsoft Windows (no other OS that runs Java does this)
See official documentation about it at
https://www.eclipse.org/jetty/documentation/current/troubleshooting-locked-files-on-windows.html
If you follow the advice laid out in that documentation then you'll not need to stop/start a specific webapp.
Important: Note that the advice in the documentation is for DEVELOPMENT TIME ONLY and is not a good general configuration for production.
Insert from OP:
I followed the directions in the docs above, and it worked! Here's what I did:
Find your webdefault.xml file.
Mine was in C:\Place_where_Jetty_was_installed\Jetty\etc\
Open it and search for UseFileMappedBuffer
Find this:
<init-param>
<param-name>useFileMappedBuffer</param-name>
<param-value>true</param-value>
</init-param>
Set param-value to false
<param-value>false</param-value>
That being said, if you still want to go down this path, there's 2 ways ...
1. Use hotreload
Create an XML deployable for your "reload" webapp and touch it to hot reload just that 1 webapp.
The File: ${jetty.base}/webapps/myapp.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE Configure PUBLIC "-//Jetty//Configure//EN"
"http://www.eclipse.org/jetty/configure_9_3.dtd">
<Configure class="org.eclipse.jetty.webapp.WebAppContext">
<Set name="contextPath">/myapp</Set>
<Set name="war"><Property name="jetty.webapps"/>myapp.war</Set>
</Configure>
Then to make jetty reload it just ...
$ touch /path/to/myjettybase/webapps/myapp.xml
This standard Posix command will update the timestamp of that file, which will be seen by Jetty as "hey, that file updated, I must reload it"
2. Use JMX to stop/start a specific webapp
Start Jetty with the JMX module active (--module=jmx).
Start a JMX console (the JDK ships with jmc and jconsole) and connect to your running Jetty instance. Find the MBean for your specific webapp and use the stop() and start() commands on that specific webapp.

Related

Auto-reloading WAR in Jetty standalone

I have a WAR deployed to Jetty 9.0.0.M3. I am trying to figure out what I need to set in my context in order to be able to have it reloaded every time I upload an updated war file (without having to restart Jetty).
I had a look at the docs, but I'm afraid I couldn't find what I was looking for. I only know how to do this with the embedded Jetty Maven plugin, but not with the standalone.
Any help would be appreciated! Thanks.
The key is in the deployer. You need to wire up the deployment manager functionality and have it manage the starting of the webapp.
http://git.eclipse.org/c/jetty/org.eclipse.jetty.project.git/tree/jetty-deploy/src/main/java/org/eclipse/jetty/deploy/providers/WebAppProvider.java
The jetty xml files are effectively a thin skin over java so look the following xml file which is what jetty uses for the traditional webapp startup of our distribution.
http://git.eclipse.org/c/jetty/org.eclipse.jetty.project.git/tree/jetty-deploy/src/main/config/etc/jetty-deploy.xml
This ought to get you fixed up.

Compile JSP & Java on browser refresh - Tomcat

Is there any way to setup Tomcat server so whenever I make changes to Java class or JSP page the change is visible on browser refresh.
I'm bored stopping and starting Tomcat. I want to configure Tomcat like the way WAMP works [where you can see the PHP code change upon browser refresh]
If it's for development mode that's ok. Don't use it for production stuff.
You don't have to restart the server. You can restart the app through the Tomcat Manager.
You can even do this directly as: http://[hostname]:[port]/manager/reload?path=[/path/to/your/webapp]
or
Define your context as reloadable
Be careful: It is NOT recommended to place elements directly in the server.xml file
Check out the Tomcat configuration guide
For java classes: reloadable
Set to true if you want Catalina to monitor classes in /WEB-INF/classes/ and /WEB-INF/lib for changes, and automatically reload the web application if a change is detected. This feature is very useful during application development, but it requires significant runtime overhead and is not recommended for use on deployed production applications. You can use the Manager web application, however, to trigger reloads of deployed applications on demand.
NOTE - The value for this property will be inherited from the reloadable attribute you set on the surrounding Context component, and any value you explicitly set here will be replaced.
(http://tomcat.apache.org/tomcat-7.0-doc/config/loader.html)
For JSP: development ($CATALINA_BASE/conf/web.xml)
development - Is Jasper used in development mode? If true, the frequency at which JSPs are checked for modification may be specified via the modificationTestInterval parameter.true or false, default true.
Hope this helps

How does one add or update a WAR file/folder to the default embedded Jetty server in a Restlet 2.1 Application?

I would like to develop a Restlet 2.1 Java SE or Java EE Application that uses a (default) Jetty server, as opposed to an external Jetty/Tomcat server.
But I would like to configure the WAR file/folder that Jetty is processing, even allowing for stop(), reconfigure() or reload(), start() to happen at run time. In the external case, I can use setWar("path to war file/folder") from the Jetty API to achieve my goal, so this is plan B. Plan A is to figure out how to do this from the Restlet 2.1 API.
I cannot see a way to do it and I'm hoping that I'm just missing an obvious, or even not-so-obvious solution.
I think the Jetty WebAppProvider will provide what you need. If not, have a look at my hot swap code for WAR files in an embedded Jetty on this thread.

Delphi native Web Service applications not working. IIS 7 seems to be stripping the pathinfo

I've run into an interesting problem that I never encountered with XP or IIS 6.
Basically, I can't get a native Delphi (WebBroker) Web service server to work with a native Web service client in Windows 7 64-bit.
Here's the most basic breakdown. If I create a new Web service application in Delphi 2010 (or any version, back to Delphi 7), and access it using IE 8, I can see the HTML that the WSDLHTMLPublish component creates, but I can never get to the SOAP. In the same way, the WSDL Importer cannot get to the SOAP either. (I have IIS 7 configured to use a 32-bit application pool, and I have created a working Script Map to the Handler Mappings. In short, the 32-bit ISAPI Web service is running).
For example, I have a simple Web service server named TestService (created using the default sample interface generated when you create a new Web service server).
I installed it in a virtual directory named scripts.
If I enter http://localhost/scripts/TestService.dll/wsdl, IIS 7 displays the page http://localhost/scripts/TestService.dll.
If I put my mouse over the WSDL link for the ITestService, I see http://localhost/scripts/TestService.dll/wsdl/ITestService in the status bar. However, when I click this link, the address bar shows http://localhost/scripts/TestService.dll/wsdl/ITestService, but I see only the HTML from http://localhost/scripts/TestService.dll. There seems no way to get to the SOAP definition. IIS 7 seems to be ignoring everything after the script name (it is ignoring the pathinfo).
Additional evidence that IIS7 is stripping off the pathinfo is that if I pause my mouse over the ITestService link, the statusbar shows http://localhost/scripts/TestService.dll?intf=ITestService. Clicking that link takes me to another HTML page, the one associated with http://localhost/scripts/TestService.dll?intf=ITestService. However, any link that includes a pathinfo following the script name, takes me simply to http://localhost/scripts/TestService.dll.
I have tested this in Delphi 7, Delphi 2010, and Delphi XE, with the same results.
I am guessing that IIS7 is stripping off the pathinfo, since even the WSDL Importer cannot get to the SOAP definition.
Tried creating a new Web service using the CGI option, and got the same result.
Have any idea what is going on?
Added: Bob Swart reports he has had no problems under Windows 7 32-bit. Downloading the 32-bit OS and will try that (in a new VM).
The problem was that I had created a specific script mapping in the Handling Mappings for the ISAPI dll. This caused IIS to redirect all requests to the specific dll, which was why any request that included an info path part was ignored. The info path was stripped off.
What I really needed to do is to simply enable the Execute feature permission of the ISAPI-dll module mapping handler mapping. This module mapping is available for a virtual directory once you have allowed unspecified ISAPI modules (or CGI modules, if that is the kind of Web server extension you have created).
To fix my problem, I needed to
Delete the directory whose handling mappings I has messed up.
Since I already had allowed unspecified ISAPI modules (select Edit Feature Settings from the ISAPI and CGI Restrictions applet from the IIS section of the server), I then needed to add a new virtual directory for the appropriate Web site (here is where I recreated the directory that I deleted in previous step 1.
From the Handling Mappings applet for the virtual directory, you probably have the ISAPI-dll handling mapping disabled. Select it and select the Edit Feature Permissions option on the right-hand side. Enable the Execute checkbox.
Don't edit the ISAPI-dll handling mapping and add an Executable. Even though this dialog box says that Executable is optional, once you've added one, it's over. You can never remove it (I could never remove it). On one of my VM installs I had an Executable entry on this dialog box. In order to get rid of it, I had to uninstall IIS 7 and then reinstall it. (Maybe this wasn't necessary, but I could not figure out how to remove and reinstall a module mapping without entering the Executable entry).
Additionally, if your ISAPI DLL is a 32-bit DLL, and you're working in a 64-bit operating system, you need to enable 32-bit applications for the associated application pool.
I hope my pain has helped someone.
I know that this question is a little bit old, but this answer might help someone with the same problem.
When you add the Script Map in the IIS Manager it creates the handler in the web.config like this:
<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<system.webServer>
<handlers accessPolicy="Read, Execute, Script">
<add name="MyISAPI" path="myisapi" verb="*" modules="IsapiModule" scriptProcessor="C:\MyISAPI\myisapi_extension.dll" resourceType="Unspecified" requireAccess="Execute" preCondition="bitness32" />
</handlers>
</system.webServer>
</configuration>
What you need to do is to add the attribute allowPathInfo="true" to the handler. The IIS Manager doesn't have this option and you have to edit web.config manually:
<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<system.webServer>
<handlers accessPolicy="Read, Execute, Script">
<add name="MyISAPI" path="myisapi" verb="*" modules="IsapiModule" scriptProcessor="C:\MyISAPI\myisapi_extension.dll" resourceType="Unspecified" requireAccess="Execute" preCondition="bitness32" allowPathInfo="true" />
</handlers>
</system.webServer>
</configuration>
This way you can choose the request path of the ISAPI extension (in this example: http://HOSTNAME/MyISAPI/myisapi), otherwise without this change you will need to call the ISAPI extension with the name of the DLL (http://HOSTNAME/MyISAPI/myisapi_extension.dll)

How can I deliver jetty with many webapps via jnlp?

I have a webapp (http://sourceforge.net/projects/sf-mvn-plugins/files/m2-repo/net/sf/maven/plugins/example-captaincasa-jnlp/0.1-SNAPSHOT/example-captaincasa-jnlp-0.1-SNAPSHOT.war/download) which uses jsf in a servlet container. This works fine with jetty-maven-plugin run-war target at my local pc. In the future I would like make more of this kind of webapps.
I am looking for a way to deliver these webapps with jetty via jnlp. The end user should be have a zero installation but the webapps needs servlet container and my hoster does not support a servlet container or application server or so on.
I don't like an embedded solution because in this case each webapp must be delivered with a separate jetty und run with a separate jetty -> too big size -> to many download size and so on.
The architecture should be similar to this:
(source: sourceforge.net)
Example: Bundle1 could contains jetty and deployed webapp1 and Bundle2 could contains jetty and deployed webapp1 and webapp2 (related to requirements of end user I would like deliver many variant of my webapps)
But what is my question?
Which jars of jetty are needed? I would like these upload to my homepage for hosting.
Which jar should I use for jetty as main jar to start him via jnlp?
Which main class should I use to start jetty via jnlp?
Which parameter could I use to configure jetty to say this is war of webapp1 and this is war of webapp2.... or this is directory of weapps for hot deployment...?
The important question for me is 1. If this is answered so that I could run jetty local (without maven plugin) and via manual maybe I could solve the rest 2-4.
Why not deploy a normal Java app (with a main() etc.) that invokes Jetty programatically via its Server class? That class is configured via code with the appropriate contexts, servlet classes etc.
I've done that before with success. The only headache is running one Jetty with multiple apps being downloaded on request (if I read your question correctly). Can you use some classloading magic, and load classes/apps on demand from a remote URL ?
I have found another way today. This is interesting too. Here is the concept:
Use java webstart to install an osgi container
Use a bundle x or a osgi service to download all bundles of your app
Use the jetty bundle to provide jetty support
Then the application is installed
I got the idea from this article:
http://www.toedter.com/blog/?p=45