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