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
_______________________________________________
gatein-dev mailing list
gatein-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/gatein-dev