Raphael Luta wrote:
> 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.
>
If you feel it can be substituted easily, nothing to object. The MemoryStore
is also used to report in the Admin associated component.
I have a fear: that the behaviour of both Store systems is different, and that
it propagates as a set of bugs difficult to handle. If we where speaking about
Jetspeed 2 I would say OK, but 1.2 should be close. Nothing to object if work
is done in a branch after we have released 1.2b2, and we test before merging
back.
The danger is that we can enter again a unstable HEAD problem, and have people
scared of the stability of code.
I will take a look at that, if nobody objects, as I wanted to clean up the
code in the basic JetspeedDiskCache, and have it implemented as a similar
service, instead of using our own interfaces. This will reduce dramatically
the code in this area, and will make it simpler to use and to maintain.
>
> - 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.
>
I agree. You are convincing me by now.
>
> - 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...).
That was the issue I was speaking about with Ricardo WRT Cocoon 1. We are also
speaking about how to manage portlet paremeter isolation and URI management
with the sitemap and the action classes in Cocoon 2, and testing this kind of
integration at the conceptual level.
>
> 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.
>
You are right, I am convinced by now..
Do you think it will be better to discuss the issues with Cocoon people before
switching?
Which API would be use from Cocoon as a service? servlet-like, or app-like?
I thought about having a XML or Cocoon templating engine, which basically
would handle parameters to XSLT (the way I did in SimpleTransform) or to
Cocoon, and then Xalan or Cocoon would render the page as a template. It is
similar to the way Velocity is handled, and it would integrate nicely with
Turbine templating approach.
This would be less powerful than the Service approach, but it could be used
for simple XSLT transformations, similar to what Juan Carlos and Roberto are
doing currently.
>
> 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).
>
Would you mind to wait until I have shown this info to Ricardo, and test with
him? If you already have the code refactoring, replacement, etc., then I
change my -1 for a +1, as now I see the whole picture.
I agree that, whichever integration we have with Cocoon, it should be at the
service level, and it should not create code dependencies.
>
> --
> 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]
