Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jetty-dev] Re: start.options Re: [jetty-dev] Re: jetty7 distribution

I went ahead and added the following to start.config ...

OPTIONS~=default,*  ! property OPTIONS

The codebase in trunk (rev 681) now allows for that to be defaulted in the start.config if not present on the command line.

And as for start.ini, it currently acts in a similar way to the eclipse.ini, in so far as that each line in the start.ini represents a command line argument.

It can handle arguments passed to the start.jar just fine.
However, I have not implemented the ability to pass JVM arguments/parameters via it (yet).
I'm leaning towards using the eclipse.ini pattern of "--vmargs" being the point where all arguments after it are considered JVM arguments.

I'll add this to my Wiki Documentation TODO list.

----
Joakim Erdfelt / joakim@xxxxxxxxxxx


On Mon, Aug 10, 2009 at 7:19 PM, Greg Wilkins <gregw@xxxxxxxxxxx> wrote:

Joakime,

start.ini !! I knew you had done something like that.
How does start.ini work?  it is not documented in start.jar help?

So with that, we have half what I'm after - ie the ability to
have a configurable default command line.


But the other part I think we need, is the ability to create new
options without needing to edit the start.config file.

The proposed
       [=$(jetty.home)/lib/*]

syntax, will make all subdirectories of lib options.  Thus
new options can be added simply by adding subdirectories.

So Jetty-hightide can add it's options without remaking
a start.config file.


cheers





Joakim Erdfelt wrote:
> Is this about ...
>
> a) Making a new default list of preselected OPTIONS?
> b) about making the OPTIONS be defaulted to set list?
>
> in the case of (a) you could just add that new OPTIONS list to the start.ini
> in the case of (b) we could add some logic to start.config to allow an
> entry like this ...
>
> OPTIONS=All                  ! property OPTIONS
>
> So that we can default the OPTIONS list if not provided.  wdyt?
>
> ---
> Joakim Erdfelt / joakim@xxxxxxxxxxx <mailto:joakim@xxxxxxxxxxx>
>
>
> On Sun, Aug 9, 2009 at 6:03 PM, Jan Bartel <janb@xxxxxxxxxxx
> <mailto:janb@xxxxxxxxxxx>> wrote:
>
>     Inline ...
>
>
>     Greg Wilkins wrote:
>
>
>         All,
>
>         I'm wondering if we could do some more minor improvements with
>         the way that
>         start.jar and the structure of lib work together.
>
>
>         Currently we have lib/ext which is always on the classpath, so
>         jetty-hightide
>         now is adding
>
>          lib/ext/atomikos
>          lib/ext/derby
>
>         But we really don't want those ALWAYs on the classpath.
>
>         We could move them to
>
>          lib/atomikos
>          lib/derby
>
>         but then we would need to have entries in start.config for all such
>         possibilities... which would need good foresight.
>
>
>         So instead, I'm wondering if we should update start.jar mechanism
>         with a way to discover options.  So if lib/jsp, lib/jta, lib/jndi
>         directories existed, then adding
>
>         [All,=$(jetty.home)/lib/*]
>
>         to the start.config file would be equivalent to adding
>
>         [All,jsp]
>         $(jetty.home)/lib/jsp/**
>
>         [All,jta]
>         $(jetty.home)/lib/jta/**
>
>         [All,jndi]
>         $(jetty.home)/lib/jndi/**
>
>
>     As we're including atomikos and now also derby, all to make the test
>     jndi/annotations
>     webapps work out of the box, but yet we want to signal that they're
>     optional and
>     replaceable (eg jotm (transactions), mysql (database) etc etc), then
>     it would
>     be nice to put these jars in clearly and cleanly defined
>     subdirectories, so:
>
>     $(jetty.home)/lib/jta/jta.jar
>     $(jetty.home)/lib/jta/atomikos/**
>
>     $(jetty.home)/lib/jdbc/derby/**
>
>     So one can easily delete the jta/atomikos or jdbc/derby directories and
>     replace as needed.
>
>
>
>         More over,  I'd like to make the default options configurable
>         from a file,
>         so that for the jetty-hightide distribution all the jndi, jaas
>         examples
>         webapps would work out-of-the-box, but without hard coding their
>         dependencies
>         into the default options list.
>
>         I think start.jar should check for a start.default file (in
>         current directory
>         or passed in via option), that would contain a default command
>         line to
>         execute.  So for hightide, it might be something like:
>
>         OPTIONS=Server,jmx,jsp,jta \
>         ${jetty.home}/etc/jetty-jmx.xml \
>         ${jetty.home}/etc/jetty.xml
>         ${jetty.home}/etc/jetty-ssl.xml
>
>
>     To get the test webapps to work it would be:
>     OPTIONS=Server,plus,annotations,jta,jdbc
>
>     so uniting the 2 lists it would be:
>     OPTIONS=Server,plus,annotations,jta,jdbc,jsp,jmx
>
>     Actually, if the philosophy to-date has been that hightide is
>     the optioned-up jetty, then perhaps the default should be:
>     OPTIONS=All
>
>     Then users who care about paring back can change the start.default
>     file or command line to specify exactly what they want?
>
>     cheers
>     Jan
>
>
>
>
>         Joakim - you were working on something like this right?
>
>         thoughts????
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>         _______________________________________________
>         jetty-dev mailing list
>         jetty-dev@xxxxxxxxxxx <mailto:jetty-dev@xxxxxxxxxxx>
>     Jan Bartel, Webtide LLC | janb@xxxxxxxxxxx <mailto:janb@xxxxxxxxxxx>
>     | http://www.webtide.com
>
>     ---------------------------------------------------------------------
>     To unsubscribe from this list, please visit:
>
>       http://xircles.codehaus.org/manage_email
>
>
>



Back to the top