"Kevin A. Burton" wrote:
>
> > * Fix multi-threaded operation / caching rework
> > Make sure that the engine may be safely used in a multi-threaded,
> > multi-user environment. If we want to avoid a major API change
> > for the 1.2 release, this may require to disable or rework portlet
> > caching.
>
> I don't think so... there was only one small issue that need to be worked out.
> That should be in TODO.
>
No, there are some serious issues in there, check the posts from
santiago, stefan and thomas.
> > In any case, the caching system needs an audit to identify
> > its shortcomings.
> >
> > * Create a WAR
> > We should be able to provide Jetspeed as a WAR application. This
> > may require to change the way some properties are used so that
> > all properties URL or files can be considered relative to the
> > webapp root.
>
> That is already in there. I have said it a number of times but the tomcat-build
> will give you this :)
>
Doesn't run. There's no tomcat in the CVS. In any case, it's only
suitable for a generic introduction setup. Most people who will
want to use jetspeed will need to reinstall it with different
DBs, etc... and we ought to make this task as easy as possible.
> > * Castor support
> > Some time ago, it was decided to drop Castor support and provide
> > another XML <-> Java mechanism. This would imply a lot
> > of factory rework.
> >
> > [I'd stick with Castor for 1.2 and remove it for the later
> > releases]
>
> I was going to take this up. I would say that personally the Castor stuff is
> the worst part of Jetspeed right now. It really scares me :(
>
I think removing Castor while definitely a good move is ambitious
for a 1.2 release, but if you can commit a lot of time to fix this,
go for it :)
> > * Cocoon support
> > The Cocoon support provided by Jetspeed is currently a hack and
> > I don't think it works with Cocoon 1.8, so we either need to
> > drop this feature and use a simple XSL processor or re-design
> > a Cocoon bridge.
>
> I would rather redesign it..
>
> > [I'd vote for moving the CocoonPortlet and Cocoon support to a
> > modules directory and remove any dependency of the engine on
> > Cocoon 1]
>
> Then we would have to drop Cocoon 100%. The Engine is already hacked to support
> Cocoon 1.x. If we want to clean it up then we have to drop Cocoon which would
> make a lot of people angry (myself included). If we decide to do this then we
> need to go with Jetspeed 2.0 -> Cocoon 2.0.
>
What use do we currently have for Cocoon 1 in the engine that can't be
done by a simple XSL engine or a simple Java code ?
--
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]
