Plugin initialization

5 messages Options
Embed this post
Permalink
glenn_engel

Plugin initialization

Reply Threaded More More options
Print post
Permalink
I seem to recall some discussion about automatic plugin startup being planned.  One of the really nice things about confluence is that you can add plugins with just a jar file and don't have to edit .xml configuration files.   This also makes upgrades of either the plugin or wiki easier as everything is in the jar.

 

Was anything like this added for 2.0 or possibly planned in the near future?

 

--

Glenn

_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
vmassol

Re: Plugin initialization

Reply Threaded More More options
Print post
Permalink
Hi Glenn,

On Jul 1, 2009, at 9:54 PM, <[hidden email]> wrote:

> I seem to recall some discussion about automatic plugin startup  
> being planned.  One of the really nice things about confluence is  
> that you can add plugins with just a jar file and don't have to  
> edit .xml configuration files.   This also makes upgrades of either  
> the plugin or wiki easier as everything is in the jar.
>
>
>
> Was anything like this added for 2.0 or possibly planned in the near  
> future?

Yes definitely. This is how it works already. Plugins are the old way  
of extending xwiki. The new way is to use components. For example if  
you implement a Macro component and put it in WEB-INF/lib it'll be  
automatically available.

-Vincent

_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
glenn_engel

Re: Plugin initialization

Reply Threaded More More options
Print post
Permalink


> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]] On Behalf
> Of Vincent Massol
> Sent: Wednesday, July 01, 2009 1:34 PM
> To: XWiki Developers
> Subject: Re: [xwiki-devs] Plugin initialization
>
> Hi Glenn,
>
> On Jul 1, 2009, at 9:54 PM, <[hidden email]> wrote:
>
> > I seem to recall some discussion about automatic plugin startup
> > being planned.  One of the really nice things about confluence is
> > that you can add plugins with just a jar file and don't have to
> > edit .xml configuration files.   This also makes upgrades of either
> > the plugin or wiki easier as everything is in the jar.
> >
> >
> >
> > Was anything like this added for 2.0 or possibly planned in the near
> > future?
>
> Yes definitely. This is how it works already. Plugins are the old way
> of extending xwiki. The new way is to use components. For example if
> you implement a Macro component and put it in WEB-INF/lib it'll be
> automatically available.
>


How about a servlet?  Is there a similar way to do this without editing web.xml?  I suppose if there was something I could put into the jar that would automatically get an init method of some kind then I could in theory add my servlet url with java code.

I noticed my Macro component didn't get instantiated/initialized until it was referenced.

Are there other types of Components I should be aware of?

Thanks for explaining this.



> -Vincent
>
> _______________________________________________
> devs mailing list
> [hidden email]
> http://lists.xwiki.org/mailman/listinfo/devs


_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
vmassol

Re: Plugin initialization

Reply Threaded More More options
Print post
Permalink

On Jul 1, 2009, at 10:45 PM, <[hidden email]> <[hidden email]
 > wrote:

>
>
>> -----Original Message-----
>> From: [hidden email] [mailto:[hidden email]] On  
>> Behalf
>> Of Vincent Massol
>> Sent: Wednesday, July 01, 2009 1:34 PM
>> To: XWiki Developers
>> Subject: Re: [xwiki-devs] Plugin initialization
>>
>> Hi Glenn,
>>
>> On Jul 1, 2009, at 9:54 PM, <[hidden email]> wrote:
>>
>>> I seem to recall some discussion about automatic plugin startup
>>> being planned.  One of the really nice things about confluence is
>>> that you can add plugins with just a jar file and don't have to
>>> edit .xml configuration files.   This also makes upgrades of either
>>> the plugin or wiki easier as everything is in the jar.
>>>
>>>
>>>
>>> Was anything like this added for 2.0 or possibly planned in the near
>>> future?
>>
>> Yes definitely. This is how it works already. Plugins are the old way
>> of extending xwiki. The new way is to use components. For example if
>> you implement a Macro component and put it in WEB-INF/lib it'll be
>> automatically available.
>>
>
>
> How about a servlet?  Is there a similar way to do this without  
> editing web.xml?  I suppose if there was something I could put into  
> the jar that would automatically get an init method of some kind  
> then I could in theory add my servlet url with java code.

The servlet spec *mandates* a web.xml (except in Servlet 3.0 which  
just came out) so there's no way to have a servlet without a web.xml  
entry.

However why do you need a servlet? It's not required in most cases I  
can think of since you can have a component instead? Maybe you could  
tell us your use case so that we could help you better?

> I noticed my Macro component didn't get instantiated/initialized  
> until it was referenced.

Yes, that's the default. What's your need? We could add the feature to  
load some specific components on startup in the future if there's a  
need. Right now you can receive the startup event and do some specific  
init at that time.

>
> Are there other types of Components I should be aware of?

Not sure I understand. Everything is a component and can be replaced  
or extended (except for old code not yet migrated to components).

Do you have a specific use case?

Thanks
-Vincent

_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
glenn_engel

Re: Plugin initialization

Reply Threaded More More options
Print post
Permalink


> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]] On Behalf
> Of Vincent Massol
> Sent: Wednesday, July 01, 2009 1:58 PM
> To: XWiki Developers
> Subject: Re: [xwiki-devs] Plugin initialization
>
>
> On Jul 1, 2009, at 10:45 PM, <[hidden email]>
> <[hidden email]
>  > wrote:
>
> >
> >
> >> -----Original Message-----
> >> From: [hidden email] [mailto:[hidden email]] On
> >> Behalf
> >> Of Vincent Massol
> >> Sent: Wednesday, July 01, 2009 1:34 PM
> >> To: XWiki Developers
> >> Subject: Re: [xwiki-devs] Plugin initialization
> >>
> >> Hi Glenn,
> >>
> >> On Jul 1, 2009, at 9:54 PM, <[hidden email]> wrote:
> >>
> >>> I seem to recall some discussion about automatic plugin startup
> >>> being planned.  One of the really nice things about confluence is
> >>> that you can add plugins with just a jar file and don't have to
> >>> edit .xml configuration files.   This also makes upgrades of either
> >>> the plugin or wiki easier as everything is in the jar.
> >>>
> >>>
> >>>
> >>> Was anything like this added for 2.0 or possibly planned in the
> near
> >>> future?
> >>
> >> Yes definitely. This is how it works already. Plugins are the old
> way
> >> of extending xwiki. The new way is to use components. For example if
> >> you implement a Macro component and put it in WEB-INF/lib it'll be
> >> automatically available.
> >>
> >
> >
> > How about a servlet?  Is there a similar way to do this without
> > editing web.xml?  I suppose if there was something I could put into
> > the jar that would automatically get an init method of some kind
> > then I could in theory add my servlet url with java code.
>
> The servlet spec *mandates* a web.xml (except in Servlet 3.0 which
> just came out) so there's no way to have a servlet without a web.xml
> entry.
>
> However why do you need a servlet? It's not required in most cases I
> can think of since you can have a component instead? Maybe you could
> tell us your use case so that we could help you better?
>
> > I noticed my Macro component didn't get instantiated/initialized
> > until it was referenced.
>
> Yes, that's the default. What's your need? We could add the feature to
> load some specific components on startup in the future if there's a
> need. Right now you can receive the startup event and do some specific
> init at that time.
>

Let me describe a bit more.  We have a servlet we're porting from confluence.  The servlet has it's own custom api for doing special actions which is utilized by some ajax js (via macros) as well as flash applications.  The servlet is "mostly" independent from the wiki except for some user permission checks.  

The need is to have a known url that can be invoked as a servlet service before or after any xwiki pages have been accessed.

In confluence one could define in atlassian.xml a servlet similar to adding to xwiki web.xml.  The servlet would then be subservient to a url like /plugins/servlet/myplugin for the 'myplugin' servlet.  I suppose if xwiki had a web.xml defined servlet that allowed adding children that would be sufficient.

Currently I have a web.xml entry for xwiki that works of course but it would be nice to avoid editing web.xml on every install or xwiki upgrade.

P.S.  When I added an EventListener interface to a component I get the following at startup:

java.lang.RuntimeException: Failed to find the Observation Manager component
        at org.xwiki.container.servlet.XWikiServletContextListener.contextInitialized(XWikiServletContextListener.java:79)
        at org.mortbay.jetty.handler.ContextHandler.startContext(ContextHandler.java:548)
        at org.mortbay.jetty.servlet.Context.startContext(Context.java:136)
        at org.mortbay.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1239)
        at org.mortbay.jetty.handler.ContextHandler.doStart(ContextHandler.java:517)
        at org.mortbay.jetty.webapp.WebAppContext.doStart(WebAppContext.java:466)
        at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
        at org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:152)
        at org.mortbay.jetty.handler.ContextHandlerCollection.doStart(ContextHandlerCollection.java:156)
        at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
        at org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:152)
        at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
        at org.mortbay.jetty.handler.HandlerWrapper.doStart(HandlerWrapper.java:130)
        at org.mortbay.jetty.Server.doStart(Server.java:224)
        at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
        at org.mortbay.xml.XmlConfiguration.main(XmlConfiguration.java:985)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
        at java.lang.reflect.Method.invoke(Unknown Source)
        at org.mortbay.start.Main.invokeMain(Main.java:194)
        at org.mortbay.start.Main.start(Main.java:523)
        at org.mortbay.start.Main.main(Main.java:119)
Caused by: org.xwiki.component.manager.ComponentLookupException: Failed to lookup component [role = [org.xwiki.observation.ObservationManager] hint = [default]]
        at org.xwiki.component.embed.EmbeddableComponentManager.initialize(EmbeddableComponentManager.java:263)
        at org.xwiki.component.embed.EmbeddableComponentManager.lookup(EmbeddableComponentManager.java:93)
        at org.xwiki.container.servlet.XWikiServletContextListener.contextInitialized(XWikiServletContextListener.java:76)
        ... 22 more
C

> >
> > Are there other types of Components I should be aware of?
>
> Not sure I understand. Everything is a component and can be replaced
> or extended (except for old code not yet migrated to components).
>
> Do you have a specific use case?
>
> Thanks
> -Vincent
>
> _______________________________________________
> devs mailing list
> [hidden email]
> http://lists.xwiki.org/mailman/listinfo/devs


_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs