Re: [jervlet-patch] Make Jervlet-Jetty accept external configurations

We can email some requests for enhancement to the Jetty boys. They have done it before for me, and
would do it again. So ..

  jetty.setJettyHome("d:\fooDir");

.. could be one request.

- Paul

 --- Ryan Hoegg <[email protected]> wrote: > Johan Sjöberg wrote:
> 
> > Ryan Hoegg wrote:
> >
> >>> -Possibility to set the system parameter "jetty.home" (can be 
> >>> considered bad by some)
> >>
> >>
> >> My opinion is that this should be set through the configuration, as 
> >> this violates IoC and could provide for some unexpected behavior.  I 
> >> don't usually like voodoo :)  More discussion below.
> >
> >
> > I knew someone would object ;) The reason for it was only to make it 
> > possible to use the original Jetty configuration files without 
> > modification. Agreed that it brakes IoC. You are also correct about 
> > that it might produce strange behavior, for example if several 
> > components are deployed in the same Service Manager etc.
> >
> > Other possibilities are to include examples of more advanced Jetty 
> > configurations in the release, or explaing external confs really well 
> > in the docs. You like writing? ;) Don't worry I'll do it (fingers 
> > crossed). Anyway, remove it.
> >
> OK I looked into the system property stuff a bit more.  On mortbay's 
> site it looks like they are reading system  properties, not writing 
> them.  As far as I can tell, there is no way to set them from within the 
> jetty configuration, right?  Your code takes the <jetty-home/> 
> configuration element and sets the system property with it.  Why not 
> just set the system property before starting the container?
> 
> I also think some container support for setting system properties for 
> use by components would be neat.
> 
> >> Good idea.  Make a loom-jervlet-demo or something.  Then in the 
> >> future we can make others such as plexus-jervlet-demo, 
> >> pico-jervlet-demo, merlin-jervlet-demo.
> >
> >
> > Hmm. I was thinking of not spending any time on demos, but start with 
> > the final release packages already now. Even if they have alfa status. 
> > For the loom part demoserver is quite close, but its final name can't 
> > be demoserver :) Soo, why not make loom-jervlet etc. modules already now?
> >
> The reason I thought if it as a "demo" is that I didn't mean it as a 
> black-box deployable unit, I think.  To me, it was an example for users 
> to create their own SARs, with their own custom configurations.  For 
> instance, demoserver currently has a brain dead setting for the 
> deployer's context docBase.  What would be better?  I don't know.
> 
> >>> -Set the default port (8080) in AvalonJervletJetty to -1.
> >>
> >>
> >> +0.  Why?
> >
> >
> > Ahh, because if you don't specify anything in the AvalonJettyJervlet 
> > conf it will start listening on port 8080 on all hosts. I don't like 
> > systems that open stuff by default. It's risky. Note that this is very 
> > different from having <port>8080</port> and <host>localhost</host> in 
> > the default configuration. That would be OK, as I see it. -1 means no 
> > socketlistener btw. If we include the proposed <socketlisteners> conf 
> > we would have to remove this anyway. Agree?
> 
> +1.  I like the listeners.
> 
> > I'm flexible too. I like to have one for every project though if 
> > possible. Personally I'm quite fond of the old Avalon coding 
> > conventions. Don't know if they exist anymore as before.
> 
> 
> I was sort of waiting on someone with a bit more spice tenure to pipe up 
> and give some direction on style guidelines :)
> 
> >
> >> Also, I think the ${app.home} substitution that was added in 
> >> AbstractJettyJervlet warrants some discussion.
> >
> >
> > The purpose of that is to find the loom/apps/yourapp before knowing 
> > where in the filesystem the installation exists. Before deploying 
> > systems all configurations are usually done beforehand as much as 
> > possible. It helps a lot if you can use some relative root like that. 
> > Agreed that one could put the webapps dir under e.g. /var/webapps 
> > instead. Remove it is you don't like it, it sure is a little smelly.
> >
> Not interested in removing it, at all.  Actually, I'd like to extract it 
> into either another component or a container service.  Talking it out on 
> jcontainer-interest.
> 
> --
> Ryan Hoegg
> ISIS Networks
> http://www.isisnetworks.net
> 
> 
> 
> -------------------------------------------------------
> This SF. Net email is sponsored by: GoToMyPC
> GoToMyPC is the fast, easy and secure way to access your computer from
> any Web browser or wireless device. Click here to Try it Free!
> https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tmpl
> _______________________________________________
> Spice-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/spice-devel 

________________________________________________________________________
Want to chat instantly with your online friends?  Get the FREE Yahoo!
Messenger http://mail.messenger.yahoo.co.uk


-------------------------------------------------------
This SF. Net email is sponsored by: GoToMyPC
GoToMyPC is the fast, easy and secure way to access your computer from
any Web browser or wireless device. Click here to Try it Free!
https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tmpl