Rapha�l Luta wrote:
<snip>
> The problem with this name is twofold:
> - if it's a XXXSet, then it people may expect it to extend the java.util.Set
> interface. Do we really want to implement this interface on our object ?
> (I'd say yes)
-1. That is Java2 only :( There is no reason we can implement all the
methods but just to implement the interface.
> - what if we want to use this object to allow the controller to retrieve a
> Config object:
> PortletSet.getControllerConfig() or PortletSet.getPanes() doesn't ring so well
> to me...
That would probably be in the controller. The PortletSet would just be
the content not its representation. So:
PortletController.getPortletControllerConfig().getPanes()
<snip>
> Well, the way I would see the process is:
>
> Class X (for example PortletControl) needs a Portlet PO with config PC:
> Call PortletFactory.getPortlet(PO,PC)
> - if PO declared stateful portlet:
> - check if CacheHandleManager has an instance created and
> return it
> - else create a new PO with PC.
> - if PO stateless:
> - get a PO from available pool and return it
> Call ContentCacheManager.getContent(PO,PC)
> - if content already generated, get it from store (either memory, file,
> DB, etc...) and return it
> - else call Portlet.getContent(PC)
> - if PO stateful, getContent(PC) <=> getContent()
> - else renders content with PC info.
>
> The advantages of this method over the one currently implemented is that
> ContentCacheManager can implement consistently any caching strategy, such
> as storing the rendered content on disk, which the indivdual portlets
> can't.
I was thinking the same thing for this. We should provide a mechanism
that can restore Jetspeed to a running config should the whole thing
die. You are right but I just think that we should build the
restoration mechanism separate from the actual portlet implementation.
Why?
Portlets can do things that we would never imagine. That is why they
are in interface. What I want to do is provide a CacheContentPortlet
that we can substitute for the real portlet.
Here is what we would do.
- Jetspeed crashes or is shut down for some reason.
- Machine comes back up but we don't want it to recreate 1500 Portlets
as this would take a *long* time.
What we would do is just create a dummy portlet that we put our old
Portlet cache in. This way we can serve up portlets with the old
content for a finite amount of time. Then we would create a low
priority thread that would go about re-instantiating the correct portlet
and swap out the cache instance of the DummyPortlet with the correct
Portlet.
Make sense? That is the best way I can think of doing it.
I originally thought of a mechanism similar to the one you have above
but the problem is that we have to rely on our Portlets correctly
implementing the content restoration. They could get by this and just
provide NO OP code and then they would actually start doing work on
getContent().
This would be a Bad Thing and would screw over Jetspeed. That and it is
Engine specific code. The point being that Jetspeed is a Portal
Application server and when you develop under it you shouldn't have to
worry about the implementation details of crash persistence, etc.
Thoughts?
> > Note that with the servlet API as it already is you can tell the Factory
> > not to cache it. Thus if you have a web app that always changes or
> > would otherwise waste *tons* of memory just tell it not to cache, or
> > handle the caching portion yourself.
> >
>
> I agree that WebApps should be left from the caching system as they may have
> very complex operation.
Yeah. This needs to be in the docs. The other point is that for some
situations it would make *no* sense to cache Applications. For example
a mail application that gets your mail and displays it on the screen
would just go right through the cache and out the other side. Because
it isn't a hot spot and would really not be called again.
> > This might be an issue for developer docs. What do you think. I
> > Engineered it to do this but I am not sure it was obvious except if you
> > looked at the code... hmmm. It will be in there for 1.1.
> >
>
> I certainly feel some developer docs is needed to understand Jetspeed
> (and turbine) architecture, esp since the interfaces are still somewhat in
> flux. Do you have some kind of OMT/UML schemas for Jetspeed available or should
> we put this the TODO list ?
<snip>
No UML. But it is big. OSS is awesome but only if the communications
channels are high bandwidth. UML will help broaden that. I will jump
on that after 1.1 ships.
Kevin
--
Kevin A Burton ([EMAIL PROTECTED])
http://relativity.yi.org
Message to SUN: "Please Open Source Java!"
"For evil to win is for good men to do nothing."
--
--------------------------------------------------------------
Please read the FAQ! <http://java.apache.org/faq/>
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Archives and Other: <http://java.apache.org/main/mail.html>
Problems?: [EMAIL PROTECTED]
