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 
Hi Eirik,
nice input, thx. Will definetly have a look at Jexmec and see if it can in any way fit our needs. One of the main targets is to keep the whole thing lightweight. Will check if and how Jexmec will fit into that picture. 

Cheers,
Thomas

On 11/3/11 10:52 PM, Eirik Bjørsnøs wrote:

This idea reminded me of the thoughts I had when I created
JettyConsole[1] some years back

JettyConsole embeds Jetty into war files and making them "executable"
with java -jar [1]. The most common way of creating JettConsole wars
is using the Maven plugin.

JettyConsole is extendable through a plugin API. Plugins have access
to the Server and WebAppContext and are able to modify and add
functionality. Plugins can also contribute command line options for
configuring themselves or for configuring Jetty. Some examples of
plugins are:

* JSP support
* AJP support
* Jetty XML configuration support
* Windows Service installation
* Unix start/stop scripts
* Log4J configuration

The plugin support in JettyConsole leverages Jexmec[2] to do the heavy
lifting. Jexmec is designed to be a clean, simple and non-intrusive
library supporting plugin based development on the Java platform.

Dependency injection and class loading in Jexmec is pluggable. So you
can start small and simple using pure constructor injection on the
normal class path (like JettyConsole does). Then if and when you need
to, you can choose to add Spring or Guice dependency injection or do
fancier class loading using dynamic class loading (like OSGi). There's
also a class loader provider which allows you to point at Maven
artifact, download it with dependencies and create a class loader from
it.

Applications using Jexmec define their plugin APIs using just Java
interfaces and classes. Applications can make certain services
injectable to plugins. This is also defined using plain Java
interfaces.

Maybe not directly applicable to what you guys are doing, but might be
worth taking a look. The Jexmec reference documentation has more info
on the background and design of Jexmec[3]. There's also the
Javadocs[4] and the source code [5] (ASLv2).

Thanks,
Eirik.

[1] http://simplericity.com/2009/11/10/1257880778509.html
[2] http://jexmec.org/
[3] http://jexmec.org/sites/jexmec/versions/latest/jexmec-docs/reference/html/book.html
[4] http://jexmec.org/javadocs/
[5] https://opensource.kantega.no/svn/jexmec/trunk/

On Wed, Nov 2, 2011 at 5:15 PM, Thomas Becker<tbecker@xxxxxxxxxxx>  wrote:

Hi all,

as you might already know, we maintain two jetty releases at the moment. The
core jetty is hosted at eclipse and additionally we maintain the "Jetty
Hightide" release hosted at codehaus:
http://docs.codehaus.org/display/JETTY/Hightide+Documentation.
We'd like to get rid of hightide and all the maintenance work caused by it.
To do so, we evaluate a plugin/module concept for jetty and wire up the
remaining hightide features as plugins for eclipse jetty. In a later phase
it can be extended to contain plugins not from hightide (e.g. cometd) and
even plugins contributed by the community. We'd like the community to take
part in the design decisions and discuss the setup with all interested
developers.

In the first phase we want to achieve the following milestones:

- discuss and write down a directory structure for plugins
- wire up and run a proof of concept with the hightide activemq module
- tweak jetty-start to be able to load everything belonging to the POC
plugin which is installed manually at this phase

In the second phase:

- some kind of ModuleManager to activate/deactivate plugins and
install/remove plugins
- use aether to fetch plugins from maven central

In the third phase:

- create more plugins (cometd, etc.)

The first thing to think about is the directory structure for plugins. Jesse
McConnell and I had a discussion and the following structure is what I've in
mind after the chat with Jesse:

(some standard directories are omitted for readability)
$JETTY_HOME
    |-bin
    |-contexts
    |-contexts-available
    |-etc
    |-lib
    |-plugins
    |---activemq
    |-----context
    |-----etc
    |-----lib
    |-----webapps
    |-resources
    |-webapps

So basically everything belonging to a plugin is installed in a single
directory: $JETTY_HOME/plugins/[pluginname] and thus can be
installed/removed easily. It's also nicely separated from everything else.

As you can see a plugin is supposed to be able to have config files,
additional jar files and even webapps (at least in a later phase). First of
all we need to tweak jetty-start to pickup and enable installed plugins.
Then we need to think about something like a PluginManager responsible for
installing/removing plugins from maven central and a config file for the
plugin-manager "jetty-plugins.xml" enabling/disabling plugins.

Plugins could be installed on the commandline using something like:

java -jar start.jar -list-plugins

to retrieve a list of available plugins. And:

java -jar start.jar -install-plugin [pluginname]

to install a plugin.

I will now start with hightide activemq and fit it into the directory
structure as shown above. However this is all open for discussion and if
you've better ideas, like another structure/approach more, please let us
know. I will be able to refactor at any time.

Cheers,
Thomas

--
thomas becker
tbecker@xxxxxxxxxxx

http://webtide.com / http://intalio.com
(the folks behind jetty and cometd)
_______________________________________________
jetty-dev mailing list
jetty-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/jetty-dev



_______________________________________________
jetty-dev mailing list
jetty-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/jetty-dev


--
thomas becker
tbecker@xxxxxxxxxxx

http://webtide.com / http://intalio.com
(the folks behind jetty and cometd)

Back to the top