1:06 p.m.
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.
HTH.
On Wed, Jan 26, 2011 at 4:26 PM, Christophe Laprun <claprun(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/gatein-dev
--
*Patrice Lamarque*
VP Platform
eXo Platform SAS