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 warAbout 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@redhat.com> 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@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/gatein-dev
--
Patrice Lamarque
VP Platform
eXo Platform SAS
gatein-dev mailing list
gatein-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/gatein-dev