You should be able to do everything you're attempting to do without all
of the work :)
In other words, if you simply bundle pluto as-is in your WEB-INF/lib, it
will naturally only support one context. There's even a property you
can set to ensure that cross context dispatching doesn't occur.
I'm not sure what you mean by "addressable" URLs, but if you're looking
for simple portlet support within a webapp, where a simple url invokes
some hard coded portlets in a jsp, there's a filter which allows you to
do just that.
As for the out of memory error, I have not encountered it. The default
portlet registry is one place where singletons are used. . .but you said
you modified that. . .
David
[EMAIL PROTECTED] wrote:
Hi all,
I believe this is correct forum for this question, but if it is not,
please let me know.
I have a need to implement a portlet container that runs inside of a web
application (i.e., it runs as a component of the portlet application that
it is managing). In order to achieve this, I reimplemented the following
Pluto container services:
PortletInvokerService - changed so that it does not use cross-context
dispatching, and does not support admin requests.
PortletRegistryService - changed so that it only supports one application
context per instance.
PortalCallbackService - changed to support addressable URLs
I also reimplemented PortletEnvironmentService and PortletInfoService, but
the changes were trivial, and they pretty act the same as the default
implementations.
All of this worked fine, and passed all of the test suite tests except for
one. However, my problem is that when I place pluto-container.jar,
pluto-descriptor-api.jar, pluto-descriptor-impl.jar, and pluto-tags in my
webapp's WEB-INF/lib directory, if the application gets restarted without
restarting Tomcat (v5.5) the memory is not released. As the context gets
constantly restarted during development, eventually I get a PermGen
OutOfMemory error and the server crashes. The Tomcat Wiki
(http://wiki.apache.org/tomcat/OutOfMemory) seems to suggest that this
could be a result of the singleton pattern. If I move the Pluto jars so
that they are loaded by the shared classloader, I do not get the PermGen
errors any more. My question is, is there a way to release the singleton
resources used by the Pluto container upon a shutdown of the servlet
context? Also, is this really a Pluto issue, or do you think that I am
doing something wrong? I am planning to do some slight refactoring of the
singletons in the portlet container in order to make it possible for me to
the release the resources, but I would like to make sure that there is not
already a tested/stable solution.
I realize that this is probably not a common use of the portlet container,
but I have shared hosting that prevents me from using multiple contexts or
utilizing shared libraries. Thanks in advance for any help that you might
be able to provide.
-- BCG
