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

On Jan 26, 2011, at 5:19 PM, Julien Viet wrote: > 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). Does that mean that GateIn cannot be started then stopped then a WSRP.ear added and correctly handled?

>> 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. I don't care about hot (re-)deployment at the moment (though I have to note that it was kind of possible with JBoss Portal). > So Java EE sucks :-) > > (that being said, the WSRP JSF administration should be hot redeployable as it's a consumer of the shared classes). 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