Re: OutOfMemory/Classloader Question regarding portlet container

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
>>>
>>>