[gatein-dev] Extracting WSRP (modularization of services and configuration)?
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 that 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