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

On Jan 26, 2011, at 8:06 PM, Patrice Lamarque wrote: Hello Christophe, I'll try to share some of my knowledge about the extension mechanism. Hopefully it will answer some of your questions. The extension mechanism let's you : * plug your own kernel config from your own war instead of portal.war (kernel will load it from yourextension.war/WEB-INF/conf/configuration.xml) * extend the /portal servlet context so that it can serve resources from your own war About the question of JCR workspaces, the extension mechanism is able to merge all repository-configuration.xml it finds. So to declare your workspaces, just place them in a repository-configuration.xml inside your extension war at the exact same location you'll find it in portal.war. I didnt know about that, is it referenced somewhere ? HTH. On Wed, Jan 26, 2011 at 4:26 PM, Christophe Laprun <claprun(a)redhat.com&gt;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). > > 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. 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? 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 ^_^)? > > 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 > -- *Patrice Lamarque* VP Platform eXo Platform SAS _______________________________________________ gatein-dev mailing list gatein-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/gatein-dev