Hi Ben,
[EMAIL PROTECTED] wrote:
David,
Thanks for the advice. I went ahead and did all the work and then noticed
a few days later that version 1.1.3 was released with simple portlet
support, so it was kind of a waste of time. Although, it was interesting
to get my hands dirty and see what was under the hood. I think that the
simple portlet support should meet my needs. Do you have any
documentation on it? I think that I can get it working based on the
/about.jsp example, but some extra info would be useful. If you don't
have any docs on it, I can write down the steps I take and give it to you
if you like.
Please do, we can always use these kinds of examples. You can either
create and post a document on the Portals Wiki,
http://wiki.apache.org/portals/Pluto or better yet create a Jira issue
https://issues.apache.org/jira/browse/PLUTO with your patch or document
and we'll get it up on the offical Pluto website.
As for the "addressable URLs", I wanted something similar to the feature
described in the following article:
http://www.ibm.com/developerworks/websphere/library/techarticles/0607_hesmer/0607_hesmer.html#N1030A.
Basically, it looks like WAS 6.1 allows you to target a portlet on a page
with mode/state/action/render parameters very easily. I thought this
would be useful for functional testing, etc. If there's any interest,
I'll make my solution open source.
Anyhow, I think that Pluto is becoming very easy to integrate. I tried
doing some of this stuff about year ago with an earlier version and found
it difficult. Kudos to the development team; Thanks for all your hard
work.
Thanks for the feedback,
Elliot
Sincerely,
Ben
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
