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

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.

> Ideas? > > Cordialement / Best, > Chris > > == > Principal Software Engineer / JBoss Enterprise Middleware Red Hat, Inc. > Follow GateIn: http://blog.gatein.org / http://twitter.com/gatein > Follow me: http://metacosm.codepuccino.com / http://twitter.com/metacosm > > > _______________________________________________ > gatein-dev mailing list > gatein-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/gatein-dev _______________________________________________ gatein-dev mailing list gatein-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/gatein-dev