incubator-wadi-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bill Dudney <>
Subject Re: WADI configuration...
Date Thu, 05 Jan 2006 13:09:11 GMT
Hi Jules,

On Jan 4, 2006, at 4:32 AM, Jules Gosnell wrote:

> Here is my contribution:
> WADI's existing configuration mechanism uses Spring to construct  
> and wire together a relatively large number of POJOs. This gives  
> WADI a flexible and extendable approach with a zero-overhead  
> configurer - i.e. no code other than Spring and the POJOs  
> themselves is required. POJOs may be declared to the container and  
> hooked into its management services et al. via e.g. the Spring  
> MBeanExporter, which may be given a list of Beans and will register  
> them as MBeans with the local JMX agent.
> Currently, The Spring config is held in each webapp's WEB-INF/wadi- 
> web.xml.
> I would like to address two issues :
> 1) How (do we instantiate, wire together and integrate the POJOs  
> into the container) ?
> 2) Where (do we do this - at the webapp or container level) ?
> (2) is easier, so I will deal with it first.
As you say I think we have to provide the ability to do both per app  
and per container configuration. From my work on configuration  
simplification I think there are several things we can do to make it  
much easier to do both.
> At the moment, WADI only addresses the per-webapp approach. This is  
> very useful for dropping a WADI-enabled webapp into an (almost)  
> vanilla container (i.e. an off-the-shelf TC with a few jars  
> sprinkled over it), but a less useful approach when dealing with  
> cases where the container itself wants to manage the clustering  
> resources and share them between apps/tiers.
> I want to retain the per-app config, but also allow configuration  
> by default on a per-container basis. In the same way as Jetty and  
> TC have a default web.xml and webapps have a WEB-INF/web.xml  
> (except that whereas these are overlaid, I think WADI's configs  
> will need to be exclusive).

I'm not convinced that we must have exclusive configuration  
information. I would prefer for the user to have the flexibility of  
lets say specifying the # of partions in their web app but the  
default number being 64 (which would be specified at the container  
level). By that I mean that the user could configure their container  
to manage the clustering configuration and resources but the  
individual web apps would also be able to specify configuration  
details as well. I'd expect the per web app configuration would take  
precedence over the configuration that is specified at the container  

There is code (forget if its in apache or codehause) that takes the  
first step towards this goal in the TC 5.5 bits. I posted a long note  
about that when I did it. Maybe we could resurrect that thread and  
discuss further there? I'll see if I can dig it up.

> Inititially, we may be able to support this mode of use in Geronimo  
> and standalone Jetty as it will most likely involve small scale  
> changes to the container itself. Ultimately, I would like to see  
> this facility available in standalone TC as well, and, who knows -  
> maybe in JBoss via a WADI MBean and a per webapp hookup to this  
> MBean...
> As far as other tiers go, we need to draw Gianny into this  
> conversation and discover more about the OpenEJB approach. Gianny -  
> are you there ? I would like to see a similar ability in the EJB  
> tier. I've noticed that Gianny has recently committed some form of  
> WADI/OpenEJB GBean. This looks very interesting and is the  
> beginnings of what I see as the per-container approach. Ultimately,  
> I imagine that something like this GBean will be shared between  
> Web, EJB and maybe POJO tiers, along with a single container-wide  
> configuration.

> (1)
> This is a thornier issue.
> On the per-app side of things - Another of WADI's goals has been to  
> ensure that you can shrinkwrap a WADI-enabled app and run it on any  
> WADI-integrated container without changes. This is important as I  
> foresee a number of different standard WADI configs arising and I  
> think it would be a very bad idea to have to support different  
> versions of every config on a growing number of containers. I also  
> think that the whole J2EE experience shows us that users want  
> portable solutions, so a WADI webapp should be portable without  
> changes.

I totally agree that this is very important, we cant support anything  
else IMO it'd just be too much overhead.

> On the per-container side of things - I'm not so worried about how  
> container-wide config is stored, although I would still advise the  
> use of an LWC because of the breadth, granularity and ever-changing  
> nature of the WADI API. If an LWC is used, then it seems sensible  
> to use the same one as is used for the per-app approach.

I'd push for an LWC as well, no sense in reinventing that wheel.

> Integration with container services - in JMX enabled containers  
> (Jetty, TC, JBoss) WADI uses, as described above, the Spring  
> MBeanExporter to expose certain internals to the container's  
> management services (check out the mc4j integration page at the  
> website - 
> jmxmonitoring.html). I am unclear as to exactly what should be done  
> in Geronimo if the LWC argument carries the day (which I hope it  
> will, since this will allow the sharing of per-container configs  
> between different containers), but I have discussed this with  
> Greg&Jan and Jeff and there seem to be a number of solutions all  
> available via the same sort of exporter pattern currently in use. A  
> while ago I wrote a Spring integration module for Geronimo which  
> injected proxy wrapped POJOs directly into the Geronimo kernel in  
> order to expose them to management. Worst comes to worst, this code  
> could be quickly resuscitated, although I expect that either the  
> MBean exporter, some technology available from the XBean project or  
> a reworked XBean-based Geronimo kernel will provide the ultimate  
> solution.

Doesn't G already have an LWC integrated into the kernel. From what I  
recall there was an expiermental spring kernel thing happening back  
in June.

> I think that that just about sums up my current thinking on the  
> subject, I look forward to a useful discussion.
> Jules
> P.S.
> One issue that I have come across with the LWC approach so far is  
> that of lifecycle - Spring is able to register POJOs with the  
> container on construction, but deregistering them on destruction is  
> trickier, since Spring (at the moment) is not really involved in  
> the rest of a WADI bean's lifecycle. My understanding is that XBean  
> gives more control over bean lifecycle, so I am hoping that this is  
> the way forward. Would anyone like to comment ? Is anyone following  
> up the XBean thread and investigating the benefits and costs of a  
> Spring->XBean migration ?

Its fairly easy to get your beans to be spring life-cycle aware. We  
don't have to go to XBean to make that happen but I'm glad to help  
with which ever approach we take.

I'm all for the move to XBean though, it makes the xml sooo much  
easier to read.

> -- 
> "Open Source is a self-assembling organism. You dangle a piece of
> string into a super-saturated solution and a whole operating-system
> crystallises out around it."
> /**********************************
> * Jules Gosnell
> * Partner
> * Core Developers Network (Europe)
> *
> *
> *
> * Open Source Training & Support.
> **********************************/

View raw message