Hello,
Now that I have a decent network connection again, I'll commit the bunch of changes
I've done over the week-end once I've catched up with my real work...
Here are a list of modifications :
Services:
=========
I've created a couple of services.
What I have ready:
* EngineContext
This is the EngineContext service written by Jeff in which I removed all
obsolete code.
* PortletCache
This service is an adaptation of the PortletCache system. I removed the dependency on
the Cocoon MemoryStore and used instead the TurbineGloablCache service as a backend.
As it is, the PortletCache is mainly used for bridging the old caching semantics of
Jetspeed and the TurbineGlobalCache semantics. It'll need to be modified when the
caching semantics will be refactored.
I had to remove the MemoryStorePortlet functionality because the GlobalCache does not
currently support monitor operations. It would be a good thing to add it and send the
patches to the Turbine list.
* URLManager
This started as a port of the BadURLManager code but morphed into a new service. The
idea behind the idea is : why have a service that only deal with bad urls when you can
have a service that deal with any URL and affects them a status ?
So the URLManager is just that: a central clearing house for registering URLs and their
status (which can be extended to also store their next update date, caching status,
etc...).
Since this require a lot of change in JetspeedDiskCache and associated classes which
Santiago is working on, I currently only use it to emulate the BadURLManager behavior
(ie store only the bad URLs).
It's fairly untested because I did not have a real internet connection for testing
during the week-end so it may take a few days to make it work well but it doesn't
break the basic operation of Jetspeed. If you find bugs in it, please send patches.
So that leaves the following services to write urgently to completely remove the
use of the JetspeedServlet:
* registry
* daemon
* cocoon
I'll tackle Cocoon next. Registry and Daemons may require more thought because they
aren't singletons.
Architecture
============
I've changed a little the src package architecture and remove some unused classes.
Mainly I renamed the 'turbine' package to 'modules' in order to match the standard
Turbine naming conventions.
This means that the 'localization' subpackage should certainly move because it's not
a 'module' in the Turbine sense but I'm not sure yet where these classes should
belong.
Speaking about package organisation, I think the target architecture should be
something like:
jetspeed
modules/
screens/
navigations/
layouts/
localization/ ???
om/
portal/ (portal object model: Portlet, PortletSet, etc...)
peer/ (Persitense dependant implementations)
syndication/ (syndcation object model: URLInfo, etc...)
peer/ (Persitense dependant implementations)
services/
profiler/ (layout)
capability/ (layout)
portletcache/ (layout)
cocoon/ (layout/templating)
xsl/ (layout/templating)
urlmanager/ (syndication/CMS)
diskcache/ (syndication/CMS)
feeddaemon/ (syndication)
contentdaemon/ (CMS)
castor/ (persistence, Object Relational model)
Does that make sense for everybody ?
--
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://marc.theaimsgroup.com/?l=jetspeed>
Problems?: [EMAIL PROTECTED]
