Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jetty-dev] Jetty Plugin Functionality / Getting rid of Jetty Hightide release at codehaus

I like the idea of putting everything involved with a module under a
common location and not co-mingling things

reusing our lib and etc directories will make it harder to have
install/remove functionality..

what I am thinking is something akin to

jetty.home/etc/jetty-modules.xml <-- entry point for supporting
modules, if your start.ini file has this line at the end, then you
have modules support, this is where a plugin manager is created (if we
need one really) and registered with the server, etc.

this plugin manager can look at the modules or plugins directory and
then handle the configuration and deployment of anything under there,
it can handle adding libraries to the system classloader, it can
handle deploying webapps, contexts, but the jetty-modules.xml
initially could just contain a different deployment provider then the
one watching webapps...just by having its own webapp provider
instances, if there is configuration xmls that need to be run on the
server object, it can handle the XMLConfiguration needed for it..

I like this being self contained so we enforce by convention and
logical separation between plugin configuration and jetty
configuration....these things may still modify the Server object and
contribute to the system classloader but its very clear that if you
want to tweak the special connector an administrative webapps module
is registering and setting up, that you go into the
plugin/admin_console/etc/plugin.xml file to do it.

this also means that if your having issues you can just

> mv modules/admin_console ..

restart and your done...you don't have to root through other files and
make sure libraries have been removed, etc..

cheers,
jesse


On Thu, Nov 3, 2011 at 18:20, Greg Wilkins <gregw@xxxxxxxxxxx> wrote:
> Thomas et al,
>
> I was thinking that in regards to configuration, we already have some
> modularity support in the form of:
>
>  lib/foo  - contains the jars and dependencies for foo module
>  etc/jetty-foo.xml - contains the configuration for foo module.
>
> So it would be good to see if a module system could use this pattern
> rather than add another one.
>
> I do see a need for a plugins directory, but mostly to contain meta
> data about the plugin and perhaps some example webapps and context xml
> files.
>
> The hardest thing for modules, is going to be the manipulation of
> start.ini, as it is this file that will ultimately control what
> modules are on the classpath and what configurations are executed.  I
> see we need a utility to maintain start.ini rather than encouraging
> manual editing.
>
> cheers
> _______________________________________________
> jetty-dev mailing list
> jetty-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/jetty-dev
>


Back to the top