Raphael Luta wrote:
> 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.
>
I was clearly meaning the bridge. I know the MemoryStore is better replaced to
remove dependencies.
My issues WRT the store were about having new bugs with portlet refreshing (a tough
issue), but I think that the cleaner archtecture will help spot them.
>
> > 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]
--
--------------------------------------------------------------
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]
