Santiago Gala wrote:
>
> Raphael Luta wrote:
>
> >
> > Point 2: Cocoon support
> > In my TODO list for 1.2, I mentioned that the Cocoon
> > support was a hack and was going to fail with Cocoon 1.8.
> >
> > I proposed to remove completely its use from the engine
> > (thus affecting MemoryStore and a few basic functionalities
> > like PortletBrowser, etc...). I think CocoonPortlet should
> > be kept but as a Portlet example, not something we rely on.
> >
> > I'm +1 on this.
> >
>
> I would say -1 until after this weekend. I'll be working on
> Cocoon-Jetspeed integration issues with Ricardo Roche during the weekend
> in Madrid, and I would like to have this point freezed until I discuss
> the integration with him. After the discussion, we can have clearer
> ideas.
>
> I would like to know what are the hot issues with respect to integration
> with Cocoon 1.8, as he told me that he believed that adding proper
> support for Cocoon looked like a simple work. It may be that we have
> proper 1.8 support after the weekend.
>
> More informed opinions? If the issues justify it, I could be convinced
> before the week end. But I think having Ricardo working with us could
> solve a lot of issues. It is important, though, that we post our
> conclusions so that we can have a public discussion on the Cocoon
> support.
>
Actually the issue is threefold:
- currently the Engine needs to initialize the Cocoon engine because
it uses its MemoryStore component for caching in memory portlets.
This implies that Cocoon *must* be correctly configured in order
for Jetspeed to run at all, which adds to the install complexity
and generates FAQ to the mailing-list.
Turbine now offers perfectly good caching services natively and
I think it would make life easier for everybody.
- Jetspeed uses some XSP for some basic functionalities prototypes
(such as PortletBrowser or Customizer). Providing these functions
through an external system (Cocoon) rather than develop it on the
main framework is IMO an error because it makes the architecture
kludgy and hard to maintain.
- the CocoonPortlet uses the Cocoon ProducerFromRequest in order to
emulate servlet requests but the ProducerFromRequest has been/will
be removed from Cocoon because of security issues (that's what
Stefano told me at ApacheCon). There also has been a lot of issues
with this portlet (clearing the repository, etc...).
All in all, to keep this functionality is good, but it should be
done properly and outside the scope of Jetspeed engine. I think
the most natural way to do it now is to implement a CocoonService
as a TurbineService.
I hope it clarifies the issues and reasons why I'd like to drop
Cocoon dependency from the Jetspeed engine (but keep the
CocoonPortlet and util classes in the /module directory).
--
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]
