"Kevin A. Burton" wrote:
>
> 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.
>
Yeah, I remember now why I don't see these interfaces used so often... :(
> > - 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()
>
That's a possibility, such a construct would require that a markup for the
PortletControllerConfig to be stored with each user config and would also
make panes controller specific... yes, that can work.
> <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.
>
Do you mean you want to insert a CacheContentPortlet between the
PortleControland the real Portlet such as
PortletControl -> CacheContentPortlet -> RealPortlet
The CacheContentPortlet implements the Portlet API and delegates all
the calls to RealPortlet except getContent() and getContent(PC) that would
be checked against a memory/disk cache ?
That would require many instances of CacheContentPortlet running, since each
would be linked to a specific RealPortlet... stateful portlets... not good.
Am I missing something here ?
> 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().
>
I don't understand this. The CacheContentManager (CCM) would be part of the
Engine and completely transparent to the Portlet developer.
In case of crash or reboot, the CCM would not even need to
instanciate dummy portlets since they won't be called if the cache is valid,
there's simply a need for a Recovery mode in the CCM which would always
consider cache info valid and start a thread which would:
- recreate instances of a portlet
- regenerate cache entries
- reset expiration date on each regenerated entry
Plus this construct can either be implemented as a singleton or a pool of
objects to increase availability while limiting general resource consumptions
> 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?
>
Agreed on the masking of implementation details, but I think I missed one of
your points because I don't see any advantage to the ContentCachePortlet.
> <snip>
> >
> > 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.
>
+1000. IMO, the difficulty in OSS is getting the appriopriate level of mind
reading necessary to understand where the project is going... :)
--
Rapha�l Luta - [EMAIL PROTECTED]
--
--------------------------------------------------------------
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]
