Is it safe to assume that the cvs is unstable. It
seems lots of changes are being put through, and this
makes it difficult to make the configuration work.
Are you planning on stablizing jetspeed soon? I have
been tring to get the cvs version to work. Should i
go back to the released version until this is stable?
I would really like to use cvs code, so I can modify
it to fit some specific needs. Thanks,
Anthony Mills
--- Santiago Gala <[EMAIL PROTECTED]> wrote:
>
>
> Raphael Luta wrote:
>
> > 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.
> >
>
> The idea is good. The whole idea of having a
> ResourceManager goes along the same lines.
> feeddaemon, badurlmanager and diskcache are our
> simple implementations of this manager.
>
> > 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.
>
> See below: turbine.localization, if it is related to
> turbine modules, or
> jetspeed.localization if it is abstract.
>
> >
> >
> > 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)
> >
>
> I thought that the portlet API (interfaces) would go
> into org.apache.portlet, and then the
> implementation under org.apache.jetspeed.portal (or
> something similar). In this way, we
> distinguish between the (I hope abstract) Portlet
> API and our buggy and dirty
> implementation of it :-)
>
> Also, I prefer that turbine modules would go into a
> turbine.modules package, to stress that
> there we store the glue between Jetspeed and
> Turbine. If we had alternate implementations
> of the Portlet API (for instance, for pure XML
> portlets, or for Stream oriented portlets)
> they would go into different packages. Also, we
> could use turbine.rundata for our
> extensions of RunData, ParameterParser, etc.
>
>
>
> My two cents (Eurocents, of course) :-).
>
> >
> > 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]
>
>
>
> --
>
--------------------------------------------------------------
> 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]
>
__________________________________________________
Do You Yahoo!?
Yahoo! Shopping - Thousands of Stores. Millions of Products.
http://shopping.yahoo.com/
--
--------------------------------------------------------------
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]
