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 have been thinking that we could have an OPTION in the start.config

[plugins]

jetty.home/plugins/*/lib/**

then when using the plugins OPTION you get the jars in the plugins
loaded into the system classloader, same as you would with an option
under jetty.home/lib

if you have a plugin in the plugins directory then its getting loaded
regardless, no more lifecycle needed then that, if its there, and you
have plugins in the OPTIONS those jars are loaded

I also think we should have a jetty.home/etc/jetty-plugins.xml file,
that loads a class that processes the plugin configuration..

that would run the xml files under each plugin located
jetty.home/plugins/jndi/etc/jetty-jndi.xml

I use jndi as an example of something that could be a plugin under
this model, its just some jetty xml and some library files

the jetty-plugins.xml would take care of applying the xml files
against the correct objects, id="Server" in the case of jndi (or is it
webapp context, I forget)

So initially, I don't think we really need to get more complex then
that...that would let us have a hightide plugin that included all the
bits we have in normal hightide distribution, following a simple
convention very much like the rest of jetty

I am not proposing that we move the jndi and jmx and those things to
plugins in this fashion right now...perhaps we could have an alternate
distirbution that uses this model fully, or if it works well we
standardize the convention for jetty-9

in my mind...we should focus initially on the conventions surrounding
encapsulating a module/plugin and deal with the bits of
enabling/disabling once we have a working plugin model akin to what I
have described above...

we could also have the plugins support webapps but adding a special
deployer in the jetty-plugins.xml file...perfect for an admin webapp
type setup

at least that is where my thinking has been

cheers,
jesse

--
jesse mcconnell
jesse.mcconnell@xxxxxxxxx



On Tue, Nov 8, 2011 at 16:59, Jan Bartel <janb@xxxxxxxxxxx> wrote:
> Can we clarify what is the lifecycle of a plugin and how it relates to
> a jetty distro?
>
> I assumed that plugins would NOT be distributed with the distro, but rather that
> they would be fetched as needed from a remote repo:
>
> java -jar start.jar --fetch-plugin foo
>
> Users would have to be able to see what plugins are available to get:
>
> java -jar start.jar --list-plugins
>
> Users would want to be able to update plugins (this will require some thought
> as to how to update possibly user-modified xml files, and possibly difficulties
> with determining compatibility):
>
> java -jar start.jar --update-plugin foo
> or
> java -jar start.jar --update-plugins
>
> Then once they have been downloaded, then its an issue of how do they get
> incorporated into the jetty installation.
>
> Having a separate /plugins directory is good for encapsulation, but not ideal
> for users trying to work out where to look for config and libs (ie is it in
> $JETTY_HOME/etc, $JETTY-HOME/lib (or subdir thereof), in start.ini
> or in $JETTY_HOME/plugins/foo/etc, $JETTY_HOME/plugins/foo/lib etc).
>
> I think it is important that we recognize the central importance of start.ini.
> We have this mechanism which determines what jars go on the classpath
> and which xml files take effect, so I think it also has to be the central place
> where plugins are put onto the classpath.
>
> At some point, users may want to remove a plugin completely:
>
> java -jar start.jar --remove-plugin foo
>
> Or users may want to temporarily prevent a plugin from being used:
>
> java -jar start.jar --disable-plugin foo (or maybe edit start.ini?)
>
> And then start using it again:
>
> java -jar start.jar --enable-plugin foo (or maybe just edit start.ini?)
>
> And our start.jar --dry-run should also list which plugins are enabled.
>
> Jan
>
>
> On 5 November 2011 11:35, Jesse McConnell <jesse.mcconnell@xxxxxxxxx> wrote:
>> If that is the case greg then we already have this the core of this
>> functionality in place, its what we use for building the distribution
>> right now, see the jetty-*-*-config.jar artifacts...they get unpacked
>> over the distribution, we would just have to rejigger it into a build
>> so it can drop in the files under the lib dir as well...
>>
>> I don't see that as getting us very far in terms of this being a
>> friendly system though, its not really convention rich
>>
>> joakim had mentioned another idea on irc while we were discussing this
>> that I liked as well that was related to this, just modeling this on
>> how apache httpd itself works, having an available-modules directory
>> and then symbolically linking in the ones we wanted to enable, same
>> basic concept
>>
>> I rather like that idea as jetty-jndi and jetty-jmx could work that
>> way as well...just as modules that you either copy or link in and they
>> get picked up, I just can't help but think if we keep following the
>> overlay model its going to get more out of hand then it is now, a mess
>> of configuration files that mostly are not used.
>>
>> Also, if we do this right and convention based, I don't see the
>> start.ini file needing to be changed at all, except to make sure that
>> jetty-modules.xml is in there, the OPTIONS line can be constructed by
>> looking in the modules directory for each plugin present under the
>> 'lib' directory for system libraries, just make that a convention
>>
>> cheers,
>> jesse
>>
>> --
>> jesse mcconnell
>> jesse.mcconnell@xxxxxxxxx
>>
>>
>>
>> On Fri, Nov 4, 2011 at 17:56, Greg Wilkins <gregw@xxxxxxxxxxx> wrote:
>>> I understand the benefits of having a module contained in a single
>>> directory, but I'm not sure that the benefits are worth the extra
>>> complication.
>>>
>>> The start.jar mechanism (while simple enough) already causes some
>>> confusion because lib/foo/foo.jar  is not automatically put onto the
>>> classpath, unless the OPTIONS=foo is included.     Having yet another
>>> location to mix in modules, is only going to increase that confusion.
>>>
>>> I'd really like the module utility to be about how a jetty is
>>> assembled and not about how jetty runs.
>>>
>>> I also don't see why remove is any harder with using the lib
>>> directory.   Essentially the tool will have to do
>>>
>>>   rm -fr lib/foo etc/jetty-foo.xml
>>>
>>> instead of
>>>
>>>  rm -fr plugins/foo
>>>
>>> In either case, the tool doing the remove will need to update
>>> start.ini to reflect the change.   I'm also kind of partial to having
>>> meta data about all the files of a module, including a checksum - so
>>> if you go to remove a module and the jetty-foo.xml file has been
>>> modified, then you will get a warning about that and have to confirm
>>> the deletion.
>>>
>>>
>>> cheers
>>> _______________________________________________
>>> 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
>>
> _______________________________________________
> jetty-dev mailing list
> jetty-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/jetty-dev
>


Back to the top