Re: [gatein-dev] Extracting WSRP (modularization of services and configuration)?

On Jan 26, 2011, at 5:06 PM, Matt Wringe wrote: > On Wed, 2011-01-26 at 16:26 +0100, Christophe Laprun wrote: >> Hi, >> >> I'm trying to extract as much WSRP code as possible from GateIn so >> that the WSRP service can be updated without having to update GateIn >> itself and, ideally, be able to package it in a single (ear?) file so >> that it can easily be removed without having configuration files all >> over the place. >> >> In this process, I'm running into several issues: >> >> 1. The extension mechanism documentation is rather poor at the moment. >> Nowhere is it explained what extensions are good for, what can they be >> used for and, more importantly, what *can't* they used for. For >> example, it is not clear to me whether I could package the WSRP >> service as an extension (though I'm pretty sure I can't). > > You should be able to provide it as an extension, depending on what you > want to do with it. > The documentation for eXo kernel isn't very good, and its spread around > in different locations. > >> 2. WSRP-related configuration is, at the moment, spread among several >> files located at different spots making it very difficult to extract >> so that it can be removed (or added to a bare portal install). For >> example, the main configuration file is located in >> web/portal/src/main/webapp/WEB-INF/conf/wsrp/wsrp-configuration.xml >> which is linked to by the main configuration.xml file. It would be >> good if this file (and the linked ones) could, at the very least, be >> moved to the component/wsrp module and dynamically picked-up at >> runtime by the kernel. I don't know if this is possible, it might just >> be a lack of kernel knowledge on my part. > > You can add the configuration file through the extension mechanism (its > what the extension mechanism is meant for), so you can move it to > another module. > >> However, even if extracting these files (and avoiding to have to link >> to them in the main configuration.xml file) was possible, there are >> still other dependencies left to be extracted. In particular, WSRP >> needs to create JCR workspaces and at the moment, these need to be >> defined in repository-configuration.xml. Is it possible to split that >> file so t! >> hat services can dynamically add new workspaces to the JCR repository >> as needed at runtime? > > don't know about the JCR configuration stuff :( > >> On that note, a lot of that configuration is pretty much similar for >> all the workspaces. Wouldn't it make sense to have reasonable default >> values that users would override only if needed to avoid having long >> and error-prone XML configuration? >> >> 3. The design of the ApplicationRegistryService makes it difficult to >> support WSRP because of the assumption it makes on the format of >> portlet identifiers leading to lots of hardcoded information and >> if-else cases which makes the code brittle and difficult to evolve. >> Independently of WSRP support, it would break if the portlet container >> was ever to change its identifier format. I would like to start a >> discussion on fixing this issue even though I know this is not the >> priority at the moment. >> >> TL,DR summary: What would be the best way to extract and package the >> WSRP-related code so that it could be added/removed dynamically (while >> the server is stopped at least, though, of course, hot-deploy would be >> even better ^_^)? > > You can't dynamically add or remove things right now with the exo > kernel. > With the extension mechanism it requires that the ear be deployed when > the server is started for the _first_ time. If you add or remove it > after, it wont work (and will fill your logs with a bunch of errors).

> So if the wsrp.ear is available when the server first starts, its added. > If the wsrp.ear is removed before the server is first started, its not > added. > It sucks, which is why we need a proper xml based deployment > implementation. One technical constraint preventing hot redeployment is the lack of shared classes between applications in Java EE, this is required for many parts of GateIn.

So Java EE sucks :-) (that being said, the WSRP JSF administration should be hot redeployable as it's a consumer of the shared classes).