You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Carsten Ziegeler <cz...@sundn.de> on 2001/07/10 10:33:37 UTC
[C2]: Planning beta 2
Hi Team,
I think it is time to plan our next release: beta 2.
Our plans were to make this release in the middle of july and
I think we can realize this.
Apart from more documentation which is of course important
for the beta 2,
we have *only* to solve the bugs entered in bugzilla and
to finish outstanding issues. One of them is the content length
problem and the other is the class loading problem entered
in the todo list.
Is there any other thing to do?
If not, I would propose a code freeze for the end of the week
and a release date for the beta 2 could be 23rd of july.
What do you think?
Carsten
Open Source Group sunShine - b:Integrated
================================================================
Carsten Ziegeler, S&N AG, Klingenderstrasse 5, D-33100 Paderborn
www.sundn.de mailto: cziegeler@sundn.de
================================================================
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [C2]: Planning beta 2
Posted by Gerhard Fröhlich <g-...@gmx.de>.
Hi,
no I mean the MRUMemoryStore which keeps objects on the fs. See
my todo...
Cheers
Gerhard
> Quoting g-froehlich@gmx.de:
>
> > Hi,
> > do you want to integrate the filesystem store in the beta2
> > it's nearly ready, but not tested on load. But it should be
> > testable at the end of the week...
>
> Ahem... which FilesystemStore? A new one? What about the old one? Do you
> have
> any plans for it?
>
> Giacomo
>
> >
> > Cheers
> > Gerhard
> > > Hi Team,
> > >
> > > I think it is time to plan our next release: beta 2.
> > > Our plans were to make this release in the middle of july and
> > > I think we can realize this.
> > >
> > > Apart from more documentation which is of course important
> > > for the beta 2,
> > > we have *only* to solve the bugs entered in bugzilla and
> > > to finish outstanding issues. One of them is the content length
> > > problem and the other is the class loading problem entered
> > > in the todo list.
> > >
> > > Is there any other thing to do?
> > >
> > > If not, I would propose a code freeze for the end of the week
> > > and a release date for the beta 2 could be 23rd of july.
> > >
> > > What do you think?
> > >
> > > Carsten
> > >
> > > Open Source Group sunShine - b:Integrated
> > > ================================================================
> > > Carsten Ziegeler, S&N AG, Klingenderstrasse 5, D-33100 Paderborn
> > > www.sundn.de mailto: cziegeler@sundn.de
> > > ================================================================
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> > > For additional commands, email: cocoon-dev-help@xml.apache.org
> > >
> >
> > --
> > Gerhard Fröhlich
> > g-froehlich@gmx.de
> >
> > "black holes are,
> > when GOD is dividing by zero"
> >
> > GMX - Die Kommunikationsplattform im Internet.
> > http://www.gmx.net
> >
> > GMX Tipp:
> >
> > Machen Sie Ihr Hobby zu Geld bei unserem Partner 1&1!
> > http://profiseller.de/info/index.php3?ac=OM.PS.PS003K00596T0409a
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> > For additional commands, email: cocoon-dev-help@xml.apache.org
> >
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
--
Gerhard Fröhlich
g-froehlich@gmx.de
"black holes are,
when GOD is dividing by zero"
GMX - Die Kommunikationsplattform im Internet.
http://www.gmx.net
GMX Tipp:
Machen Sie Ihr Hobby zu Geld bei unserem Partner 1&1!
http://profiseller.de/info/index.php3?ac=OM.PS.PS003K00596T0409a
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [C2]: Planning beta 2
Posted by Giacomo Pati <gi...@apache.org>.
Quoting g-froehlich@gmx.de:
> Hi,
> do you want to integrate the filesystem store in the beta2
> it's nearly ready, but not tested on load. But it should be
> testable at the end of the week...
Ahem... which FilesystemStore? A new one? What about the old one? Do you have
any plans for it?
Giacomo
>
> Cheers
> Gerhard
> > Hi Team,
> >
> > I think it is time to plan our next release: beta 2.
> > Our plans were to make this release in the middle of july and
> > I think we can realize this.
> >
> > Apart from more documentation which is of course important
> > for the beta 2,
> > we have *only* to solve the bugs entered in bugzilla and
> > to finish outstanding issues. One of them is the content length
> > problem and the other is the class loading problem entered
> > in the todo list.
> >
> > Is there any other thing to do?
> >
> > If not, I would propose a code freeze for the end of the week
> > and a release date for the beta 2 could be 23rd of july.
> >
> > What do you think?
> >
> > Carsten
> >
> > Open Source Group sunShine - b:Integrated
> > ================================================================
> > Carsten Ziegeler, S&N AG, Klingenderstrasse 5, D-33100 Paderborn
> > www.sundn.de mailto: cziegeler@sundn.de
> > ================================================================
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> > For additional commands, email: cocoon-dev-help@xml.apache.org
> >
>
> --
> Gerhard Fröhlich
> g-froehlich@gmx.de
>
> "black holes are,
> when GOD is dividing by zero"
>
> GMX - Die Kommunikationsplattform im Internet.
> http://www.gmx.net
>
> GMX Tipp:
>
> Machen Sie Ihr Hobby zu Geld bei unserem Partner 1&1!
> http://profiseller.de/info/index.php3?ac=OM.PS.PS003K00596T0409a
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: AW: [C2]: Planning beta 2
Posted by Gerhard Fröhlich <g-...@gmx.de>.
Hi,
no problem for me at :-)
Cheers
Gerhard
> Hi Gerhard,
>
> great to hear to have a new filesystem store working for c2!
> I'm looking forward to it.
>
> If your implementation arrives in time we *could* add it to the
> beta2.
> But I think we should first add it to the HEAD branch, test it
> and then add it to the 2.0 branch so that it will make it's
> way into the final beta.
>
> However, if we agree to a later date than the 23rd of july
> for the beta2, we could add it directly to the 2.0 branch.
>
> Is this ok for you?
>
>
> Carsten
>
> Open Source Group sunShine - b:Integrated
> =========================
> =========================
> ==============
> Carsten Ziegeler, S&N AG, Klingenderstrasse 5, D-33100 Paderborn
> www.sundn.de mailto: cziegeler@sundn.de
> =========================
> =========================
> ==============
>
>
> > -----Ursprüngliche Nachricht-----
> > Von: g-froehlich@gmx.de [mailto:g-froehlich@gmx.de]
> > Gesendet: Dienstag, 10. Juli 2001 12:22
> > An: cocoon-dev@xml.apache.org
> > Betreff: Re: [C2]: Planning beta 2
> >
> >
> > Hi,
> > do you want to integrate the filesystem store in the beta2
> > it's nearly ready, but not tested on load. But it should be
> > testable at the end of the week...
> >
> > Cheers
> > Gerhard
> > > Hi Team,
> > >
> > > I think it is time to plan our next release: beta 2.
> > > Our plans were to make this release in the middle of july and
> > > I think we can realize this.
> > >
> > > Apart from more documentation which is of course important
> > > for the beta 2,
> > > we have *only* to solve the bugs entered in bugzilla and
> > > to finish outstanding issues. One of them is the content length
> > > problem and the other is the class loading problem entered
> > > in the todo list.
> > >
> > > Is there any other thing to do?
> > >
> > > If not, I would propose a code freeze for the end of the week
> > > and a release date for the beta 2 could be 23rd of july.
> > >
> > > What do you think?
> > >
> > > Carsten
> > >
> > > Open Source Group sunShine - b:Integrated
> > > =======================
> =========================
> ================
> > > Carsten Ziegeler, S&N AG, Klingenderstrasse 5, D-33100 Paderborn
> > > www.sundn.de mailto: cziegeler@sundn.de
> > > =======================
> =========================
> ================
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> > > For additional commands, email: cocoon-dev-help@xml.apache.org
> > >
> >
> > --
> > Gerhard Fröhlich
> > g-froehlich@gmx.de
> >
> > "black holes are,
> > when GOD is dividing by zero"
> >
> > GMX - Die Kommunikationsplattform im Internet.
> > http://www.gmx.net
> >
> > GMX Tipp:
> >
> > Machen Sie Ihr Hobby zu Geld bei unserem Partner 1&1!
> > http://profiseller.de/info/index.php3?ac=OM.PS.PS003K00596T0409a
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> > For additional commands, email: cocoon-dev-help@xml.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
--
Gerhard Fröhlich
g-froehlich@gmx.de
"black holes are,
when GOD is dividing by zero"
GMX - Die Kommunikationsplattform im Internet.
http://www.gmx.net
GMX Tipp:
Machen Sie Ihr Hobby zu Geld bei unserem Partner 1&1!
http://profiseller.de/info/index.php3?ac=OM.PS.PS003K00596T0409a
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
AW: [C2]: Planning beta 2
Posted by Carsten Ziegeler <cz...@sundn.de>.
Hi Gerhard,
great to hear to have a new filesystem store working for c2!
I'm looking forward to it.
If your implementation arrives in time we *could* add it to the
beta2.
But I think we should first add it to the HEAD branch, test it
and then add it to the 2.0 branch so that it will make it's
way into the final beta.
However, if we agree to a later date than the 23rd of july
for the beta2, we could add it directly to the 2.0 branch.
Is this ok for you?
Carsten
Open Source Group sunShine - b:Integrated
================================================================
Carsten Ziegeler, S&N AG, Klingenderstrasse 5, D-33100 Paderborn
www.sundn.de mailto: cziegeler@sundn.de
================================================================
> -----Ursprüngliche Nachricht-----
> Von: g-froehlich@gmx.de [mailto:g-froehlich@gmx.de]
> Gesendet: Dienstag, 10. Juli 2001 12:22
> An: cocoon-dev@xml.apache.org
> Betreff: Re: [C2]: Planning beta 2
>
>
> Hi,
> do you want to integrate the filesystem store in the beta2
> it's nearly ready, but not tested on load. But it should be
> testable at the end of the week...
>
> Cheers
> Gerhard
> > Hi Team,
> >
> > I think it is time to plan our next release: beta 2.
> > Our plans were to make this release in the middle of july and
> > I think we can realize this.
> >
> > Apart from more documentation which is of course important
> > for the beta 2,
> > we have *only* to solve the bugs entered in bugzilla and
> > to finish outstanding issues. One of them is the content length
> > problem and the other is the class loading problem entered
> > in the todo list.
> >
> > Is there any other thing to do?
> >
> > If not, I would propose a code freeze for the end of the week
> > and a release date for the beta 2 could be 23rd of july.
> >
> > What do you think?
> >
> > Carsten
> >
> > Open Source Group sunShine - b:Integrated
> > ================================================================
> > Carsten Ziegeler, S&N AG, Klingenderstrasse 5, D-33100 Paderborn
> > www.sundn.de mailto: cziegeler@sundn.de
> > ================================================================
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> > For additional commands, email: cocoon-dev-help@xml.apache.org
> >
>
> --
> Gerhard Fröhlich
> g-froehlich@gmx.de
>
> "black holes are,
> when GOD is dividing by zero"
>
> GMX - Die Kommunikationsplattform im Internet.
> http://www.gmx.net
>
> GMX Tipp:
>
> Machen Sie Ihr Hobby zu Geld bei unserem Partner 1&1!
> http://profiseller.de/info/index.php3?ac=OM.PS.PS003K00596T0409a
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [C2]: Planning beta 2
Posted by g-...@gmx.de.
Hi,
do you want to integrate the filesystem store in the beta2
it's nearly ready, but not tested on load. But it should be
testable at the end of the week...
Cheers
Gerhard
> Hi Team,
>
> I think it is time to plan our next release: beta 2.
> Our plans were to make this release in the middle of july and
> I think we can realize this.
>
> Apart from more documentation which is of course important
> for the beta 2,
> we have *only* to solve the bugs entered in bugzilla and
> to finish outstanding issues. One of them is the content length
> problem and the other is the class loading problem entered
> in the todo list.
>
> Is there any other thing to do?
>
> If not, I would propose a code freeze for the end of the week
> and a release date for the beta 2 could be 23rd of july.
>
> What do you think?
>
> Carsten
>
> Open Source Group sunShine - b:Integrated
> ================================================================
> Carsten Ziegeler, S&N AG, Klingenderstrasse 5, D-33100 Paderborn
> www.sundn.de mailto: cziegeler@sundn.de
> ================================================================
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
--
Gerhard Fröhlich
g-froehlich@gmx.de
"black holes are,
when GOD is dividing by zero"
GMX - Die Kommunikationsplattform im Internet.
http://www.gmx.net
GMX Tipp:
Machen Sie Ihr Hobby zu Geld bei unserem Partner 1&1!
http://profiseller.de/info/index.php3?ac=OM.PS.PS003K00596T0409a
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
AW: [C2]: Planning beta 2
Posted by Carsten Ziegeler <cz...@sundn.de>.
> Giacomo Pati wrote:
>
> Quoting Carsten Ziegeler <cz...@sundn.de>:
>
> > Hi Team,
> >
> > I think it is time to plan our next release: beta 2.
> > Our plans were to make this release in the middle of july and
> > I think we can realize this.
> >
> > Apart from more documentation which is of course important
> > for the beta 2,
> > we have *only* to solve the bugs entered in bugzilla and
> > to finish outstanding issues. One of them is the content length
> > problem and the other is the class loading problem entered
> > in the todo list.
> >
> > Is there any other thing to do?
>
> I don't have any other issues except integrating the new avalon
> libs and get rid
> of the Roles.java class which should not be needed anymore then.
>
> Oh, one issue left. In the caching subpackage there are empty interfaces
> (EventCache and StreamCache) left which are not needed anymore.
> Carsten, you've
> remove two of them yesterday (the classes) but not their
> interfaces. Could you
> remove them (in the 20-branch)?
>
Oh yes, I just removed them. Thanks.
Carsten
> > If not, I would propose a code freeze for the end of the week
> > and a release date for the beta 2 could be 23rd of july.
>
> +1.
>
> Giacomo
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [C2]: Planning beta 2
Posted by Giacomo Pati <gi...@apache.org>.
Quoting Carsten Ziegeler <cz...@sundn.de>:
> Hi Team,
>
> I think it is time to plan our next release: beta 2.
> Our plans were to make this release in the middle of july and
> I think we can realize this.
>
> Apart from more documentation which is of course important
> for the beta 2,
> we have *only* to solve the bugs entered in bugzilla and
> to finish outstanding issues. One of them is the content length
> problem and the other is the class loading problem entered
> in the todo list.
>
> Is there any other thing to do?
I don't have any other issues except integrating the new avalon libs and get rid
of the Roles.java class which should not be needed anymore then.
Oh, one issue left. In the caching subpackage there are empty interfaces
(EventCache and StreamCache) left which are not needed anymore. Carsten, you've
remove two of them yesterday (the classes) but not their interfaces. Could you
remove them (in the 20-branch)?
> If not, I would propose a code freeze for the end of the week
> and a release date for the beta 2 could be 23rd of july.
+1.
Giacomo
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [C2]: Planning beta 2 (Configurable JspGenerator which work with Oracle9iAS Containers for J2EE)
Posted by "Marcelo F. Ochoa" <mo...@ieee.org>.
Davanum Srinivas wrote:
>>
>>
>
> Marcelo,
> Do you have some time to do this?
IMO using the interface javax.servlet.Servlet will be work for all cases.
- "javax.servlet.http.HttpServlet" class extends
javax.servlet.GenericServlet which implements javax.servlet.Servlet
interface.
- "com.evermind.server.http.JSPServlet" implements
javax.servlet.Servlet interface.
- "com.prism.JspWrapper" implements javax.servlet.Servlet interface.
Then using:
...
import javax.servlet.Servlet;
...
Class clazz = Thread.currentThread().getContextClassLoader().loadClass(this.jspServletClass);
Servlet jsp = (Servlet) clazz.newInstance();
jsp.init(new config((ServletContext)this.objectModel.get(HttpEnvironment.HTTP_SERVLET_CONTEXT)));
jsp.service(request, response);
...
will be work ...
>
>
> Thanks,
> dims
>
>
Many thanks in advance, Marcelo
--
Marcelo F. Ochoa - mochoa@ieee.org
Do you Know DB Prism? Look @ http://www.plenix.com/dbprism/
More info?
Chapter 21 of the book "Professional XML Databases" (Wrox Press
http://www.wrox.com/)
Chapter 8 of the book "Oracle & Open Source" (O'Reilly
http://www.oreilly.com/catalog/oracleopen/)
-----------------------------------------------
Lab. de Sistemas - Fac. de Cs. Exactas - UNICEN
Paraje Arroyo Seco - Campus Universitario
(7000) Tandil - Bs. AS. - Argentina
Te: +54-2293-444430 Fax: +54-2293-444431
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [C2]: Planning beta 2 (Configurable JspGenerator which work with Oracle9iAS Containers for J2EE)
Posted by Davanum Srinivas <di...@yahoo.com>.
Please see below:
--- Giacomo Pati <gi...@apache.org> wrote:
> Quoting "Marcelo F. Ochoa" <mo...@ieee.org>:
>
> > Hi all:
> > Is there any simple way to modified the JspGenerator in order to
> > accept a configuration parameter?
>
> Yes, patch it to accept a Configuration/Parameters like any other component will
> ev. have Configuration/Parameters.
Giacomo, Marcelo,
Done. Checked-in to both 2.0 and 2.1 CVS.
>
> > It mean that JspGenerator accepts differents JspCompiler, for
> > example:
> > - com.evermind.server.http.JSPServlet (Oracle9iAS Containers for
> > J2EE)
> > - oracle.jsp.JspServlet (Oracle JSP 1.1)
> >
> > - com.prism.JspWrapper (DB Prism wrapper which integrates DB Prism
> > 1.2.1 with Cocoon 2 framework)
> >
> > I am working with the last option and with a modified version (hard
> > coded) of JspGenerator which has changed the lines:
> >
> > // start JSPServlet.
> > Class clazz =
> >
>
Thread.currentThread().getContextClassLoader().loadClass("org.apache.jasper.servlet.JspServlet");
> > HttpServlet jsp = (HttpServlet) clazz.newInstance();
> >
> >
> > with these lines:
> >
> > // start JSPServlet.
> > Class clazz =
> > Thread.currentThread().getContextClassLoader().loadClass("com.prism.JspWrapper");
> > Servlet jsp = (Servlet) clazz.newInstance();
>
> If all these HttpServlets/Servlets need to be abstracted then you should create
> an Avalon component put into cocoon.xconf to wrap those and let JspGenerator
> choose that component for the request.
>
Marcelo,
Do you have some time to do this?
> >
> > Note that, I am using Servlet class instead of HttpServlet because is
> > higher in the level of inherency and it working with Oracle Object
> > Container for Java (9 iAS).
> > In the other hand, I am working in document with five step to install
> > and run Cocoon 2 with Oracle9iAS Containers for J2EE (OC4J)
> > (http://technet.oracle.com/tech/java/oc4j/content.html) and I will sent
> > it to this list.
> > Best regards, Marcelo.
Thanks,
dims
=====
Davanum Srinivas, JNI-FAQ Manager
http://www.jGuru.com/faq/JNI
__________________________________________________
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail
http://personal.mail.yahoo.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [C2]: Planning beta 2 (Configurable JspGenerator which work with Oracle9iAS Containers for J2EE)
Posted by Giacomo Pati <gi...@apache.org>.
Quoting "Marcelo F. Ochoa" <mo...@ieee.org>:
> Hi all:
> Is there any simple way to modified the JspGenerator in order to
> accept a configuration parameter?
Yes, patch it to accept a Configuration/Parameters like any other component will
ev. have Configuration/Parameters.
> It mean that JspGenerator accepts differents JspCompiler, for
> example:
> - com.evermind.server.http.JSPServlet (Oracle9iAS Containers for
> J2EE)
> - oracle.jsp.JspServlet (Oracle JSP 1.1)
>
> - com.prism.JspWrapper (DB Prism wrapper which integrates DB Prism
> 1.2.1 with Cocoon 2 framework)
>
> I am working with the last option and with a modified version (hard
> coded) of JspGenerator which has changed the lines:
>
> // start JSPServlet.
> Class clazz =
>
Thread.currentThread().getContextClassLoader().loadClass("org.apache.jasper.servlet.JspServlet");
> HttpServlet jsp = (HttpServlet) clazz.newInstance();
>
>
> with these lines:
>
> // start JSPServlet.
> Class clazz =
> Thread.currentThread().getContextClassLoader().loadClass("com.prism.JspWrapper");
> Servlet jsp = (Servlet) clazz.newInstance();
If all these HttpServlets/Servlets need to be abstracted then you should create
an Avalon component put into cocoon.xconf to wrap those and let JspGenerator
choose that component for the request.
Giacomo
>
> Note that, I am using Servlet class instead of HttpServlet because is
> higher in the level of inherency and it working with Oracle Object
> Container for Java (9 iAS).
> In the other hand, I am working in document with five step to install
> and run Cocoon 2 with Oracle9iAS Containers for J2EE (OC4J)
> (http://technet.oracle.com/tech/java/oc4j/content.html) and I will sent
> it to this list.
> Best regards, Marcelo.
>
>
> --
> Marcelo F. Ochoa - mochoa@ieee.org
> Do you Know DB Prism? Look @ http://www.plenix.com/dbprism/
> More info?
> Chapter 21 of the book "Professional XML Databases" (Wrox Press
> http://www.wrox.com/)
> Chapter 8 of the book "Oracle & Open Source" (O'Reilly
> http://www.oreilly.com/catalog/oracleopen/)
> -----------------------------------------------
> Lab. de Sistemas - Fac. de Cs. Exactas - UNICEN
> Paraje Arroyo Seco - Campus Universitario
> (7000) Tandil - Bs. AS. - Argentina
> Te: +54-2293-444430 Fax: +54-2293-444431
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [C2]: Planning beta 2 (Configurable JspGenerator which work with Oracle9iAS Containers for J2EE)
Posted by Davanum Srinivas <di...@yahoo.com>.
Marcelo,
Please pick up the latest JspGenerator.java and sitemap.xmap from the CVS. You will find that you
can specify the Class Name as a parameter in the sitemap.xmap file. Please feel free to submit
patches and docs. It will be really helpful.
Thanks,
dims
--- "Marcelo F. Ochoa" <mo...@ieee.org> wrote:
> Hi all:
> Is there any simple way to modified the JspGenerator in order to
> accept a configuration parameter?
> It mean that JspGenerator accepts differents JspCompiler, for example:
> - com.evermind.server.http.JSPServlet (Oracle9iAS Containers for J2EE)
> - oracle.jsp.JspServlet (Oracle JSP 1.1)
>
> - com.prism.JspWrapper (DB Prism wrapper which integrates DB Prism 1.2.1 with Cocoon 2
> framework)
>
> I am working with the last option and with a modified version (hard
> coded) of JspGenerator which has changed the lines:
>
> // start JSPServlet.
> Class clazz =
>
Thread.currentThread().getContextClassLoader().loadClass("org.apache.jasper.servlet.JspServlet");
> HttpServlet jsp = (HttpServlet) clazz.newInstance();
>
>
> with these lines:
>
> // start JSPServlet.
> Class clazz =
> Thread.currentThread().getContextClassLoader().loadClass("com.prism.JspWrapper");
> Servlet jsp = (Servlet) clazz.newInstance();
>
> Note that, I am using Servlet class instead of HttpServlet because is
> higher in the level of inherency and it working with Oracle Object
> Container for Java (9 iAS).
> In the other hand, I am working in document with five step to install
> and run Cocoon 2 with Oracle9iAS Containers for J2EE (OC4J)
> (http://technet.oracle.com/tech/java/oc4j/content.html) and I will sent
> it to this list.
> Best regards, Marcelo.
>
>
> --
> Marcelo F. Ochoa - mochoa@ieee.org
> Do you Know DB Prism? Look @ http://www.plenix.com/dbprism/
> More info?
> Chapter 21 of the book "Professional XML Databases" (Wrox Press
> http://www.wrox.com/)
> Chapter 8 of the book "Oracle & Open Source" (O'Reilly
> http://www.oreilly.com/catalog/oracleopen/)
> -----------------------------------------------
> Lab. de Sistemas - Fac. de Cs. Exactas - UNICEN
> Paraje Arroyo Seco - Campus Universitario
> (7000) Tandil - Bs. AS. - Argentina
> Te: +54-2293-444430 Fax: +54-2293-444431
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
=====
Davanum Srinivas, JNI-FAQ Manager
http://www.jGuru.com/faq/JNI
__________________________________________________
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail
http://personal.mail.yahoo.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [C2]: Planning beta 2 (Configurable JspGenerator which work with Oracle9iAS Containers for J2EE)
Posted by "Marcelo F. Ochoa" <mo...@ieee.org>.
Hi all:
Is there any simple way to modified the JspGenerator in order to
accept a configuration parameter?
It mean that JspGenerator accepts differents JspCompiler, for example:
- com.evermind.server.http.JSPServlet (Oracle9iAS Containers for J2EE)
- oracle.jsp.JspServlet (Oracle JSP 1.1)
- com.prism.JspWrapper (DB Prism wrapper which integrates DB Prism 1.2.1 with Cocoon 2 framework)
I am working with the last option and with a modified version (hard
coded) of JspGenerator which has changed the lines:
// start JSPServlet.
Class clazz =
Thread.currentThread().getContextClassLoader().loadClass("org.apache.jasper.servlet.JspServlet");
HttpServlet jsp = (HttpServlet) clazz.newInstance();
with these lines:
// start JSPServlet.
Class clazz =
Thread.currentThread().getContextClassLoader().loadClass("com.prism.JspWrapper");
Servlet jsp = (Servlet) clazz.newInstance();
Note that, I am using Servlet class instead of HttpServlet because is
higher in the level of inherency and it working with Oracle Object
Container for Java (9 iAS).
In the other hand, I am working in document with five step to install
and run Cocoon 2 with Oracle9iAS Containers for J2EE (OC4J)
(http://technet.oracle.com/tech/java/oc4j/content.html) and I will sent
it to this list.
Best regards, Marcelo.
--
Marcelo F. Ochoa - mochoa@ieee.org
Do you Know DB Prism? Look @ http://www.plenix.com/dbprism/
More info?
Chapter 21 of the book "Professional XML Databases" (Wrox Press
http://www.wrox.com/)
Chapter 8 of the book "Oracle & Open Source" (O'Reilly
http://www.oreilly.com/catalog/oracleopen/)
-----------------------------------------------
Lab. de Sistemas - Fac. de Cs. Exactas - UNICEN
Paraje Arroyo Seco - Campus Universitario
(7000) Tandil - Bs. AS. - Argentina
Te: +54-2293-444430 Fax: +54-2293-444431
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [C2]: Planning beta 2
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> -----Original Message-----
> From: Carsten Ziegeler [mailto:cziegeler@sundn.de]
> Sent: den 10 juli 2001 12:55
> To: cocoon-dev@xml.apache.org
> Subject: AW: [C2]: Planning beta 2
>
>
> Hi,
>
> patch is applied and so should it make into the beta2....
>
> Thanks and please cross-check.
Checked. Thanks.
/LS
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
AW: [C2]: Planning beta 2
Posted by Carsten Ziegeler <cz...@sundn.de>.
Hi,
patch is applied and so should it make into the beta2....
Thanks and please cross-check.
Carsten
Open Source Group sunShine - b:Integrated
================================================================
Carsten Ziegeler, S&N AG, Klingenderstrasse 5, D-33100 Paderborn
www.sundn.de mailto: cziegeler@sundn.de
================================================================
> -----Ursprüngliche Nachricht-----
> Von: Leo Sutic [mailto:leo.sutic@inspireinfrastructure.com]
> Gesendet: Dienstag, 10. Juli 2001 10:42
> An: cocoon-dev@xml.apache.org
> Betreff: RE: [C2]: Planning beta 2
>
> > -----Original Message-----
> > From: Carsten Ziegeler [mailto:cziegeler@sundn.de]
> > Sent: den 10 juli 2001 10:34
> > To: Cocoon-Dev@Xml. Apache. Org
> > Subject: [C2]: Planning beta 2
> >
> > Is there any other thing to do?
>
> I'd like to have my patch fixing WML output incorporated into the beta.
>
> /LS
>
> --- sitemap.xmap.old Mon Jul 09 16:38:10 2001
>
> +++ sitemap.xmap Mon Jul 09 16:37
> :42 2001
> @@ -47,6 +47,7 @@
> <map:serializer name="wap" mime-type="text/vnd.wap.wml"
> src="org.apache.c
> ocoon.serialization.XMLSerializer">
> <doctype-public>-//WAPFORUM//DTD WML 1.1//EN</doctype-public>
>
> <doctype-system>http://www.wapforum.org/DTD/wml_1.1.xml</doctype-system>
> + <encoding>ASCII</encoding>
> </map:serializer>
> <map:serializer name="svgxml" mime-type="image/svg-xml"
> src="org.apache.c
> ocoon.serialization.XMLSerializer">
> <doctype-public>-//W3C//DTD SVG 20000303
> Stylable//EN</doctype-public>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [C2]: Planning beta 2
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> -----Original Message-----
> From: Carsten Ziegeler [mailto:cziegeler@sundn.de]
> Sent: den 10 juli 2001 10:34
> To: Cocoon-Dev@Xml. Apache. Org
> Subject: [C2]: Planning beta 2
>
> Is there any other thing to do?
I'd like to have my patch fixing WML output incorporated into the beta.
/LS
--- sitemap.xmap.old Mon Jul 09 16:38:10 2001
+++ sitemap.xmap Mon Jul 09 16:37
:42 2001
@@ -47,6 +47,7 @@
<map:serializer name="wap" mime-type="text/vnd.wap.wml"
src="org.apache.c
ocoon.serialization.XMLSerializer">
<doctype-public>-//WAPFORUM//DTD WML 1.1//EN</doctype-public>
<doctype-system>http://www.wapforum.org/DTD/wml_1.1.xml</doctype-system>
+ <encoding>ASCII</encoding>
</map:serializer>
<map:serializer name="svgxml" mime-type="image/svg-xml"
src="org.apache.c
ocoon.serialization.XMLSerializer">
<doctype-public>-//W3C//DTD SVG 20000303 Stylable//EN</doctype-public>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
AW: [C2]: Planning beta 2
Posted by Carsten Ziegeler <cz...@sundn.de>.
> Davanum Srinivas wrote:
>
> Please see below:
>
> --- Carsten Ziegeler <cz...@sundn.de> wrote:
> > Apart from more documentation which is of course important
> > for the beta 2,
> > we have *only* to solve the bugs entered in bugzilla and
> > to finish outstanding issues. One of them is the content length
> > problem and the other is the class loading problem entered
> > in the todo list.
> > Is there any other thing to do?
>
> We can move the new SQLTransformer and helper transformers from
> C2.1 to C2.
>
I didn't follow the discussions very close, but is the C2.1 SQL
transformer combatible to the C2 solution? If so, ok we can
add it.
Carsten
> > If not, I would propose a code freeze for the end of the week
> > and a release date for the beta 2 could be 23rd of july.
>
> +1 for beta 2 on 23rd July.
>
> Thanks,
> dims
>
> =====
> Davanum Srinivas, JNI-FAQ Manager
> http://www.jGuru.com/faq/JNI
>
> __________________________________________________
> Do You Yahoo!?
> Get personalized email addresses from Yahoo! Mail
> http://personal.mail.yahoo.com/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [C2]: Planning beta 2
Posted by Davanum Srinivas <di...@yahoo.com>.
Please see below:
--- Carsten Ziegeler <cz...@sundn.de> wrote:
> Apart from more documentation which is of course important
> for the beta 2,
> we have *only* to solve the bugs entered in bugzilla and
> to finish outstanding issues. One of them is the content length
> problem and the other is the class loading problem entered
> in the todo list.
> Is there any other thing to do?
We can move the new SQLTransformer and helper transformers from C2.1 to C2.
> If not, I would propose a code freeze for the end of the week
> and a release date for the beta 2 could be 23rd of july.
+1 for beta 2 on 23rd July.
Thanks,
dims
=====
Davanum Srinivas, JNI-FAQ Manager
http://www.jGuru.com/faq/JNI
__________________________________________________
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail
http://personal.mail.yahoo.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
AW: [C2]: Planning beta 2
Posted by Carsten Ziegeler <cz...@sundn.de>.
> Vadim Gritsenko wrote:
>
> > -----Original Message-----
> > From: Carsten Ziegeler [mailto:cziegeler@sundn.de]
> > Sent: Wednesday, July 11, 2001 9:33
> > To: cocoon-dev@xml.apache.org
> > Subject: AW: [C2]: Planning beta 2
> >
> >
> > > Vadim Gritsenko wrote:
> > >
> > > > -----Original Message-----
> > > > From: Carsten Ziegeler [mailto:cziegeler@sundn.de]
> > > > Sent: Tuesday, July 10, 2001 4:34
> > > > To: Cocoon-Dev@Xml. Apache. Org
> > > > Subject: [C2]: Planning beta 2
> > > >
> > > >
> > > > Hi Team,
> > > >
> > > > I think it is time to plan our next release: beta 2.
> > > > Our plans were to make this release in the middle of july and
> > > > I think we can realize this.
> > > >
> > > > Apart from more documentation which is of course important
> > > > for the beta 2,
> > > > we have *only* to solve the bugs entered in bugzilla and
> > > > to finish outstanding issues. One of them is the content length
> > > > problem and the other is the class loading problem entered
> > > > in the todo list.
> > > >
> > > > Is there any other thing to do?
> > >
> > > Restore ContentAggregator's cachebility would be great...
> > > I did not have much time to spent on this, but have run into some
> > > issues...
> > Yes, I agree here with you. The cachebility would really be great,
> > but currently my time is also limited. But perhaps we can work it
> > out until friday.
> > But however we should keep changes as small as possible. I still
> > believe that it is possible to make the CA cacheable without
> > changing any interfaces except the CachedEventObject which could
> > get a timestamp indicating when it was created.
> >
> > > Can we add generateKey/validity methods to Source interface?
> > I think this is not a good design decision as the Source interface
> > only describes a resource. It doesn't know anything about caching.
> > And the decision about how the key (or the validity object) is build
> > can not be made by the Source object. Only the components using
> > a Source object can do this.
>
> That is fine, if you are sure that timestamp would be enough to
> make a decision
> about content's validity.
>
Hi Vadim,
I thought yesterday, that it was me who broke the caching of CA,
so it should be myself who must fix this. And here is the good news:
Actually, I made the CA cacheable last night and will check it in today.
For this I didn't have to change any interface. The cocoon urls
(or the SitemapSource) calculates now a last modification date for the
source and this is used. This makes even the file generator etc.
cacheable if the source is a cocoon url.
>
> > > And, because SitemapSource needs to construct pipeline which should be
> > > reused during generateKey/validity/stream (or
> > > getTimestamp/stream) methods,
> > > it need to a recyclable component...
> > The Source object is not an avalon component, so we can't use the mimic
>
> I know.
>
> > and as the Source object should be as lightweight as possible, I think
> > it is better this way. The Source object is itself "recycle" by calling
> > the "refresh" method.
>
> Is it a contract between Source and component which is uses it
> that refresh()
> _must_ always be called? Then this solves this issue.
>
Yes, it is a contract between them. The component can use the Source
object only once. After that it must call refresh() to use it again.
I hope I can come up with a documentation on url and source handling next
week.
>
> > > And connected to this issue... Should we call HashUtil.hash()
> > > only once during
> > > key generation process for pipeline? Then it's better return
> > > String as a key and
> > > then caller can hash it.
> > Sorry, again I don't agree here. During the pipeline processing the
> > generateKey method is called only once, so the hash function is
> > only called once. So I don't see any overhead here.
>
> You missed the point here. It is called once _per_component_.
> Let's assume that you have following sitemap:
> <aggregator>
> <part>
> <aggregator>
> <part>
> <generator>
> <transformer>
> <transformer>
> </part>
> <part>
> <generator>
> <transformer>
> <transformer>
> </part>
> </aggregator>
> <transformer>
> <transformer>
> </part>
> <part>
> <generator>
> <transformer>
> <transformer>
> </part>
> </aggregator>
> <transformer>
> ...
>
> Every generator/transformer have HashUtul.hash() call, then
> resulting "long"s are combined into
> string and content aggregator calls HashUtul.hash() again, and so
> on (if you have more
> then one level of aggregation). And that's not even performance
> concern here, but the
> quality of the resulting key - could it be that it would degrade
> when you use more levels
> of content aggregation?
>
> That's why I'm thinking that it might be better to hash string
> only once, without
> recursion.
>
Ah, ok, you're right. I think, as the working solution makes no
difference between CA and the normal file generator and no
difference between a cocoon url and a http url, we can leave
everything at it is right now.
The overhead is as minimal as possible without changing interfaces.
Carsten
>
> > And there are components which can generate a key by not using
> > Strings, so it is more performant to use long as the return value
> > than to use Strings and hash them in these cases.
> >
> >
> > Carsten
> >
> > Open Source Group sunShine - b:Integrated
> > ================================================================
> > Carsten Ziegeler, S&N AG, Klingenderstrasse 5, D-33100 Paderborn
> > www.sundn.de mailto: cziegeler@sundn.de
> > ================================================================
> >
> > >
> > > Vadim
> > >
> > > >
> > > > If not, I would propose a code freeze for the end of the week
> > > > and a release date for the beta 2 could be 23rd of july.
> > > >
> > > > What do you think?
> > > >
> > > > Carsten
> > > >
> > > > Open Source Group sunShine - b:Integrated
> > > > ================================================================
> > > > Carsten Ziegeler, S&N AG, Klingenderstrasse 5, D-33100 Paderborn
> > > > www.sundn.de mailto: cziegeler@sundn.de
> > > > ================================================================
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [C2]: Planning beta 2
Posted by Vadim Gritsenko <vg...@hns.com>.
> -----Original Message-----
> From: Carsten Ziegeler [mailto:cziegeler@sundn.de]
> Sent: Wednesday, July 11, 2001 9:33
> To: cocoon-dev@xml.apache.org
> Subject: AW: [C2]: Planning beta 2
>
>
> > Vadim Gritsenko wrote:
> >
> > > -----Original Message-----
> > > From: Carsten Ziegeler [mailto:cziegeler@sundn.de]
> > > Sent: Tuesday, July 10, 2001 4:34
> > > To: Cocoon-Dev@Xml. Apache. Org
> > > Subject: [C2]: Planning beta 2
> > >
> > >
> > > Hi Team,
> > >
> > > I think it is time to plan our next release: beta 2.
> > > Our plans were to make this release in the middle of july and
> > > I think we can realize this.
> > >
> > > Apart from more documentation which is of course important
> > > for the beta 2,
> > > we have *only* to solve the bugs entered in bugzilla and
> > > to finish outstanding issues. One of them is the content length
> > > problem and the other is the class loading problem entered
> > > in the todo list.
> > >
> > > Is there any other thing to do?
> >
> > Restore ContentAggregator's cachebility would be great...
> > I did not have much time to spent on this, but have run into some
> > issues...
> Yes, I agree here with you. The cachebility would really be great,
> but currently my time is also limited. But perhaps we can work it
> out until friday.
> But however we should keep changes as small as possible. I still
> believe that it is possible to make the CA cacheable without
> changing any interfaces except the CachedEventObject which could
> get a timestamp indicating when it was created.
>
> > Can we add generateKey/validity methods to Source interface?
> I think this is not a good design decision as the Source interface
> only describes a resource. It doesn't know anything about caching.
> And the decision about how the key (or the validity object) is build
> can not be made by the Source object. Only the components using
> a Source object can do this.
That is fine, if you are sure that timestamp would be enough to make a decision
about content's validity.
> > And, because SitemapSource needs to construct pipeline which should be
> > reused during generateKey/validity/stream (or
> > getTimestamp/stream) methods,
> > it need to a recyclable component...
> The Source object is not an avalon component, so we can't use the mimic
I know.
> and as the Source object should be as lightweight as possible, I think
> it is better this way. The Source object is itself "recycle" by calling
> the "refresh" method.
Is it a contract between Source and component which is uses it that refresh()
_must_ always be called? Then this solves this issue.
> > And connected to this issue... Should we call HashUtil.hash()
> > only once during
> > key generation process for pipeline? Then it's better return
> > String as a key and
> > then caller can hash it.
> Sorry, again I don't agree here. During the pipeline processing the
> generateKey method is called only once, so the hash function is
> only called once. So I don't see any overhead here.
You missed the point here. It is called once _per_component_.
Let's assume that you have following sitemap:
<aggregator>
<part>
<aggregator>
<part>
<generator>
<transformer>
<transformer>
</part>
<part>
<generator>
<transformer>
<transformer>
</part>
</aggregator>
<transformer>
<transformer>
</part>
<part>
<generator>
<transformer>
<transformer>
</part>
</aggregator>
<transformer>
...
Every generator/transformer have HashUtul.hash() call, then resulting "long"s are combined into
string and content aggregator calls HashUtul.hash() again, and so on (if you have more
then one level of aggregation). And that's not even performance concern here, but the
quality of the resulting key - could it be that it would degrade when you use more levels
of content aggregation?
That's why I'm thinking that it might be better to hash string only once, without
recursion.
> And there are components which can generate a key by not using
> Strings, so it is more performant to use long as the return value
> than to use Strings and hash them in these cases.
>
>
> Carsten
>
> Open Source Group sunShine - b:Integrated
> ================================================================
> Carsten Ziegeler, S&N AG, Klingenderstrasse 5, D-33100 Paderborn
> www.sundn.de mailto: cziegeler@sundn.de
> ================================================================
>
> >
> > Vadim
> >
> > >
> > > If not, I would propose a code freeze for the end of the week
> > > and a release date for the beta 2 could be 23rd of july.
> > >
> > > What do you think?
> > >
> > > Carsten
> > >
> > > Open Source Group sunShine - b:Integrated
> > > ================================================================
> > > Carsten Ziegeler, S&N AG, Klingenderstrasse 5, D-33100 Paderborn
> > > www.sundn.de mailto: cziegeler@sundn.de
> > > ================================================================
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
AW: [C2]: Planning beta 2
Posted by Carsten Ziegeler <cz...@sundn.de>.
> Vadim Gritsenko wrote:
>
> > -----Original Message-----
> > From: Carsten Ziegeler [mailto:cziegeler@sundn.de]
> > Sent: Tuesday, July 10, 2001 4:34
> > To: Cocoon-Dev@Xml. Apache. Org
> > Subject: [C2]: Planning beta 2
> >
> >
> > Hi Team,
> >
> > I think it is time to plan our next release: beta 2.
> > Our plans were to make this release in the middle of july and
> > I think we can realize this.
> >
> > Apart from more documentation which is of course important
> > for the beta 2,
> > we have *only* to solve the bugs entered in bugzilla and
> > to finish outstanding issues. One of them is the content length
> > problem and the other is the class loading problem entered
> > in the todo list.
> >
> > Is there any other thing to do?
>
> Restore ContentAggregator's cachebility would be great...
> I did not have much time to spent on this, but have run into some
> issues...
Yes, I agree here with you. The cachebility would really be great,
but currently my time is also limited. But perhaps we can work it
out until friday.
But however we should keep changes as small as possible. I still
believe that it is possible to make the CA cacheable without
changing any interfaces except the CachedEventObject which could
get a timestamp indicating when it was created.
> Can we add generateKey/validity methods to Source interface?
I think this is not a good design decision as the Source interface
only describes a resource. It doesn't know anything about caching.
And the decision about how the key (or the validity object) is build
can not be made by the Source object. Only the components using
a Source object can do this.
> And, because SitemapSource needs to construct pipeline which should be
> reused during generateKey/validity/stream (or
> getTimestamp/stream) methods,
> it need to a recyclable component...
The Source object is not an avalon component, so we can't use the mimic
and as the Source object should be as lightweight as possible, I think
it is better this way. The Source object is itself "recycle" by calling
the "refresh" method.
> And connected to this issue... Should we call HashUtil.hash()
> only once during
> key generation process for pipeline? Then it's better return
> String as a key and
> then caller can hash it.
Sorry, again I don't agree here. During the pipeline processing the
generateKey method is called only once, so the hash function is
only called once. So I don't see any overhead here.
And there are components which can generate a key by not using
Strings, so it is more performant to use long as the return value
than to use Strings and hash them in these cases.
Carsten
Open Source Group sunShine - b:Integrated
================================================================
Carsten Ziegeler, S&N AG, Klingenderstrasse 5, D-33100 Paderborn
www.sundn.de mailto: cziegeler@sundn.de
================================================================
>
> Vadim
>
> >
> > If not, I would propose a code freeze for the end of the week
> > and a release date for the beta 2 could be 23rd of july.
> >
> > What do you think?
> >
> > Carsten
> >
> > Open Source Group sunShine - b:Integrated
> > ================================================================
> > Carsten Ziegeler, S&N AG, Klingenderstrasse 5, D-33100 Paderborn
> > www.sundn.de mailto: cziegeler@sundn.de
> > ================================================================
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> > For additional commands, email: cocoon-dev-help@xml.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [C2]: Planning beta 2
Posted by Vadim Gritsenko <vg...@hns.com>.
> -----Original Message-----
> From: Carsten Ziegeler [mailto:cziegeler@sundn.de]
> Sent: Tuesday, July 10, 2001 4:34
> To: Cocoon-Dev@Xml. Apache. Org
> Subject: [C2]: Planning beta 2
>
>
> Hi Team,
>
> I think it is time to plan our next release: beta 2.
> Our plans were to make this release in the middle of july and
> I think we can realize this.
>
> Apart from more documentation which is of course important
> for the beta 2,
> we have *only* to solve the bugs entered in bugzilla and
> to finish outstanding issues. One of them is the content length
> problem and the other is the class loading problem entered
> in the todo list.
>
> Is there any other thing to do?
Restore ContentAggregator's cachebility would be great...
I did not have much time to spent on this, but have run into some issues...
Can we add generateKey/validity methods to Source interface?
And, because SitemapSource needs to construct pipeline which should be
reused during generateKey/validity/stream (or getTimestamp/stream) methods,
it need to a recyclable component...
And connected to this issue... Should we call HashUtil.hash() only once during
key generation process for pipeline? Then it's better return String as a key and
then caller can hash it.
Vadim
>
> If not, I would propose a code freeze for the end of the week
> and a release date for the beta 2 could be 23rd of july.
>
> What do you think?
>
> Carsten
>
> Open Source Group sunShine - b:Integrated
> ================================================================
> Carsten Ziegeler, S&N AG, Klingenderstrasse 5, D-33100 Paderborn
> www.sundn.de mailto: cziegeler@sundn.de
> ================================================================
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org