RE: advice

[Carsten Ziegeler]

Stefano Mazzocchi wrote:
> 
> Carsten Ziegeler wrote:
> 
> > Great idea! Let's do that.
> > The only problem I see is that we can't tag 2.1.6 if we do 
> it this way!
> 
> What about 2.1.5bis?
> 
> [bis is latin for "second", used in italian law a lot for 
> these kind of things, Gianugo knows better since he's a lawyer ;-)]
> 
:) "bis" is the german word for "until", Hmm :)

Carsten

RE: OWLQLTransfomer + RDQLTransformer

[Corin Moss]

Hiya,

Any idea when this will make it to CVS?  I'm almost salivating at the
thought of a cocoon RDF Query Transformer! 

Have you been able to do any bench marks on performance vs XPath or
XQuery?

Looking forward to seeing it!

Corin

-Original Message-
From: Stefano Mazzocchi [mailto:[EMAIL PROTECTED]
Sent: Friday, 9 July 2004 5:02 a.m.
To: [EMAIL PROTECTED]
Subject: Re: OWLQLTransfomer + RDQLTransformer


Halgurt Mustafa-Ali wrote:

> Hi all,
>
> I am a student of the technical university in Munich. I am working on
> a software
> development project. I wrote 2 Transformers. both for extracting data
from
> knowledge bases (OWL, RDF, DAML etc). The RADQTransformer uses rdql
(RDF query
> language), it works like the SQLTransformer. And the OWLQLTransformer
uses
> owl-ql (a query language for owl and daml). So the question: Are you
interested
> in these Transformers? and whom shall I send the source code and the
Examples?

AWESOME! I love it!!!

Send it to me, it was in my todo list for a long time ;-)

I'll start a semweb block in the repository: prepare people, the semweb
is coming to getcha :-)

--
Stefano.


CAUTION: This e-mail and any attachment(s) contains information
that is intended to be read only by the named recipient(s). It
may contain information that is confidential, proprietary or the
subject of legal privilege. This information is not to be used by
any other person and/or organisation. If you are not the intended
recipient, please advise us immediately and delete this e-mail
from your system. Do not use any information contained in it.


For more information on the Television New Zealand Group, visit
us online at http://www.tvnz.co.nz

Re: XMLDBSource and credentials

[Luigi Bai]

Upayavira wrote:
Luigi Bai wrote:
I'd like to modify XMLDBSource to allow the URI to override the 
credential information. This would allow different users to access 
collections/resources as themselves in eXist (http://exist.sf.net).

Any objections? My first thought is to allow URIs of the form:
xmldb:exist://user:[EMAIL PROTECTED]:port/coll/coll/resource.xml
I take it there is no such definition of providing user/pass within the 
XMLDB spec?

Regards, Upayavira
Authentication is handled by username and password parameters to methods 
on the org.xmldb.api.base.Database interface. The XMLDB spec is silent 
about handling userinfo in the URI itself. The org.cocoon...XMLDBSource 
gets around this by configuring authentication information into the 
 element, and then passing that through to the relevant 
interface methods when necessary (see Bugzilla for a recent patch of 
that behaviour). However, that is static: only one username and password 
can be configured per protocol scheme (i.e.; xmldb:).

What I'm proposing is effectively allowing just-in-time specification of 
username and password in  elements.

--
http://www.focalpoint.com/";>Home Page
education is what's left after what is learned is forgotten.
   -- b f skinner
Luigi P. Bai   Focal Point Software, Inc.
[EMAIL PROTECTED] 3701 Kirby Drive, Suite 512
turning data into information  Houston, TX   77098
   (713) 215-1600 x 33#

Re: XMLDBSource and credentials

[Upayavira]

Luigi Bai wrote:
I'd like to modify XMLDBSource to allow the URI to override the 
credential information. This would allow different users to access 
collections/resources as themselves in eXist (http://exist.sf.net).

Any objections? My first thought is to allow URIs of the form:
xmldb:exist://user:[EMAIL PROTECTED]:port/coll/coll/resource.xml
I take it there is no such definition of providing user/pass within the 
XMLDB spec?

Regards, Upayavira

XMLDBSource and credentials

[Luigi Bai]

I'd like to modify XMLDBSource to allow the URI to override the 
credential information. This would allow different users to access 
collections/resources as themselves in eXist (http://exist.sf.net).

Any objections? My first thought is to allow URIs of the form:
xmldb:exist://user:[EMAIL PROTECTED]:port/coll/coll/resource.xml
--
http://www.focalpoint.com/";>Home Page
education is what's left after what is learned is forgotten.
   -- b f skinner
Luigi P. Bai   Focal Point Software, Inc.
[EMAIL PROTECTED] 3701 Kirby Drive, Suite 512
turning data into information  Houston, TX   77098
   (713) 215-1600 x 33#

[RT] Document based I18n sites with Cocoon

[Upayavira]

I'm building a 'document centric' internationalised site which, to my 
mind, Cocoon can't 'quite' do yet. Cocoon's i18n functionality works 
well on 'webapps', where you have snippets of text to be translated, but 
not when the content is whole pages.

The most complex part of this is identifying the most appropriate 
language content, given the combination of the user's desired 
locales/languages, and the available translations.

The site will cater for locale provided as a request parameter, as the 
one of the acceptable locales configured within the browser, or as a 
site default.

When a page is requested, it will look for a page with the preferred 
locale (request parameter, if provided), if not found, it will look for 
a page using each of the locales in turn. If none are found, the default 
page is used.

So, say we have three locales to try: pt, es, en. We have resources:
content/pl/foo.xml
content/es/foo.xml
content/en/foo.xml
When the user requests foo.html, Cocoon will look to see if 
content/pt/foo.xml exists. It doesn't, so it will look for 
content/es/foo.xml. That it finds, so that is what it uses to as a 
source for the pipeline.

Similarly, this system would be able to handle a file structure such as:
content/foo_pl.xml
content/foo_es.xml
content/foo_en.xml
Now, handling this functionality within a Cocoon component really isn't 
that easy to work out. To achieve it, the component needs to take a 
configurable path, e.g content/{locale}/{1}.xml, and needs to be told 
what to use for finding the locale (request param, accept-language 
header, default locale for site). Once it has made a decision, it might 
also want to make its choice of locale available to other components 
(e.g. the i18nTransformer) so that it can localise any other bits of 
text on the page, e.g. navigation.

I have mulled on whether an input module, a generator or maybe an action 
would do the job. In fact, I think it is a job for an I18n matcher.

Introducing the I18NMatcher
---
Here's a sample sitemap snippet:

 
   
   
   
 
   
   
 

Once an ordinary wildcard matcher has done its job, in comes the i18n 
matcher. Its job is to see whether it can find a suitable source 
document for the requested page. The * is used to symbolise the place 
where the locale is to be placed. If a match is successful, it will make 
sitemap variables available for the source that was found, and the 
locale that matched.

Now, this seems to be quite in keeping with the Cocoon sitemap model, 
and gives some rather nice, flexible functionality.

What do you all think?
When I've finished implementing this, I'll go onto extend the CLI to be 
able to work effectively with this kind on i18n site, enableing it to 
crawl a site for each of a range of locales. But that's for another time.
  
Regards, Upayavira

Re: [GUMP] please remove/rename the nekohtml project in Cocoon's descriptor

[Upayavira]

Stefan Bodewig wrote:
Hi,
Gump already has a project named nekohtml for NekoHTML 0.9.3.  If this
is what you need in Cocoon then please simple remove your project
definition, otherwise please rename the project.
Gump tries to merge the like-named project and drops both of them
since their jar ids clash (and would claim there were missing build
outputs if the ids didn't clash).
 

Done.
Sorry for the hassle. I'm a complete Gump newbie, and figured I would 
get something wrong!

Regards, Upayavira

Re: Cocoon 2.1.5 as a FreeBSD port

[Tony Collen]

Juan Jose Pablos wrote:
Stefano Mazzocchi escribió:
Sylvain Wallez wrote:
Hi all,
Jean-Baptiste Quenot, a colleague of mine, made a FreeBSD port of 
Cocoon 2.1.5, replacing the previous one which was based on... Cocoon 
1.8.3!!

See http://www.freshports.org/textproc/cocoon/
The port includes a GUI to specify which blocks are to be included by 
the build.
Wooohoo :) :)
This is something that I was thinking about not that long ago, and 
discussing it with someone.

NICE!! we should put this information on the web!!!
There used to be a debian package as well but, again, it was based on 
1.8.2!!

I would *ROCK* to have a debian package for cocoon and a fink one too ;-)
on the bug report ( http://bugs.debian.org/221219 ) you can read:
"The problem is that it can not be built without very much hassle on
a Debian system. The problem is that it depends hard on a specific
jvm (that do not exist in debian)."
Yep, this is the same problem that I was discussing with someone. 
That, and from what I gathered, Debian is pretty pragmatic about 
dependencies, so we might run into problems with all the JARs that we 
include with the distribution.

The FreeBSD ports idea is pretty cool, and I look forward to when we 
have a whole mess of Real Blocks as separate BSD ports.

Tony

Re: Cocoon 2.1.5 as a FreeBSD port

[Juan Jose Pablos]

Stefano Mazzocchi escribió:
Sylvain Wallez wrote:
Hi all,
Jean-Baptiste Quenot, a colleague of mine, made a FreeBSD port of 
Cocoon 2.1.5, replacing the previous one which was based on... Cocoon 
1.8.3!!

See http://www.freshports.org/textproc/cocoon/
The port includes a GUI to specify which blocks are to be included by 
the build.

NICE!! we should put this information on the web!!!
There used to be a debian package as well but, again, it was based on 
1.8.2!!

I would *ROCK* to have a debian package for cocoon and a fink one too ;-)
on the bug report ( http://bugs.debian.org/221219 ) you can read:
"The problem is that it can not be built without very much hassle on
a Debian system. The problem is that it depends hard on a specific
jvm (that do not exist in debian)."

Re: Cocoon 2.1.5 as a FreeBSD port

[Stefano Mazzocchi]

Ralph Goers wrote:
Out of curiosity, why does one need to "port" a pure Java app to 
FreeBSD?  The GUI sounds good though. Can it be incorporated into Cocoon?
nonono
A "port" in FreeBSD is a package, like an RPM or a DEB package for linux.
--
Stefano.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: OWLQLTransfomer + RDQLTransformer

[Stefano Mazzocchi]

Halgurt Mustafa-Ali wrote:
Hi all,
I am a student of the technical university in Munich. I am working on a software 
development project. I wrote 2 Transformers. both for extracting data from 
knowledge bases (OWL, RDF, DAML etc). The RADQTransformer uses rdql (RDF query 
language), it works like the SQLTransformer. And the OWLQLTransformer uses 
owl-ql (a query language for owl and daml). So the question: Are you interested 
in these Transformers? and whom shall I send the source code and the Examples?
AWESOME! I love it!!!
Send it to me, it was in my todo list for a long time ;-)
I'll start a semweb block in the repository: prepare people, the semweb 
is coming to getcha :-)

--
Stefano.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: Cocoon 2.1.5 as a FreeBSD port

[Stefano Mazzocchi]

Sylvain Wallez wrote:
Hi all,
Jean-Baptiste Quenot, a colleague of mine, made a FreeBSD port of Cocoon 
2.1.5, replacing the previous one which was based on... Cocoon 1.8.3!!

See http://www.freshports.org/textproc/cocoon/
The port includes a GUI to specify which blocks are to be included by 
the build.
NICE!! we should put this information on the web!!!
There used to be a debian package as well but, again, it was based on 
1.8.2!!

I would *ROCK* to have a debian package for cocoon and a fink one too ;-)
--
Stefano.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: advice

[Stefano Mazzocchi]

Andreas Kuckartz wrote:
Dirk-Willem van Gulik wrote:
what happened on a sunny day in 2004 the day we are in hostile takeover
talks with the by then virtual monopolist RHSCO.
That will only happen in a few parallel universes.
After experiencing what a few votes in florida can do, I wouldn't be so 
dismissive about worst case scenario.

--
Stefano.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: advice

[Stefano Mazzocchi]

Carsten Ziegeler wrote:
Great idea! Let's do that.
The only problem I see is that we can't tag 2.1.6 if we do it this way!
What about 2.1.5bis?
[bis is latin for "second", used in italian law a lot for these kind of 
things, Gianugo knows better since he's a lawyer ;-)]

--
Stefano.


smime.p7s
Description: S/MIME Cryptographic Signature

[Patch:new] Oracle auto. increment impl. for Modual Database Action

[tc]

My first contribution, please review!
regards,

TC
=== OraIncrementModule.java
package org.apache.cocoon.components.modules.database;

import java.lang.Integer;
import java.sql.PreparedStatement;
import java.sql.Connection;
import java.sql.ResultSet;
import java.sql.Statement;
import java.sql.SQLException;
import java.util.Map;
import org.apache.avalon.framework.configuration.*;
import org.apache.avalon.framework.thread.ThreadSafe;
import org.apache.cocoon.components.modules.database.*;
import org.apache.avalon.framework.logger.AbstractLogEnabled;

/**
 * This is an impl. on behalf of an ORACLE sequence defined in your schema
for getting an automatic incremental ID.
 * A total of 2 queries will be sent to the DB.
 *
 * The 1st one is for getting a snapshot of the latest sequence id,
which will be availabe in the sitemap for other usage.
 * The 2nd one is for inserting record(s) into the target table.
 * 
 * NOTE:: If the sequence-id is NOT needed in sitemap, please use
org.apache.cocoon.components.modules.database.OraShortIncrementModule
to save the effort of the first query.
 *
 * In cocoon.xconf, one could declare such an auto module as:
 *
 *
 *  
 *
 * In the mdb configuartion file definition,
 *
 *...
 *   ...
 *  
 * 
 *
 * where mode/@sequence is u're Oracle sequence name and 
 * mode/@reqAttr is the name of a req. attribute containing a value of the
sequence which is also available in sitemap via
{request-attr:seqid-in-sitemap}.
 **/
public class OraSeqIncrementModule extends AbstractAutoIncrementModule
implements ThreadSafe {

/**
 * @return: true, key value is needed in the final query.
 **/
public boolean includeInQuery() {
return true;
}

/**
 * @return true: key appears as a value; 2 queries will be sent to the
DB.
 **/
public boolean includeAsValue() {
return true;
}

/**
 * a query for getting the NEXTVAL out of a sequence.
 * Such a NEXTVAL value will be set as a String into a request
attribute, whose name=/@reqAttr. Therefore, such a sequence
number is available in the sitemap thru
{request-attr:<[EMAIL PROTECTED]>}
 **/
public Object getPreValue( Configuration tableConf, Configuration
columnConf, Configuration modeConf, Connection conn, Map objectModel )
throws SQLException, ConfigurationException {
String sequence = modeConf.getAttribute("sequence", null);
if( null==sequence )
throw new ConfigurationException("ERROR!!! Please define your
sequence name in mdb file, under
table[name="+tableConf.getAttribute("name")+"]/[EMAIL 
PROTECTED]"+columnConf.getAttribute("name")+"]/mode/@sequence"
);
String reqAttr = modeConf.getAttribute("reqAttr", null);
PreparedStatement pstmt= conn.prepareStatement( "select
"+sequence+".NEXTVAL AS nextid from dual" );
ResultSet rs= pstmt.executeQuery();
rs.next();
Integer nextid= new Integer(rs.getInt("nextid"));
pstmt.close();
if (getLogger().isDebugEnabled())
getLogger().debug("ORA sequence:"+sequence+".NextVal= "+nextid );
if( null!=reqAttr )

org.apache.cocoon.environment.ObjectModelHelper.getRequest(objectModel).setAttribute(reqAttr,
nextid.toString() );
return nextid;
}

public Object getPostValue( Configuration tableConf, Configuration
columnConf, Configuration modeConf, Connection conn, Statement stmt,
Map objectModel )  throws SQLException, ConfigurationException {
return null;
}

public String getSubquery( Configuration tableConf, Configuration
columnConf, Configuration modeConf)
throws ConfigurationException {
return null;
}

}


= OraShortIncrementModule.java
package org.apache.cocoon.components.modules.database;

import java.lang.Integer;
import java.sql.PreparedStatement;
import java.sql.Connection;
import java.sql.ResultSet;
import java.sql.Statement;
import java.sql.SQLException;
import java.util.Map;
import org.apache.avalon.framework.configuration.*;
import org.apache.avalon.framework.thread.ThreadSafe;
import org.apache.cocoon.components.modules.database.*;
import org.apache.avalon.framework.logger.AbstractLogEnabled;

/**
 * This is an impl. on behalf of an ORACLE sequence defined in your schema
for getting an automatic incremental ID.
 * Only one insert query will be sent to the DB-table with a snapshot
value out of a sequence.
 * NOTE:: If the sequence-id is needed in sitemap, please use
org.apache.cocoon.components.modules.database.OraIncrementModule;
which costs U one more query for getting the sequence and make it
available to the sitemap as a request attributre.
 *
 * In cocoon.xconf, one could declare such an auto module as:
 *
 *
 *  
 *
 * In the mdb configuartion file definition,
 *
 *...
 *   ...
 *  
 * 
 *
 * where mode/@sequence is u're Oracle sequence name.
 **/
public class OraSeqShortIncrementModule extends 

Re: Cocoon 2.1.5 as a FreeBSD port

[Jean-Baptiste Quenot]

* Ralph Goers:

> Out of  curiosity, why  does one  need to  "port" a  pure Java  app to
> FreeBSD?   The GUI  sounds good  though. Can it  be incorporated  into
> Cocoon?

The  FreeBSD « ports »  is a  collection  of applications,  ready to  be
installed.  Porting an application means ensuring it builds and installs
properly, not necessarily modifying the source code.  It's rather a kind
of packaging for this specific platform.

The gui for  choosing compile-time options cannot  be incorporated as-is
into Cocoon, because it relies intensively on the FreeBSD ports system.

Best regards,
-- 
Jean-Baptiste Quenot
http://caraldi.com/jbq/

[GUMP] please remove/rename the nekohtml project in Cocoon's descriptor

[Stefan Bodewig]

Hi,

Gump already has a project named nekohtml for NekoHTML 0.9.3.  If this
is what you need in Cocoon then please simple remove your project
definition, otherwise please rename the project.

Gump tries to merge the like-named project and drops both of them
since their jar ids clash (and would claim there were missing build
outputs if the ids didn't clash).

Stefan

Re: Caching of generated XSP.

[Vadim Gritsenko]

Scott Payne wrote:
Hi,
I'm taking up a thread about caching of generated XSPs started at
http://marc.theaimsgroup.com/?l=xml-cocoon-users&m=107880112301284&w=2.
 

Snippet from this link:

  
  
   



  
  
   



I've ported the patches in
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26725 to the 2.1.5 source
but we still seem to have a bit of a bottle-neck.
Although the new EnvironmentWrapper now has a getLastModified() method, the
lastModified field is only set by the isResponseModified() method, which
doesn't seem to be called for the generated content. Therefore the
getLastModified() method always returns 0, and the java file always gets
regenerated.
So, my question is, has anyone tried to get this working without the
regeneration? Is there somewhere appropriate we should set the lastModified
time for the SitemapSource instance representing the generated XSP?
 

Looking at the sitemap snippet above, the answer is, page.xsp should be 
cacheable, and I guess it is not cacheable at the moment. See XSP 
examples for the details.

Vadim

RE: cronjob and cocoonpipelinecronjob

[arnaud DANEELS]

Hello, 

Thanks for your answer.

Finaly, I compile cron blocks version cocoon 2.1.5 with 
Cocoonpipelinecronjob.java in the source directory: it works fine...
(trigger and component) I see this in the cron.log. the pipeline works fine
as well in standalone calls.

But I don't understand why this block don't work in cocoon-2.2.0 block cvs.
A lot of things have changed in the cocoon source: modification of
QuartzJobExecutor.java and BackgroundEnvironment.java by C.

Have you further details about this modifications ?

Regards arnaud 




-Message d'origine-
De : Jeremy Quinn [mailto:[EMAIL PROTECTED] 
Envoyé : jeudi 8 juillet 2004 10:43
À : [EMAIL PROTECTED]
Objet : Re: cronjob and cocoonpipelinecronjob

Could you show us your configuration?

How have you configured the CocoonPipelineCronJob and it's trigger.

Have you tested the pipeline it calls, independently?

regards Jeremy

On 7 Jul 2004, at 14:57, arnaud DANEELS wrote:

> Hi,
>
>  
>
>     I need some help with cocoon-2.2.0-dev with cronjob and  
> CocoonPipelineCronJob functionnality
>
>  
>
>     Samples of cron (testcronjob) don’t work in this version of  
> cocoon. (he did in the 2.1.5):
>
>   
>
> INFO    (2004-07-07) 15:55.06:024   [cron]  
> Unknown-thread/QuartzJobExecutor: Scheduling cron job named 'test'
>
> INFO    (2004-07-07) 15:55.06:039   [cron.test]  
> Unknown-thread/TestCronJob: CronJob test launched at Wed Jul 07  
> 15:55:06 CEST 2004 with message 'I'm here' and sleep timeout of  
> 23000ms
>
> ERROR   (2004-07-07) 15:55.06:039   [cron]  
> Unknown-thread/QuartzJobExecutor: Cron job name 'test died.
>
> org.apache.avalon.framework.CascadingRuntimeException: CronJob test  
> raised an exception
>
>     at  
> org.apache.cocoon.components.cron.TestCronJob.execute(TestCronJob.java: 
> 100)
>
>     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native  
> Method)
>
>     at  
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.ja 
> va:39)
>
>     at  
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccesso 
> rImpl.java:25)
>
>     at java.lang.reflect.Method.invoke(Method.java:324)
>
>     at  
> org.apache.avalon.excalibur.component.ComponentProxyGenerator$Component 
> InvocationHandler.invoke(ComponentProxyGenerator.java:143)
>
>     at $Proxy14.execute(Unknown Source)
>
>     at  
> org.apache.cocoon.components.cron.QuartzJobExecutor.execute(QuartzJobEx 
> ecutor.java:109)
>
>     at org.quartz.core.JobRunShell.run(JobRunShell.java:188)
>
>     at  
> EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(Unknown  
> Source)
>
>     at java.lang.Thread.run(Thread.java:534)
>
> Caused by: java.lang.UnsupportedOperationException
>
>     at  
> org.apache.cocoon.environment.background.BackgroundEnvironment$NullProc 
> essor.getContext(BackgroundEnvironment.java:164)
>
>     at  
> org.apache.cocoon.components.source.CocoonSourceResolver.resolveURI(Coc 
> oonSourceResolver.java:55)
>
>     at  
> org.apache.cocoon.components.source.CocoonSourceResolver.resolveURI(Coc 
> oonSourceResolver.java:70)
>
>     at  
> org.apache.cocoon.components.cron.TestCronJob.execute(TestCronJob.java: 
> 83)
>
>     ... 10 more
>
>  
>
>     In the 2.2.0 dev, libraries are updated to 1.4 for quartz.jar and  
> 1.3.4 for util-current and cocoonpipelinecronjob is
>
>      added to cron block.
>
>  
>
>  
>
>     Have you any idea about this problem  and test this functionnality
>
>  
>
> Thank you for your help.
>
>  
>
> Arnaud
>


   If email from this address is not signed
 IT IS NOT FROM ME

 Always check the label, folks !

Re: Cocoon 2.1.5 as a FreeBSD port

[Ralph Goers]

Out of curiosity, why does one need to "port" a pure Java app to 
FreeBSD?  The GUI sounds good though. Can it be incorporated into Cocoon?

Ralph
At 7/8/2004  01:58 AM, you wrote:
Hi all,
Jean-Baptiste Quenot, a colleague of mine, made a FreeBSD port of Cocoon 
2.1.5, replacing the previous one which was based on... Cocoon 1.8.3!!

See http://www.freshports.org/textproc/cocoon/
The port includes a GUI to specify which blocks are to be included by the 
build.

Enjoy,
Sylain
--
Sylvain Wallez  Anyware Technologies
http://www.apache.org/~sylvain   http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }

Re: Releasing 2.1.5.1

[Sylvain Wallez]

Carsten Ziegeler wrote:
At least we have the hope that this will help avoiding such problems.
To be honest, I suspect that even if we had a tarball before, noone
would have noticed the missing files. See how long it took until
someone found out! 

Anyways: plus +1 - let's give it a try starting with 2.1.6
 

+1, and +1 also for releasing 2.1.5.1
Sylvain
--
Sylvain Wallez  Anyware Technologies
http://www.apache.org/~sylvain   http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }

OWLQLTransfomer + RDQLTransformer

[Halgurt Mustafa-Ali]

Hi all,

I am a student of the technical university in Munich. I am working on a software 
development project. I wrote 2 Transformers. both for extracting data from 
knowledge bases (OWL, RDF, DAML etc). The RADQTransformer uses rdql (RDF query 
language), it works like the SQLTransformer. And the OWLQLTransformer uses 
owl-ql (a query language for owl and daml). So the question: Are you interested 
in these Transformers? and whom shall I send the source code and the Examples?

Best regards,
Halgurt
>X-Sieve: CMU Sieve 2.2
>Delivered-To: [EMAIL PROTECTED]
>Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
>list-help: 
>list-unsubscribe: 
>list-post: 
>Delivered-To: mailing list [EMAIL PROTECTED]
>X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests=
>X-Spam-Check-By: apache.org
>Date: Thu, 08 Jul 2004 13:20:33 +0200
>From: Torsten Curdt <[EMAIL PROTECTED]>
>User-Agent: Mozilla Thunderbird 0.7.1 (Windows/20040626)
>X-Accept-Language: en-us, en
>MIME-Version: 1.0
>To: [EMAIL PROTECTED]
>Subject: Re: Releasing 2.1.5.1
>X-Enigmail-Version: 0.84.2.0
>X-Enigmail-Supports: pgp-inline, pgp-mime
>Content-Transfer-Encoding: 7bit
>X-Virus-Checked: Checked
>X-Spam-Checker-Version: SpamAssassin 2.63-tuminfo (2004-01-11) on  
mailin2.informatik.tu-muenchen.de
>X-Spam-Status: No, hits=-4.9 required=6.0 tests=BAYES_00 autolearn=ham  
version=2.63-tuminfo
>X-Spam-Level: 
>X-Virus-Scanned: by amavisd-new at informatik.tu-muenchen.de
>
>> Anyways: plus +1 - let's give it a try starting with 2.1.6
>
>yepp +1 :)
>
>cheers
>--
>Torsten
>

RE: Cocoon JSR 168 Portlet in Cocoon Portal

[Carsten Ziegeler]

Looks good to me!

Thanks
Carsten 

> -Original Message-
> From: Vadim Gritsenko [mailto:[EMAIL PROTECTED] 
> Sent: Thursday, July 08, 2004 2:43 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Cocoon JSR 168 Portlet in Cocoon Portal
> 
> Carsten Ziegeler wrote:
> 
> >Vadim Gritsenko wrote:
> >  
> >
> >>It's actually very easy to reproduce:
> >>1. cvs up
> >>2. build clean; build
> >>3. cocoon servlet
> >>4. http://localhost:/samples/blocks/portal/portal
> >>5. login
> >>6. JSR-168 tab
> >>
> >>Exception is printed neatly within "JSR-168 Cocoon Portlet" 
> >>content pane.
> >>
> >>Please bear in mind, call stack here is the following:
> >>  CocoonServlet
> >>   Cocoon (1)
> >>Treeprocessor, ...
> >> CopletSource
> >>  ManagedCocoonPortlet
> >>   Cocoon (2)
> >>EnvironmentHelper
> >>
> >>Where, (1) and (2) are the same instance of the Cocoon 
> class, on the 
> >>same thread. I think that's why it is confused. Here is 
> head of trace.
> >>
> >>
> >>
> >Ah, ok, than life is much simpler :)
> >The check currently assumes that on method entry the stack stored in 
> >the thread local is empty. Thus it checks on exit if the 
> stack is empty 
> >again.
> >We could store the current number of elements in the stack on method 
> >entry and check if the stack has the same size on exit. This 
> would just 
> >be a local int variable.
> >WDYT?
> >  
> >
> 
> Done, please double check :-)
> 
> Demo works out of the box now.
> 
> Vadim
> 
> 

Re: Cocoon JSR 168 Portlet in Cocoon Portal

[Vadim Gritsenko]

Carsten Ziegeler wrote:
Vadim Gritsenko wrote:
 

It's actually very easy to reproduce:
1. cvs up
2. build clean; build
3. cocoon servlet
4. http://localhost:/samples/blocks/portal/portal
5. login
6. JSR-168 tab
Exception is printed neatly within "JSR-168 Cocoon Portlet" 
content pane.

Please bear in mind, call stack here is the following:
 CocoonServlet
  Cocoon (1)
   Treeprocessor, ...
CopletSource
 ManagedCocoonPortlet
  Cocoon (2)
   EnvironmentHelper
Where, (1) and (2) are the same instance of the Cocoon class, 
on the same thread. I think that's why it is confused. Here 
is head of trace.

   

Ah, ok, than life is much simpler :)
The check currently assumes that on method entry the stack
stored in the thread local is empty. Thus it checks on exit
if the stack is empty again.
We could store the current number of elements in the stack
on method entry and check if the stack has the same size
on exit. This would just be a local int variable.
WDYT?
 

Done, please double check :-)
Demo works out of the box now.
Vadim

Re: Releasing 2.1.5.1

[Torsten Curdt]

Anyways: plus +1 - let's give it a try starting with 2.1.6
yepp +1 :)
cheers
--
Torsten

Re: Is there a way to revert to the old "store"?

[Vadim Gritsenko]

bernhard huber wrote:
Guys, I'm seeing some problems on 2.1.5 and 2.2 which don't happen on 
2.1.5-dev.
I am guessing that something is wrong with the new JCS-based store...
Is there a way to revert back without re-implementing the whole thing?
   

running some tests i had following experiences
A   B
100 71ms
200670ms
500   4917ms
1000 28221ms
A .. number of string entries to be cached
B .. measured time in ms
Seems that caching time rises not linear using JCS.
Memory cache is implemented by org.apache.jcs.engine.LRUMemoryCache, and 
I think it is being used by Cocoon (as configured in default.ccf). 
Method of adding an entry looks like O(log(n)), with the exception of 
one statement:

   if ( map.size() != dumpCacheSize() )
   {
 log.error( "update: After spool, size mismatch: map.size() = "
+ map.size() + ", linked list size = " +
dumpCacheSize() );
   }
Which forces linear scan of linked list. For large caches, this should 
be one of the reasons of slow performance. Another reason I can think of 
can be synchronization in the heavy-multithreaded environment.

Pier, you can also take a look at MRUMemoryStore / MRUBucketMap pair- it 
supposed to be faster replacement of excalibur's store.

Vadim

RE: Releasing 2.1.5.1

[Carsten Ziegeler]

Nicola Ken Barozzi wrote:
> 
> A typical scenario is that the release manager uploads the 
> tarballs along with the checksums on his private web space at 
> Apache, and that a vote is done on those after - let's say - 
> 72 hours. If the vote is ok then the release manager can 
> simply move the files in the dist section.
> 
Yes, I'm fine with this - as long as we don't checkin anything
between the tarball has been created and the release takes place.

> > My naiv understanding was that we all test the tarballs during our 
> > code freeze, so actually I thought we vote on a "virtual tarball"
> > so to speak.
> 
> Going 'real' instead of 'virtual' could help us not repeat 
> the same mistake we have done now. It makes it possible to 
> have the actual tarball be reviewed by all that want to (and 
> that should if they vote IMHO).
> 
At least we have the hope that this will help avoiding such problems.
To be honest, I suspect that even if we had a tarball before, noone
would have noticed the missing files. See how long it took until
someone found out! 

Anyways: plus +1 - let's give it a try starting with 2.1.6

Carsten

Re: Releasing 2.1.5.1

[Nicola Ken Barozzi]

Carsten Ziegeler wrote:
Nicola Ken Barozzi wrote:
...
We should start of taking the habit of voting the release of 
the actual tarballs.
...
Now, how do we want to do this practically. Imho this would require
that we build the tarballs and give people time to test them (some
days) so they can really vote on them.
A typical scenario is that the release manager uploads the tarballs 
along with the checksums on his private web space at Apache, and that a 
vote is done on those after - let's say - 72 hours. If the vote is ok 
then the release manager can simply move the files in the dist section.

My naiv understanding was that we all test the tarballs during our
code freeze, so actually I thought we vote on a "virtual tarball" 
so to speak.
Going 'real' instead of 'virtual' could help us not repeat the same 
mistake we have done now. It makes it possible to have the actual 
tarball be reviewed by all that want to (and that should if they vote IMHO).

--
Nicola Ken Barozzi   [EMAIL PROTECTED]
- verba volant, scripta manent -
   (discussions get forgotten, just code remains)
-

RE: Releasing 2.1.5.1

[Carsten Ziegeler]

Nicola Ken Barozzi wrote:
> 
> Carsten Ziegeler wrote:
> 
> > I'm planning to release 2.1.5.1 (2.1.5 + the two missing files) 
> > tomorrow morning if noone objects.
> > 
> > I will create a branch in CVS from 2.1.5, change the build script 
> > accordingly and do the usual release process (without testing :) )
> > 
> > I hope this is ok with everybody?
> 
> We should start of taking the habit of voting the release of 
> the actual tarballs.
> 
Ok, I'm not against it, but I think it's not necessary of 2.1.5.1
as it's really 2.1.5 plus the two files - but we can do it there
as well. 

Now, how do we want to do this practically. Imho this would require
that we build the tarballs and give people time to test them (some
days) so they can really vote on them.

My naiv understanding was that we all test the tarballs during our
code freeze, so actually I thought we vote on a "virtual tarball" 
so to speak.

Carsten

Re: Nasty flowscript issue - nailed

[Andrew Savory]

Hi,
On 7 Jul 2004, at 17:17, Gianugo Rabellino wrote:
On Jul 7, 2004, at 8:03 AM, Sylvain Wallez wrote:

Giaunugo, I committed the unique ID fix (using an instance counter). 
Can you please crosscheck?

Thanks so much Sylvain! I'm out of the office for the next two days, 
but I'll get back to you ASAP if Andrew/Jerm don't beat me at it...
Ok, I've tried it out and it seems to do the trick. Thanks very much 
for your help, Sylvain!

Andrew.
--
Andrew Savory, Managing Director, Luminas Limited
Tel: +44 (0)870 741 6658  Fax: +44 (0)700 598 1135
Web: http://www.luminas.co.uk/
Orixo alliance: http://www.orixo.com/

Re: Releasing 2.1.5.1

[Vadim Gritsenko]

Carsten Ziegeler wrote:
I'm planning to release 2.1.5.1 (2.1.5 + the two missing files)
tomorrow morning if noone objects.
I will create a branch in CVS from 2.1.5, change the build script
accordingly and do the usual release process (without testing :) )
I hope this is ok with everybody?
 

Great. +1.
Vadim

Re: Releasing 2.1.5.1

[Unico Hommes]

Nicola Ken Barozzi wrote:
Carsten Ziegeler wrote:
I'm planning to release 2.1.5.1 (2.1.5 + the two missing files)
tomorrow morning if noone objects.
I will create a branch in CVS from 2.1.5, change the build script
accordingly and do the usual release process (without testing :) )
I hope this is ok with everybody?

We should start of taking the habit of voting the release of the 
actual tarballs.

+1 Exactly my thoughts
--
Unico

Re: Releasing 2.1.5.1

[Nicola Ken Barozzi]

Carsten Ziegeler wrote:
I'm planning to release 2.1.5.1 (2.1.5 + the two missing files)
tomorrow morning if noone objects.
I will create a branch in CVS from 2.1.5, change the build script
accordingly and do the usual release process (without testing :) )
I hope this is ok with everybody?
We should start of taking the habit of voting the release of the actual 
tarballs.

--
Nicola Ken Barozzi   [EMAIL PROTECTED]
- verba volant, scripta manent -
   (discussions get forgotten, just code remains)
-

Releasing 2.1.5.1

[Carsten Ziegeler]

I'm planning to release 2.1.5.1 (2.1.5 + the two missing files)
tomorrow morning if noone objects.

I will create a branch in CVS from 2.1.5, change the build script
accordingly and do the usual release process (without testing :) )

I hope this is ok with everybody?

Carsten 

Carsten Ziegeler 
Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.net/weblogs/rael/

Re: inserver unit testing

[Claas Thiele]

Sylvain Wallez wrote:
It certainly can help... if we can get our hands on the code ;-)
If you consider contributing this code, please add it to bugzilla.
Thanks,
Sylvain
Done. Its Bugzilla Bug 29970

Claas

DO NOT REPLY [Bug 29970] - [PATCH] inserver junit testing

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=29970

[PATCH] inserver junit testing





--- Additional Comments From [EMAIL PROTECTED]  2004-07-08 09:25 ---
Created an attachment (id=12059)
sources and a README as *.tgz

DO NOT REPLY [Bug 29970] New: - [PATCH] inserver junit testing

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=29970

[PATCH] inserver junit testing

   Summary: [PATCH] inserver junit testing
   Product: Cocoon 2
   Version: Current CVS 2.1
  Platform: All
OS/Version: All
Status: NEW
  Severity: Normal
  Priority: Other
 Component: general components
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


This piece of code allows junit test in a normal server environment.
mockup objects for building up an test environment not needed anymore. Automated
testing of Cocoon components in a special servlet container like Weblogic should
be easier now.
Reporting is as for 'normal' JUnit tests.

There is a CocoonTestCase extending TestCase having the objectmodel and
servicemanager as member variables. This is the base class for testcases running
on serverside. And there is a TestCaseReader to be included in the sitemap. Its
for activating the testcases and sending back the results.

See the README in the uploaded tgz.

Cocoon 2.1.5 as a FreeBSD port

[Sylvain Wallez]

Hi all,
Jean-Baptiste Quenot, a colleague of mine, made a FreeBSD port of Cocoon 
2.1.5, replacing the previous one which was based on... Cocoon 1.8.3!!

See http://www.freshports.org/textproc/cocoon/
The port includes a GUI to specify which blocks are to be included by 
the build.

Enjoy,
Sylain
--
Sylvain Wallez  Anyware Technologies
http://www.apache.org/~sylvain   http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }

Re: ClassCastException in binding framework.

[Vilya Harvey]

Joerg Heinicke wrote:
On 07.07.2004 18:01, Vilya Harvey wrote:
With the Cocoon 2.1.5 release, the binding framework throws a 
ClassCastException if you use anything other than an  in the 
 part of a repeater binding. Is this intentional 
behaviour, or a bug?

It's a known feature ;-)
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=107906438632484&w=4
Thanks for the pointer Joerg, that does explain things a bit.
It might work for you the same way as I did it here:
http://cvs.apache.org/viewcvs.cgi/cocoon-2.1/src/blocks/forms/samples/forms/form2_bind_xml.xml?annotate=1.4#71. 
I was trying to do something slightly different from that when I came across 
this problem: I wanted an identifier that I could use to distinguish between 
different rows in the form, but I only needed it in the form and not in the 
XML (i.e. direction="load" rather than direction="save"). I was trying to 
use  inside the  element to generate them. The 
workaround I found, in this case, was to get rid of the identity element 
altogether and move the javascript into an  instead.

Thanks for the reponse,
Vil.
--
__
   o|   _. /  \|o._  _  _ ._  _  ._  _ _|_
\/ ||\/(_|| (|/||| |(/_(_)| |(/_o| |(/_ |_
 / \__
http://website.lineone.net/~vilya

Re: cronjob and cocoonpipelinecronjob

[Jeremy Quinn]

Could you show us your configuration?
How have you configured the CocoonPipelineCronJob and it's trigger.
Have you tested the pipeline it calls, independently?
regards Jeremy
On 7 Jul 2004, at 14:57, arnaud DANEELS wrote:
Hi,
 
    I need some help with cocoon-2.2.0-dev with cronjob and  
CocoonPipelineCronJob functionnality

 
    Samples of cron (testcronjob) don’t work in this version of  
cocoon. (he did in the 2.1.5):

  
INFO    (2004-07-07) 15:55.06:024   [cron]  
Unknown-thread/QuartzJobExecutor: Scheduling cron job named 'test'

INFO    (2004-07-07) 15:55.06:039   [cron.test]  
Unknown-thread/TestCronJob: CronJob test launched at Wed Jul 07  
15:55:06 CEST 2004 with message 'I'm here' and sleep timeout of  
23000ms

ERROR   (2004-07-07) 15:55.06:039   [cron]  
Unknown-thread/QuartzJobExecutor: Cron job name 'test died.

org.apache.avalon.framework.CascadingRuntimeException: CronJob test  
raised an exception

    at  
org.apache.cocoon.components.cron.TestCronJob.execute(TestCronJob.java: 
100)

    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native  
Method)

    at  
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.ja 
va:39)

    at  
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccesso 
rImpl.java:25)

    at java.lang.reflect.Method.invoke(Method.java:324)
    at  
org.apache.avalon.excalibur.component.ComponentProxyGenerator$Component 
InvocationHandler.invoke(ComponentProxyGenerator.java:143)

    at $Proxy14.execute(Unknown Source)
    at  
org.apache.cocoon.components.cron.QuartzJobExecutor.execute(QuartzJobEx 
ecutor.java:109)

    at org.quartz.core.JobRunShell.run(JobRunShell.java:188)
    at  
EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(Unknown  
Source)

    at java.lang.Thread.run(Thread.java:534)
Caused by: java.lang.UnsupportedOperationException
    at  
org.apache.cocoon.environment.background.BackgroundEnvironment$NullProc 
essor.getContext(BackgroundEnvironment.java:164)

    at  
org.apache.cocoon.components.source.CocoonSourceResolver.resolveURI(Coc 
oonSourceResolver.java:55)

    at  
org.apache.cocoon.components.source.CocoonSourceResolver.resolveURI(Coc 
oonSourceResolver.java:70)

    at  
org.apache.cocoon.components.cron.TestCronJob.execute(TestCronJob.java: 
83)

    ... 10 more
 
    In the 2.2.0 dev, libraries are updated to 1.4 for quartz.jar and  
1.3.4 for util-current and cocoonpipelinecronjob is

     added to cron block.
 
 
    Have you any idea about this problem  and test this functionnality
 
Thank you for your help.
 
Arnaud

  If email from this address is not signed
IT IS NOT FROM ME
Always check the label, folks !



smime.p7s
Description: S/MIME cryptographic signature

Re: Is there a way to revert to the old "store"?

[Unico Hommes]

Pier Fumagalli wrote:
On 7 Jul 2004, at 23:42, bernhard huber wrote:

Guys, I'm seeing some problems on 2.1.5 and 2.2 which don't happen on
2.1.5-dev.
I am guessing that something is wrong with the new JCS-based store...
Is there a way to revert back without re-implementing the whole 
thing?

running some tests i had following experiences
A   B
100 71ms
200670ms
500   4917ms
1000 28221ms
A .. number of string entries to be cached
B .. measured time in ms
Seems that caching time rises not linear using JCS.

FUDGE! That's exactly what I'm seeing. Under heavy loads, but with no 
variation of URLs, 2.2 is twice as fast as 2.1.5-dev, when the URLs I 
process in Cocoon start varying, then the request time grows 
exponentially.

For us 2.1.5 is unusable, and, ok, VNUNET is not your regular 
moderately loaded, well designed web site (it's actually a miracle it 
stays together :-P ) but this is kinda of a major problem, AFAICS!

For now, just to make sure, I'll put live 2.1.5 with the old cache, 
and give it a go. If that works, then we know we have some problems 
with JCS under load.

Are you sure this is going to work for you though? My own experience 
with the old store is that after a while the cache gets corrupted and 
you start seeing cached content pop up at unexpected places as if the 
cache key all of a sudden is now pointing to a different cached object.

If someone explains how to try out EHCache, I'll be delighted to test 
it out as well.

It's in the scratchpad area. There is an xconf patch file that shows you 
the component configuration. Javadocs should be verbose enough to get 
you going.

EHCache just released 0.9 version. I am looking into upgrading today.
--
Unico

Re: Is there a way to revert to the old store?

[Pier Fumagalli]

On 8 Jul 2004, at 07:35, Carsten Ziegeler wrote:
Pier Fumagalli wrote:
Howto? :-P I had to backport the DefaultPersistentStore and
hack all the way through...
It was definitely not nice not to have the
DefaultPersistentStore java source in the 2.1.5 source
tarball, :-( :-(
In the future, can people be slightly more careful in
removing stuff? I don't care if you switch configurations
from 2.1.4 to 2.1.5, but at least leave the files in there,
given that we are still including JISP as a JAR...
The source is still there; it has just been moved into the deprecated
directory.
You see why I always refer to myself as an idiot? :-P
$ find ../cocoon-2.1.5/src -name DefaultPersistentStore.java
../cocoon-2.1.5/src/deprecated/java/org/apache/cocoon/components/store/ 
impl/DefaultPersistentStore.java
$

Sorry! :-(
Pier


smime.p7s
Description: S/MIME cryptographic signature

Re: Is there a way to revert to the old "store"?

[Pier Fumagalli]

On 7 Jul 2004, at 23:42, bernhard huber wrote:

Guys, I'm seeing some problems on 2.1.5 and 2.2 which don't happen 
on
2.1.5-dev.
I am guessing that something is wrong with the new JCS-based 
store...
Is there a way to revert back without re-implementing the whole 
thing?

running some tests i had following experiences
A   B
100 71ms
200670ms
500   4917ms
1000 28221ms
A .. number of string entries to be cached
B .. measured time in ms
Seems that caching time rises not linear using JCS.
FUDGE! That's exactly what I'm seeing. Under heavy loads, but with no 
variation of URLs, 2.2 is twice as fast as 2.1.5-dev, when the URLs I 
process in Cocoon start varying, then the request time grows 
exponentially.

For us 2.1.5 is unusable, and, ok, VNUNET is not your regular 
moderately loaded, well designed web site (it's actually a miracle it 
stays together :-P ) but this is kinda of a major problem, AFAICS!

For now, just to make sure, I'll put live 2.1.5 with the old cache, and 
give it a go. If that works, then we know we have some problems with 
JCS under load.

If someone explains how to try out EHCache, I'll be delighted to test 
it out as well.

Pier

smime.p7s
Description: S/MIME cryptographic signature

RE: advice

[Carsten Ziegeler]

Dirk-Willem van Gulik wrote:
> 
> On Thu, 8 Jul 2004, Carsten Ziegeler wrote:
> 
> > The only problem I see is that we can't tag 2.1.6 if we do 
> it this way!
> 
> And hense cannot easiily reconstruct what has happened. Just 
> make a branch at 2.1.5 - I am sure there is a tag there; 
> release a 2.1.5a or a 2.1.6, whatever you call it; and done.
> 
Yepp, sure, you're right. Tagging it in CVS is important.

Ok, I would prefer to call it 2.1.5.1. A 2.1.6 would give the
wrong impression as there are actually no new things in it
and no bug fixes.

So, if noone is against 2.1.5.1, I will do it later today.

Carsten

Re: advice

[Andreas Kuckartz]

Dirk-Willem van Gulik wrote:

> what happened on a sunny day in 2004 the day we are in hostile takeover
> talks with the by then virtual monopolist RHSCO.

That will only happen in a few parallel universes.

Andreas

RE: advice

[Dirk-Willem van Gulik]

On Thu, 8 Jul 2004, Carsten Ziegeler wrote:

> The only problem I see is that we can't tag 2.1.6 if we do it this way!

And hense cannot easiily reconstruct what has happened. Just make a branch
at 2.1.5 - I am sure there is a tag there; release a 2.1.5a or a 2.1.6,
whatever you call it; and done.

Dw.

RE: advice

[Carsten Ziegeler]

Great idea! Let's do that.
The only problem I see is that we can't tag 2.1.6 if we do it this way!

Carsten 

> -Original Message-
> From: news [mailto:[EMAIL PROTECTED] On Behalf Of Nicola Ken Barozzi
> Sent: Thursday, July 08, 2004 9:49 AM
> To: [EMAIL PROTECTED]
> Subject: Re: advice
> 
> Pier Fumagalli wrote:
> 
> > I agree with Jim... Although rolling 2.1.6 might be non 
> trivial given 
> > that noone created a new branch/repo for 2.2 and _a_lot_ of changes 
> > (in libraries and related) have been committed since.
> 
> Can't we simply untar the 2.1.5 distro, shove in the two text 
> files, retar it, call it 2.1.6, and release that removing 2.1.5?
> 
> -- 
> Nicola Ken Barozzi   [EMAIL PROTECTED]
>  - verba volant, scripta manent -
> (discussions get forgotten, just code remains)
> -
> 

Re: advice

[Dirk-Willem van Gulik]

In-Reply-To: <[EMAIL PROTECTED]>

Nicola Ken Barozzi wrote:

> Can't we simply untar the 2.1.5 distro, shove in the two text files,
> retar it, call it 2.1.6, and release that removing 2.1.5?

Woa - have some mercy on those which 25 years from now need to figure out
what happened on a sunny day in 2004 the day we are in hostile takeover
talks with the by then virtual monopolist RHSCO. Please try to make sure
that every bit we ship, pack into a distribution tarbal comes out of CVS
and is tagged there. Use 2.1.5a, skip a version, ask 'cvs admin' help -
but do not cheat the system too much.

Dw

Re: advice

[Nicola Ken Barozzi]

Pier Fumagalli wrote:
I agree with Jim... Although rolling 2.1.6 might be non trivial given 
that noone created a new branch/repo for 2.2 and _a_lot_ of changes (in 
libraries and related) have been committed since.
Can't we simply untar the 2.1.5 distro, shove in the two text files, 
retar it, call it 2.1.6, and release that removing 2.1.5?

--
Nicola Ken Barozzi   [EMAIL PROTECTED]
- verba volant, scripta manent -
   (discussions get forgotten, just code remains)
-

Re: CIncludeTransformer issues

[Leszek Gawron]

Torsten Curdt wrote:
I have a patch. It works only with cinclude:include tag. 
caching-include and includexml is way to much complicated for me to 
change it.


Could you please add it to bugzilla?
Could you please apply the patch ?

Done :-)
Thanks
Looks fine. Thank you :)
--
Leszek Gawron  [EMAIL PROTECTED]
Project ManagerMobileBox sp. z o.o.
+48 (61) 855 06 67  http://www.mobilebox.pl
mobile: +48 (501) 720 812   fax: +48 (61) 853 29 65

Re: CIncludeTransformer issues

[Torsten Curdt]

I have a patch. It works only with cinclude:include tag. 
caching-include and includexml is way to much complicated for me to 
change it.

Could you please add it to bugzilla?
Could you please apply the patch ?
Done :-)
Thanks
--
Torsten

DO NOT REPLY [Bug 29935] - [PATCH] CIncludeTransformer include tag supports strip-root attribute

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=29935

[PATCH] CIncludeTransformer include tag supports strip-root attribute

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2004-07-08 07:24 ---
please cross-check

RE: Cocoon JSR 168 Portlet in Cocoon Portal

[Carsten Ziegeler]

Vadim Gritsenko wrote:
> 
> It's actually very easy to reproduce:
> 1. cvs up
> 2. build clean; build
> 3. cocoon servlet
> 4. http://localhost:/samples/blocks/portal/portal
> 5. login
> 6. JSR-168 tab
> 
> Exception is printed neatly within "JSR-168 Cocoon Portlet" 
> content pane.
> 
> Please bear in mind, call stack here is the following:
>   CocoonServlet
>Cocoon (1)
> Treeprocessor, ...
>  CopletSource
>   ManagedCocoonPortlet
>Cocoon (2)
> EnvironmentHelper
> 
> Where, (1) and (2) are the same instance of the Cocoon class, 
> on the same thread. I think that's why it is confused. Here 
> is head of trace.
> 
Ah, ok, than life is much simpler :)
The check currently assumes that on method entry the stack
stored in the thread local is empty. Thus it checks on exit
if the stack is empty again.
We could store the current number of elements in the stack
on method entry and check if the stack has the same size
on exit. This would just be a local int variable.
WDYT?

Carsten