Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jetty-dev] Feedback on proposed start.jar and start.ini changes.
Inline ...

On Sun, Apr 28, 2013 at 9:04 AM, Michele Rossi <michele.rossi@xxxxxxxxx> wrote:
hi,
since you are discussing changes to the jetty start.ini / start.jar I would like to propose a few things:

- The generated classpath is now gigantic, including one by one every single jar inside /lib.
This is no longer necessary as modern VMs support the "*" wildcard for the classpath.
We use it successfully at work.
This would help as on UNIX systems you are stuck with "ps -ef" and the output for jetty is so long at the moment that you can't see all of it.

Historically, our need to work on all java capable platforms meant we could not rely on this feature.
Also, we would need fine-tuned / partial wildcard support as well.  eg: ${jetty.home}/lib/jetty-jmx-*.jar


- Do we really need start.jar / a java launcher?
It would be cool to be able to start jetty just with a script so that there is no launcher java process.
With the classpath change described above it should be pretty straightforward.
It is sometimes confusing to have two processes running, one doing apparently very little (it seems to linger around after starting jetty but does not seem to provide auto-restart of jetty).

First, the default behavior of start.jar is to *not* start another JVM.  (a new JVM only happens if you have --exec enabled)
The role of start.jar to collect the desires of the command line and start.ini, validate the environment, establish the server classpath, and build up the jetty environment from the xml descriptors.

While our default xml descriptors build up 1 server with 1 connector with 1 deployment manager with 1 app provider, this is not the only environment it is capable of running.  
 

- Automatic start up on UNIX.
As far as I know on UNIX configuring processes to start automatically can be done in a number of ways, all of them confusing / unclear unless you are a UNIX guru / sysadmin.
In the Jetty documentation there doesn't seem to be a clear indication of how to achieve that.
I think it would be very helpful having a simple script under "/bin" that just installs Jetty to start automatically when the machine reboots.

There are as many flavors of how to do this as their are flavors of ice cream.  There is no 1 way to accomplish this, or even a best practices way.
We have settled on supporting the popular linux distros (ubuntu and redhat) and the osx.  For those running HP-UX, iSeries, Solaris, or AIX, they have to write their own startup scripts for Jetty.

And to top it all off, the various bundles for Jetty built by the distributions ignore our jetty.sh and build their own. Ubuntu's jetty startup and redhat's jetty startup are different.

 

- Use of variable JAVA in current script instead of JAVA_HOME
This is a minor one but the standard in the Java world is JAVA_HOME (pointing to the root installation folder of Java) and not JAVA pointing to the java executable.

Not sure how this question about start.jar and start.ini got sidetracked into jetty.sh ...

JAVA in the script is for the JAVA executable, which is required for support on cygwin, as it requires the extra .exe extension.

As for JAVA_HOME, surprise, its not standardized either.  OSX doesn't need it to use java (both the as-built-by Apple versions and the more recent Oracle versions).

 

Hope the above makes sense, apologies if I have missed something obvious in the documentation, in that case I deserve a loud RTFM.

All good points, however there's no real explanation for the historical decisions.

Thanks for the technical input. :-)
 

--
Joakim Erdfelt <joakim@xxxxxxxxxxx>
Developer advice, services and support
from the Jetty & CometD experts

Back to the top