Santiago Gala wrote:
>
> Raphael Luta wrote:
>
> >
> > 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.
>
Unstable HEAD is not too much of a problem when the committer is there
to solve problems that may crop up.
You should also have a look at where the MemoryStore is used: nowhere
except in PortletCache, so the substitution should be pretty straightforward.
The MemoryStorePortlet will have to be rewritten as PortletCachePortlet though.
> 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.
>
Good luck, you'll need a lot of refactoring to clean this.
The PortletCache is a real memory caching system, the JetspeedDiskCache is
an hybrid cache and remote document fetching object.
> >
> > - 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.
>
If you're talking about Cocoon 2 integration, I'm definitely interested in
learning what Ricardo has to say.
> >
> > 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 switching are you talking about, the MemoryStore thing or
the CocoonPortlet ?
I don't really see what the Cocoon people can say about our use of the
MemoryStore but they may definitely help us to build a robust bridge
between Jetspeed and Cocoon.
> Which API would be use from Cocoon as a service? servlet-like, or app-like?
>
App-like most likely.
> 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.
>
And this will integrate nicely with Jetspeed when the templating work is done.
> 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.
>
Velocity is implemented as a service, as well as all the other templating
systems in Turbine. I don't see why XSLT or Cocoon should be an exception.
> >
> > 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.
>
OK.
--
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]
