date:20030826

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22707.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22707

Syntax Error in build.bat on Windows ME





--- Additional Comments From [EMAIL PROTECTED]  2003-08-26 04:43 ---
Can you try:
set ANT_OPTS=-Djava.endorsed.dirs=lib\endorsed
and let know if it works? (it's hard to find MS-DOS nowdays)

DO NOT REPLY [Bug 22707] - Syntax Error in build.bat on Windows ME

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22707.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22707

Syntax Error in build.bat on Windows ME





--- Additional Comments From [EMAIL PROTECTED]  2003-08-26 04:46 ---
Tried both single and double quotes and received the same error.

What's the intended result of the line of code?

DO NOT REPLY [Bug 22707] - Syntax Error in build.bat on Windows ME

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22707.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22707

Syntax Error in build.bat on Windows ME





--- Additional Comments From [EMAIL PROTECTED]  2003-08-26 05:35 ---
The intention of this line is to create a system environment variable called
ANT_OPT (ANT OPTions) the purpose of ANT_OPT is define endorsed libs directory
to be used with ANT. See for more info http://ant.apache.org/

Re: [RT] Multiple Continuations?

2003-08-26 Thread Marc Portier



Antonio Gallardo wrote:
Carsten Ziegeler dijo:

I'm currently wondering if it is possible that a user has several
continuations at the same time.
I'm investigating if it's possible to combine our flow with portlets.
Imagine, a portal with several portlets and each portlet running an own
web application. Each application is developed with Cocoon using flow
and is invoked using internal pipeline calls.
So you need a separate continuation to persist the state of
each application.
If the user changes the state of one application, the others are not
affected (and not activated) and not even invoked.
Is this possible?
Hi Carsten!

I think this is posible. The question is if at the current flow
development is this posible. But your proposal is really amazing! I will
be glad to have such behavior in my applications.
Carsten,

same experience here: nothing should prevent you from holding those 
different states over at the server (at least not at the layer of the 
WebContinuations: I haven't waded deep enough into the js implementation 
to understand all usage of the session that could block this)

So if I understand correctly you would have different portions of the 
screen filled in by different widgets that each introduce their own set 
of URI's holding their particular continuation ID?

of course this more ties the portlet to the continuation id then a 
flow-script (or Apple for that matter) which feels odd to me since I 
keep seeing a portlet as a widget/screen (thus view) component and a 
flowscipt as a controller

Hm, I guess this goes along with how you are conceiving Dywel? For all 
we've talked about it I sensed the same tendency to somewhat treat 
controllers and views as being one and the same..

The distinction is probably only in my head, and surely the way web 
encodes everything over one URI + set of request parameters adds 
argumentation to your view...

So while it's not my natural view, I'm quite interested where all of 
this is bringing you, sounds like something could be learned here.

regards,
-marc=


Best Regards,

Antonio Gallardo

RE: cvs commit: cocoon-2.1/src/blocks/html/lib .cvsignore jtidy-04aug2000r7-dev.jar

Steven Noels wrote:
 
 
 First, let's make this clear: it's good that people contribute to the 
 new portal framework. So thanks, Friedrich, Gerald and Gernot, for 
 donating this back to the community. Also, I fully trust Carsten in 
 reviewing the code before committing.
 
 OTOH, I'm still seriously concerned with this happening, especially 
 since I've seen this before. We (= the Cocoon PMC) have the duty to 
 provide legal oversight over the ASF Cocoon codebase. For anything else 
 than bugfixes and minor patches, especially for new code, we must ensure 
 copyright is correctly transferred, and that the ASF cannot be subject 
 of patent infringement lawsuits, and all that. Hence the CLA all 
 committers are supposed to sign and fax.
 
 Of course, I'm very confident that Carsten has done this with the best 
 possible intentions, but Contributions to the portal is hardly an 
 intuitive commit message, and a quick search for the three people 
 involved didn't bring up much prior discussion on the lists. If people 
 show up off-list with anything but trivial contributions, they should be 
 discussed or at the very least mentioned on the dev list before being 
 committed.
 
 I know I'm not making myself popular here and now, but given the 
 increased number of commercial entities involved with Cocoon and its 
 community, we're better safe than sorry.
 
 Sorry again for the tone.
 

No problem.

Now, the usual way of contributing would be submitting a patch into
bugzilla and someone of the committers would look at the patch and
(perhaps) apply it, right?
So, if instead of entering this into bugzilla, the patch is send
directly to a committer looking at the patch and then (perhaps) applying
it, where is the difference?

All files checked in have the appropriate licence, have the correct
author tags etc and I'm really happy that people are contributing to
Cocoon, especially to the Cocoon portal.

Carsten

RE: cvs commit: cocoon-2.1/src/blocks/html/lib .cvsignore jtidy-04aug2000r7-dev.jar

Vadim Gritsenko wrote:
 
 Steven Noels wrote:
 
  Of course, I'm very confident that Carsten has done this with the best 
  possible intentions, but Contributions to the portal is hardly an 
  intuitive commit message, and a quick search for the three people 
  involved didn't bring up much prior discussion on the lists.
 
 
 I also would like to see a bit more descriptive commit message. And may 
 be entry in status.xml too.
 
As long as the portal is alpha this would imho only mess up the status.xml.
As soon as it's not alpha anymore, yes, it makes sense to add everything
to status.xml.

 I noticed that jtidy has been moved out of html block and into 
 lib/optional. What will happen if I to remove jtidy from the 
 lib/optional? Will this break the build?
Yepp, you can see it in the gump.xml dependency description.

Carsten

RE: [BUG] Expired Continuations are not cleaned up?

Bruno Dumon wrote:
 
 SNIP/
 
 one before and one after the ContinuationsInterrupt, and on my system
 (Linux, sun jdk 1.4.2-b28) the messages printed in the execute method
 are displayed every second, like it should. (this works without changing
 the threads-per-processor parameter)
 
Ok, I tested on W2k and Windows XP, sun jdk 1.4.1 and 1.4.2. Perhaps the
os is the difference?

Carsten

cvs commit: cocoon-2.1/src/blocks/authentication-fw/java/org/apache/cocoon/webapps/authentication/components PipelineAuthenticator.java

2003-08-26 Thread cziegeler

cziegeler2003/08/25 23:43:32

  Modified:
src/blocks/authentication-fw/java/org/apache/cocoon/webapps/authentication/components
PipelineAuthenticator.java
  Log:
  Fixing NPE in authentication reported bySonny Sukumar ([EMAIL PROTECTED])
  
  Revision  ChangesPath
  1.3   +3 -1  
cocoon-2.1/src/blocks/authentication-fw/java/org/apache/cocoon/webapps/authentication/components/PipelineAuthenticator.java
  
  Index: PipelineAuthenticator.java
  ===
  RCS file: 
/home/cvs/cocoon-2.1/src/blocks/authentication-fw/java/org/apache/cocoon/webapps/authentication/components/PipelineAuthenticator.java,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- PipelineAuthenticator.java4 Aug 2003 03:06:30 -   1.2
  +++ PipelineAuthenticator.java26 Aug 2003 06:43:32 -  1.3
  @@ -280,6 +280,8 @@
   
   if (doc != null) {
   data = DOMUtil.getFirstNodeFromPath(doc, new String[] 
{authentication,data}, false);
  +} else {
  +doc = DOMUtil.createDocument();
   }
   
   // now create the following xml:

RE: [RT] Starting 2.2

Pier Fumagalli wrote:
 
 On 13/8/03 16:37, Carsten Ziegeler [EMAIL PROTECTED] wrote:
 
  Ok, let's do simple steps perhaps:
  
  Do you think that we should start a new repository? This is
  equivalent to saying we start a new major version (2.2).
  
  (if the answer is yes, we can talk about the layout).
 
 YES! :-) As I have few [RT]s on my own! :-) :-) :-)
 
Great! Combined with the recent RTs, does still someone feel that
starting 2.2 is the right thing? Or a there still objections?

Carsten

RE: [BUG] Expired Continuations are not cleaned up?

2003-08-26 Thread Giacomo Pati

On Tue, 26 Aug 2003, Carsten Ziegeler wrote:

 Bruno Dumon wrote:
 
  SNIP/
 
  one before and one after the ContinuationsInterrupt, and on my system
  (Linux, sun jdk 1.4.2-b28) the messages printed in the execute method
  are displayed every second, like it should. (this works without changing
  the threads-per-processor parameter)
 
 Ok, I tested on W2k and Windows XP, sun jdk 1.4.1 and 1.4.2. Perhaps the
 os is the difference?

No! I've the same system where any additional Commands won't be
triggered (Linux, sun jdk 1.4.2).


 Carsten




--
Giacomo Pati
Otego AG, Switzerland - http://www.otego.com
Orixo, the XML business alliance - http://www.orixo.com

URLs being encoded WITH cookies enabled

2003-08-26 Thread Sonny Sukumar


[Hi guys, I posted this message on the Users list a
few days ago, but nobody seems to know.  I figured I'd
ask the developers. :-) Thanks!]

I'm using the EncodeURLTransformer in all of my
pipelines just before serializing the output, but from
what I read I thought it is only supposed to encode
URLs if cookies are disabled in the browser.

I've confirmed that cookies are enabled for my browser
(Mozilla Firebird v0.6 and IE 5  6), but the URLs
keep getting rewritten with a jsessionid parameter.

What could be wrong? 

__
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com

cvs commit: cocoon-2.1/src/documentation/xdocs/userdocs/concepts views.xml

2003-08-26 Thread asavory

asavory 2003/08/26 01:19:20

  Modified:src/documentation/xdocs/userdocs/concepts views.xml
  Log:
  Cleaning up grammar, fixing spelling
  
  Revision  ChangesPath
  1.2   +15 -15cocoon-2.1/src/documentation/xdocs/userdocs/concepts/views.xml
  
  Index: views.xml
  ===
  RCS file: /home/cvs/cocoon-2.1/src/documentation/xdocs/userdocs/concepts/views.xml,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- views.xml 9 Mar 2003 00:08:18 -   1.1
  +++ views.xml 26 Aug 2003 08:19:20 -  1.2
  @@ -14,7 +14,7 @@
body
 s1 title=The Views
  p
  -Apache Cocoon provides views to resource.
  +Apache Cocoon provides views to a resource.
   Defining a pipeline in a sitemap specifies the different stages
   of processing a resource. 
   A view defines an exit point in the pipeline processing.
  @@ -22,7 +22,7 @@
  p
   Views are yet another sitemap component. 
   Unlike the rest, they are not inherited by sub-sitemaps and
  -they are othogonal to the resource and pipeline definitions. 
  +they are orthogonal to the resource and pipeline definitions. 
   In the following we will not distinguish between resources and pipelines
   because their differences are not relevant here. So, when we talk
   about pipelines the said is valid for resources as well.
  @@ -46,14 +46,14 @@
Apache Cocoon offers a fairly sophisticated URI space mapping mechanism.
Defining pipelines in a sitemap you define this mapping.
It's generally a mistake to map a file system 
  - (or a directory server, or a database repository) one-2-one
  + (or a directory server, or a database repository) one-to-one
with the URI space, since it leads to easily broken links and potential
security issues. 
   /p
   p
Browsers requests resources of this URI space. 
The response of a browser request is normally intended for presenting
  - to a human being. It may be augmented with navigation controls, and 
advertisment.
  + to a human being. It may be augmented with navigation controls, and 
advertisements.
An indexer of a search engines requests resources of this URI space, too.
In contrast to a browser an indexer is interested in the
bare content of a resource.
  @@ -63,7 +63,7 @@

For example, you can now index a document resource, 
requesting the content view of the resource lacking the aggregation 
  - with navigation controls, and advertisments.
  + with navigation controls, and advertisements.

You can now index the text inside a logo, if you are given the SVG content 
that generated the raster image. 
  @@ -75,15 +75,15 @@
   
  s2 title=Defining A View
   p
  - You declare a view in sitemap. The definition of a view
  + You declare a view in the sitemap. The definition of a view
may define further processing steps. You are not allowed to
define a generator step for a view, as the content of a view
  - is xml content of a view's exit point.
  - The most simple view just serialzes the xml content to xml.
  + is the xml content from a view's exit point.
  + The most simple view just serializes the xml content to xml.
   /p
   p
A view element is identified by its name, and its label. You
  - specify the name of a view by the attribute name, and it label either
  + specify the name of a view by the attribute name, and its label either
by the attribute from-label, or by the attribute from-position.
The following list explains the attributes in more detail.
   /p
  @@ -122,7 +122,7 @@
   source![CDATA[
   map:views
map:view name=dublin-core from-label=dublin-core
  - map:transform src=stylesheets/document2dubline-core.xsl/
  + map:transform src=stylesheets/document2dublin-core.xsl/
map:serialize type=xml/
   /map:view]]/source
   
  @@ -141,11 +141,11 @@
  s2 title=Placing Labels
   p
You place labels to define a pipeline exit point.
  - A pipeline exit point may be shared by more than a single.
  + A pipeline exit point may be shared by more than a single view.
   /p
   p
Defining a pipeline exit point you have to add an attribute 
  - label to an sitemap element. Following sitemap elements are label aware:
  + label to a sitemap element. The following sitemap elements are label aware:
   /p
   table
trthSitemap Element/ththDescription/th/tr
  @@ -214,7 +214,7 @@
As described above you have a wide range of choice for placing labels.
You may even place labels to part elements, and to pipelines 
being the source of a labelled part element. The following paragraphs 
  - summarizes the some of the hot features.
  + summarize

Re: [BUG] Expired Continuations are not cleaned up?

2003-08-26 Thread Bruno Dumon

On Mon, 2003-08-25 at 14:24, Michael Melhem wrote:
 On Sun, Aug 24, 2003 at 07:39:58PM +0200, Carsten Ziegeler wrote:
  Hi,
  
  it seems that the CommandManager of the Excalibur Event package
  is not working as expected. If you add a command to the sink
  of the CommandManager it's never executed.
  Unfortunately, this code is used in the ContinuationsManager
  for testing against expired continuations. But the
  execute() method of ContinuationInterrupt is never invoked!
  
  So, it seems that there is a bug somewhere in the event package
  and our manager is not working properly.
  
  Why is the CommandManager instantiated in Cocoon.java, put
  into the Context and get out of it in contextualize in the
  ContinuationManagerImpl? The CommandManager is only used
  there. IMHO it would be much cleaner to either move the
  initialization to the ContinuationManagerImpl or to make
  a real component out of it. Passing components in the context
  seems to be a hack, no?
  
  I think, a simple solution would be to switch to the cornerstone
  scheduler component. This component works (see the scheduler sample
  in the scratchpad) and removing the CommandManager usage should also 
  fix the shut-down problems with Tomcat entered as a bug that annoyes 
  many users.
  But if someone is able to fix both problems in the event
  package I'm fine with that as well of course.
   
   IIRC, the cornerstone scheduler was the orginal scheduler
   used to expire continuations. I would need to delve into
   the mail archives to retreive the reason that it was changed.

I just did, see here:

http://marc.theaimsgroup.com/?l=xml-cocoon-devw=2r=1s=remove+need+for+cornerstone+jarsq=b

more specifically:

http://marc.theaimsgroup.com/?l=xml-cocoon-devm=104628525923843w=2

-- 
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java  XML Competence Support Center
[EMAIL PROTECTED]  [EMAIL PROTECTED]

cvs commit: cocoon-2.1/src/java/org/apache/cocoon/components/flow WebContinuation.java ContinuationsManagerImpl.java ContinuationsManager.java

mpo 2003/08/26 02:05:15

  Modified:src/java/org/apache/cocoon/components/flow
WebContinuation.java ContinuationsManagerImpl.java
ContinuationsManager.java
  Log:
  Adaption to use of new ContinuationsDisposer.
  
  PR:
  Obtained from:
  Submitted by: 
  Reviewed by:  
  CVS: --
  CVS: PR:
  CVS:   If this change addresses a PR in the problem report tracking
  CVS:   database, then enter the PR number(s) here.
  CVS: Obtained from:
  CVS:   If this change has been taken from another system, such as NCSA,
  CVS:   then name the system in this line, otherwise delete it.
  CVS: Submitted by:
  CVS:   If this code has been contributed to Apache by someone else; i.e.,
  CVS:   they sent us a patch or a new module, then include their name/email
  CVS:   address here. If this is your work then delete this line.
  CVS: Reviewed by:
  CVS:   If we are doing pre-commit code reviews and someone else has
  CVS:   reviewed your changes, include their name(s) here.
  CVS:   If you have not had it reviewed then delete this line.
  
  Revision  ChangesPath
  1.5   +24 -2 
cocoon-2.1/src/java/org/apache/cocoon/components/flow/WebContinuation.java
  
  Index: WebContinuation.java
  ===
  RCS file: 
/home/cvs/cocoon-2.1/src/java/org/apache/cocoon/components/flow/WebContinuation.java,v
  retrieving revision 1.4
  retrieving revision 1.5
  diff -u -r1.4 -r1.5
  --- WebContinuation.java  20 Mar 2003 02:46:32 -  1.4
  +++ WebContinuation.java  26 Aug 2003 09:05:15 -  1.5
  @@ -119,6 +119,13 @@
* is bigger than codelastAccessTime + timeToLive/code.
*/
   protected int timeToLive;
  +
  +/**
  + * Holds the codeContinuationsDisposer/code to call when this continuation
  + * gets invalidated.
  + */
  +protected ContinuationsDisposer disposer;
  +
   
   /**
* Create a codeWebContinuation/code object. Saves the object in
  @@ -129,16 +136,20 @@
* @param continuation an codeObject/code value
* @param parentContinuation a codeWebContinuation/code value
* @param timeToLive time this continuation should live
  + * @param disposer a codeContinuationsDisposer/code to call when this
  + * continuation gets invalidated.
*/
   WebContinuation(String id,
   Object continuation,
   WebContinuation parentContinuation,
  -int timeToLive) {
  +int timeToLive, 
  +ContinuationsDisposer disposer) {
   this.id = id;
   this.continuation = continuation;
   this.parentContinuation = parentContinuation;
   this.updateLastAccessTime();
   this.timeToLive = timeToLive;
  +this.disposer = disposer;
   
   if (parentContinuation != null) {
   this.parentContinuation.children.add(this);
  @@ -243,6 +254,17 @@
*/
   public Object getUserObject() {
   return userObject;
  +}
  +
  +/**
  + * Obtains the codeContinuationsDisposer/code to call when this continuation
  + * is invalidated.
  + * 
  + * @return a codeContinuationsDisposer/code instance or null if there are
  + * no specific clean-up actions required. 
  + */
  +ContinuationsDisposer getDisposer() {
  +return this.disposer;
   }
   
   /**
  
  
  
  1.7   +18 -5 
cocoon-2.1/src/java/org/apache/cocoon/components/flow/ContinuationsManagerImpl.java
  
  Index: ContinuationsManagerImpl.java
  ===
  RCS file: 
/home/cvs/cocoon-2.1/src/java/org/apache/cocoon/components/flow/ContinuationsManagerImpl.java,v
  retrieving revision 1.6
  retrieving revision 1.7
  diff -u -r1.6 -r1.7
  --- ContinuationsManagerImpl.java 19 Jun 2003 07:27:47 -  1.6
  +++ ContinuationsManagerImpl.java 26 Aug 2003 09:05:15 -  1.7
  @@ -143,10 +143,11 @@
   
   public WebContinuation createWebContinuation(Object kont,
WebContinuation parent,
  - int timeToLive) {
  + int timeToLive, 
  + ContinuationsDisposer disposer) {
   int ttl = (timeToLive == 0 ? defaultTimeToLive : timeToLive);
   
  -WebContinuation wk = generateContinuation(kont, parent, ttl);
  +WebContinuation wk = generateContinuation(kont, parent, ttl, disposer);
   wk.enableLogging(getLogger());
   
   if (parent == null) {
  @@ -198,6 +199,12 @@
   for (int i = 0; i  size; i++) {
   _invalidate((WebContinuation) children.get(i));
   }
  +

cvs commit: cocoon-2.1/src/blocks/apples/java/org/apache/cocoon/components/flow/apples ApplesProcessor.java

mpo 2003/08/26 02:06:44

  Modified:src/blocks/apples/java/org/apache/cocoon/components/flow/apples
ApplesProcessor.java
  Log:
  Making sure Apples that are Disposable will get their dispose event called upon 
invalidation of their wrapping WebContinuation.
  
  
  PR:
  Obtained from:
  Submitted by: 
  Reviewed by:  
  CVS: --
  CVS: PR:
  CVS:   If this change addresses a PR in the problem report tracking
  CVS:   database, then enter the PR number(s) here.
  CVS: Obtained from:
  CVS:   If this change has been taken from another system, such as NCSA,
  CVS:   then name the system in this line, otherwise delete it.
  CVS: Submitted by:
  CVS:   If this code has been contributed to Apache by someone else; i.e.,
  CVS:   they sent us a patch or a new module, then include their name/email
  CVS:   address here. If this is your work then delete this line.
  CVS: Reviewed by:
  CVS:   If we are doing pre-commit code reviews and someone else has
  CVS:   reviewed your changes, include their name(s) here.
  CVS:   If you have not had it reviewed then delete this line.
  
  Revision  ChangesPath
  1.4   +17 -2 
cocoon-2.1/src/blocks/apples/java/org/apache/cocoon/components/flow/apples/ApplesProcessor.java
  
  Index: ApplesProcessor.java
  ===
  RCS file: 
/home/cvs/cocoon-2.1/src/blocks/apples/java/org/apache/cocoon/components/flow/apples/ApplesProcessor.java,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- ApplesProcessor.java  6 Aug 2003 15:54:13 -   1.3
  +++ ApplesProcessor.java  26 Aug 2003 09:06:43 -  1.4
  @@ -50,9 +50,11 @@
   import org.apache.avalon.framework.service.ServiceException;
   import org.apache.avalon.framework.service.ServiceManager;
   import org.apache.avalon.framework.service.Serviceable;
  +import org.apache.avalon.framework.activity.Disposable;
   import org.apache.avalon.framework.context.DefaultContext;
   import org.apache.cocoon.components.LifecycleHelper;
   import org.apache.cocoon.components.flow.AbstractInterpreter;
  +import org.apache.cocoon.components.flow.ContinuationsDisposer;
   import org.apache.cocoon.components.flow.InvalidContinuationException;
   import org.apache.cocoon.components.flow.WebContinuation;
   import org.apache.cocoon.environment.Environment;
  @@ -63,7 +65,7 @@
* ApplesProcessor is the core Cocoon component that provides the 'Apples' 
* flow implementation. 
*/
  -public class ApplesProcessor extends AbstractInterpreter implements Serviceable {
  +public class ApplesProcessor extends AbstractInterpreter implements Serviceable, 
ContinuationsDisposer {
   
   //TODO make this a configuration setting
   public static final int TIMETOLIVE = 1800; // 30 minutes
  @@ -80,11 +82,13 @@
   
   AppleController app = instantiateController(className);
   
  -WebContinuation wk = this.continuationsMgr.createWebContinuation(app, null, 
TIMETOLIVE);
  +WebContinuation wk = this.continuationsMgr.createWebContinuation(app, null, 
TIMETOLIVE, this);
   
   getLogger().debug(Pulling fresh apple through the lifecycle...);
   DefaultContext appleContext = new DefaultContext();
   appleContext.put(continuation-id, wk.getId());
  +
  +//TODO: also add the componentManager for Apples that took the other 
approach
   LifecycleHelper.setupComponent(app, getLogger(), appleContext, 
this.serviceManager, null, null, null);
   
   processApple(params, env, app, wk);
  @@ -156,8 +160,19 @@
   }
   
   
  +public void disposeContinuation(WebContinuation webContinuation) {
  +AppleController app =
  +(AppleController) webContinuation.getContinuation();
  +if (app instanceof Disposable) {
  +((Disposable)app).dispose();
  +}
  +
  +}
  +
  +
   public void service(ServiceManager serviceManager) throws ServiceException {
   this.serviceManager = serviceManager;
   }
  +
   
   }

cvs commit: cocoon-2.1/src/java/org/apache/cocoon/components/flow/javascript/fom FOM_Cocoon.java

mpo 2003/08/26 02:05:52

  Modified:src/java/org/apache/cocoon/components/flow/javascript
JSWebContinuation.java
   src/java/org/apache/cocoon/components/flow/javascript/fom
FOM_Cocoon.java
  Log:
  Setting ContinuationsDisposer to null for those implementattions that do not need it.
  
  PR:
  Obtained from:
  Submitted by: 
  Reviewed by:  
  CVS: --
  CVS: PR:
  CVS:   If this change addresses a PR in the problem report tracking
  CVS:   database, then enter the PR number(s) here.
  CVS: Obtained from:
  CVS:   If this change has been taken from another system, such as NCSA,
  CVS:   then name the system in this line, otherwise delete it.
  CVS: Submitted by:
  CVS:   If this code has been contributed to Apache by someone else; i.e.,
  CVS:   they sent us a patch or a new module, then include their name/email
  CVS:   address here. If this is your work then delete this line.
  CVS: Reviewed by:
  CVS:   If we are doing pre-commit code reviews and someone else has
  CVS:   reviewed your changes, include their name(s) here.
  CVS:   If you have not had it reviewed then delete this line.
  
  Revision  ChangesPath
  1.3   +2 -2  
cocoon-2.1/src/java/org/apache/cocoon/components/flow/javascript/JSWebContinuation.java
  
  Index: JSWebContinuation.java
  ===
  RCS file: 
/home/cvs/cocoon-2.1/src/java/org/apache/cocoon/components/flow/javascript/JSWebContinuation.java,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- JSWebContinuation.java16 Mar 2003 17:49:12 -  1.2
  +++ JSWebContinuation.java26 Aug 2003 09:05:52 -  1.3
  @@ -107,7 +107,7 @@
   
   JSWebContinuation jswk = new JSWebContinuation();
   WebContinuation wk
  -  = contMgr.createWebContinuation(kont, pwk, ttl);
  +  = contMgr.createWebContinuation(kont, pwk, ttl, null);
   wk.setUserObject(jswk);
   
   jswk.cocoon = cocoon;
  
  
  
  1.10  +5 -3  
cocoon-2.1/src/java/org/apache/cocoon/components/flow/javascript/fom/FOM_Cocoon.java
  
  Index: FOM_Cocoon.java
  ===
  RCS file: 
/home/cvs/cocoon-2.1/src/java/org/apache/cocoon/components/flow/javascript/fom/FOM_Cocoon.java,v
  retrieving revision 1.9
  retrieving revision 1.10
  diff -u -r1.9 -r1.10
  --- FOM_Cocoon.java   6 Aug 2003 15:54:13 -   1.9
  +++ FOM_Cocoon.java   26 Aug 2003 09:05:52 -  1.10
  @@ -153,7 +153,8 @@
   wk = lastContinuation = 
   contMgr.createWebContinuation(continuation,
 lastContinuation,
  -  0);
  +  0,
  +  null);
   }
   
   String redUri = uri;
  @@ -964,7 +965,8 @@
   componentManager.lookup(ContinuationsManager.ROLE);
   wk = contMgr.createWebContinuation(unwrap(k),
  (WebContinuation)(parent == null ? null 
: parent.getWebContinuation()),
  -   timeToLive);
  +   timeToLive,
  +   null);
   FOM_WebContinuation result = new FOM_WebContinuation(wk);
   result.setParentScope(getParentScope());
   result.setPrototype(getClassPrototype(getParentScope(),

Re: lastModificationDate misuse? - old thread - progress

2003-08-26 Thread John Williams

Joerg Heinicke wrote
 Bug was fixed some days ago:
 http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14348. Carsten
 requested for testers of the patch, so if you can test the behaviour
 with the current Cocoon 2.0 CVS it will be good.
  If XSP is the result of a pipeline then the ServerPages Generator can't
  work out its currency and randomly re-generates and compiles. To make
  I have inspected the code of 2.0.4 and it is still there, ie code is
  same as when reported in 2001. Surely a typical use of cocoon is to
  build XSP using XSLT?

I have tested (with cocoon-2.0_20030812221701) and believe the problem has
only been partially solved. Instead of the prior situation where the .java 
.class were re-generated from XSP on a random basis - they now are always
regenerated. This is at least consistent - but very wasteful on resources 
latency in requests.

I have investigated the source and found that the test as to whether or not
regeneration takes place is:
   !currValidity.equals(prevValidity)

Inspecting the contents of the currValidity and prevValidity Maps I find
that they are equivalent excepting that the prevValidity contains an entry
S-xml-1_=NOP Validity so the test fails and code is re-generated. However,
it appears that the NOP Validity is simply indicating an always valid
condition - so code should not be re-generated.

I have added some code to strip the NOPCacheValidity entries and do a
comparison and my problem is solved - ie code is only regenerated when the
cached objects are out-of-date.

I have pasted the diff of my patch at the end of this message. I think the
bug http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14348 should be
re-opened. Your views Joerg , Carsten?

John Williams


Suggested patch to SiteMapSource.java:
@@ -56,12 +56,15 @@
import java.io.InputStream;
import java.net.MalformedURLException;
import java.util.Map;
+import java.util.HashMap;
+import java.util.Iterator;

import org.apache.avalon.framework.component.ComponentException;
import org.apache.avalon.framework.component.ComponentManager;
import org.apache.cocoon.ProcessingException;
import org.apache.cocoon.Processor;
import org.apache.cocoon.caching.PipelineCacheKey;
+import org.apache.cocoon.caching.NOPCacheValidity;
import org.apache.cocoon.components.CocoonComponentManager;
import org.apache.cocoon.components.EnvironmentStack;
import org.apache.cocoon.components.pipeline.CacheableEventPipeline;
@@ -322,7 +325,7 @@

Map currValidity = cep.generateValidity(this.environment);

- if (prevValidity == null || !currValidity.equals(prevValidity)) {
+ if (prevValidity == null || !equalsIgnoreNOPCacheValidities(currValidity,
prevValidity)) {
// validity changed, update cached validity, timestamp and last modified
this.lastModificationDate = System.currentTimeMillis();
obj = new Object[] {new Long (this.lastModificationDate), currValidity};
@@ -365,6 +368,29 @@
this.needsRefresh = false;
}

+ static boolean equalsIgnoreNOPCacheValidities (Map aMapWithNOPValidities,
Map anotherMapWithNOPValidities) {
+ return
stripNOPValidities(aMapWithNOPValidities).toString().equals(stripNOPValiditi
es(anotherMapWithNOPValidities).toString());
+ }
+
+
+ static Map stripNOPValidities(Map withNOPValidities) {
+ if (withNOPValidities == null) return null;
+ else {
+ if (withNOPValidities.containsValue(NOPCacheValidity.CACHE_VALIDITY)) {
+ Map retVal = new HashMap();
+ Iterator iter = withNOPValidities.entrySet().iterator();
+ for (; iter.hasNext(); ) {
+ Map.Entry entry = (Map.Entry)iter.next();
+ if (!entry.getValue().equals(NOPCacheValidity.CACHE_VALIDITY))
+ retVal.put(entry.getKey(), entry.getValue());
+ }
+ return retVal;
+ }
+ else return withNOPValidities;
+ }
+ }
+
+
/**
* Return a new codeInputSource/code object
*/

RE: [BUG] Expired Continuations are not cleaned up?

Bruno Dumon wrote:
  IIRC, the cornerstone scheduler was the orginal scheduler
  used to expire continuations. I would need to delve into
  the mail archives to retreive the reason that it was changed.
 
 I just did, see here:
 
 http://marc.theaimsgroup.com/?l=xml-cocoon-devw=2r=1s=remove+ne
 ed+for+cornerstone+jarsq=b

 more specifically:

 http://marc.theaimsgroup.com/?l=xml-cocoon-devm=104628525923843w=2

The cornerstone scheduler is released as an rc and is (again) in the
scratchpad/lib directory. It has a dependency to excalibur-thread
and cornerstone-threads. Now 5 (!) jars are required as one jar
contains the api and one the impl (for scheduler and threads).

Carsten

SourcepropWritingTransformer

2003-08-26 Thread Gianugo Rabellino

I'm about to tackle WebDAV properties handling, and I was happy to find 
that Guido has already provided something. :-)

I am however a bit uncomfortable with the current implementation and I 
wanted to see if it's just me not having the correct approach.

A source property (both in webdav sense and in the  SourceProperty 
implementation) is made of three part: a local name (String), a 
namespace (String) and a value (DOM Element). It's worth noticing that 
the property value is actually the *holder element* plus it's value 
(that is a text node - in case of a string value - or other Elements), 
so that effectively you get, in case of webdav,

getcontenttype xmlns=DAV:text/xml/getcontenttype

a property name of getcontenttype, a namespace of DAV: and a value of 
(xml-ized)
getcontenttype xmlns=DAV:text/xml/getcontenttype. User space tools 
will then give you a value of text/xml, but this is a different issue.

All this said, I fail to understand why this transformer is somehow 
reinveinting XML by using this syntax:

source:prop name=author namespace=metame/source:prop

which forces, besides, to use a very risky solution to rebuild the property:

  String pre = +name+ xmlns=+quote+namespace+quote+;
  String post = /+name+;
  String xml = pre+value+post;
  StringReader reader = new StringReader(xml);
  Document doc = parser.parseDocument(new InputSource(reader));
  SourceProperty property = new SourceProperty(doc.getDocumentElement());
  ((InspectableSource)source).setSourceProperty(property);
One of my biggest no-no is not to use string manipulation to build XML: 
this algo would fail in case the element has any XML reserver characters 
or is an XML property value with nested elements.

What about using good 'ole XML instead? I'm considering something like:

  source:props
 myns:author xmlns:myns=metame/myns:author
  /source:props
This would allow using standard Transformer tools (startRecording() 
instead than startTextRecording()) to set the properties later. It would 
be much safer and a good bit more XMLish (and WebDAVish too). Also, this 
modification could be inserted directly into the 
SourceWritingTransformer without requiring a new transformer just to set 
properties.

How does it sound? Am I overlooking something?

--
Gianugo Rabellino
Pro-netics s.r.l. -  http://www.pro-netics.com
Orixo, the XML business alliance - http://www.orixo.com
(Now blogging at: http://blogs.cocoondev.org/gianugo/)

Re: cvs commit: cocoon-2.1/src/blocks/html/lib .cvsignore jtidy-04aug2000r7-dev.jar

2003-08-26 Thread Vadim Gritsenko

Carsten Ziegeler wrote:

Vadim Gritsenko wrote:
 

Steven Noels wrote:

   

Of course, I'm very confident that Carsten has done this with the best 
possible intentions, but Contributions to the portal is hardly an 
intuitive commit message, and a quick search for the three people 
involved didn't bring up much prior discussion on the lists.
 

I also would like to see a bit more descriptive commit message. And may 
be entry in status.xml too.

   

As long as the portal is alpha this would imho only mess up the status.xml.
As soon as it's not alpha anymore, yes, it makes sense to add everything
to status.xml.
Then you will have to provide a blurb about portal in status.xml 
*before* next milestone/beta/rc/release, because portal was released 
once as part of 2.1 and users deserve to know what has been changed from 
2.1 to insert version number here - most probably 2.1.1.


I noticed that jtidy has been moved out of html block and into 
lib/optional. What will happen if I to remove jtidy from the 
lib/optional? Will this break the build?
   

Yepp, you can see it in the gump.xml dependency description.

But that means that we are busting build even more instead of fixing it?

Vadim

RE: cvs commit: cocoon-2.1/src/blocks/html/lib .cvsignore jtidy-04aug2000r7-dev.jar

Vadim Gritsenko wrote:
 
 I noticed that jtidy has been moved out of html block and into 
 lib/optional. What will happen if I to remove jtidy from the 
 lib/optional? Will this break the build?
 
 
 Yepp, you can see it in the gump.xml dependency description.
 
 
 But that means that we are busting build even more instead of fixing it?
 
Vadim, this is a point a stressed several times in the last months, but
noone was really interested. Yes, we have a problem with libs, e.g. we
have the same lib (velocity) at different places!

We are not busting the build. Currently, if two blocks require the same
lib, it has to be in lib/optional. When the blocks directory structure 
was built, someone moved the libs into the blocks directories making it
impossible to use the same jar in several projects. Now, each time
a second block needs the jar we have to move it :(
As I pointed out several times, this can be solved with an updated build
system where we have all jars in lib/optional. These jars are not copied
automatically to WEB-INF/lib. They are only copied if a included block
depends on them.

Carsten

Re: cvs commit: cocoon-2.1/src/blocks/html/lib .cvsignore jtidy-04aug2000r7-dev.jar

2003-08-26 Thread Vadim Gritsenko

Carsten Ziegeler wrote:

Vadim Gritsenko wrote:
 

I noticed that jtidy has been moved out of html block and into 
lib/optional. What will happen if I to remove jtidy from the 
lib/optional? Will this break the build?
  

   

Yepp, you can see it in the gump.xml dependency description.

 

But that means that we are busting build even more instead of fixing it?

...

As I pointed out several times, this can be solved with an updated build
system where we have all jars in lib/optional. These jars are not copied
automatically to WEB-INF/lib. They are only copied if a included block
depends on them.
Will it be a problem with real blocks if all the jars are in the 
WEB-INF? AFAIU, real blocks will have a per-block classloader, so libs 
will go into the BLOCK-INF/lib, and won't be seen outside of the block. 
How we will solve this issue with real blocks then?

Vadim

Re: cvs commit: cocoon-2.1/src/blocks/html/lib .cvsignore jtidy-04aug2000r7-dev.jar

2003-08-26 Thread Roger I Martin PhD

Hi Carsten,

Just a thought about something I've run into.  When a third party makes a
block or webapp that depends on the same lib but a different version, can
the jar indexing capability of jdk1.4 jar utility be employed to resolve the
issues?  It involves placing and maintaining a correct Class-Path: ... in
the jar's manifest and then running jar -i *.jar.
http://java.sun.com/j2se/1.4.2/docs/tooldocs/windows/jar.html#i

Also does anyone know if the indexing really does or would affect the speed
of bringing up a wepapp and say Tomcat?

Roger
- Original Message - 
From: Carsten Ziegeler [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Tuesday, August 26, 2003 8:10 AM
Subject: RE: cvs commit: cocoon-2.1/src/blocks/html/lib .cvsignore
jtidy-04aug2000r7-dev.jar


 Vadim Gritsenko wrote:
 
  I noticed that jtidy has been moved out of html block and into
  lib/optional. What will happen if I to remove jtidy from the
  lib/optional? Will this break the build?
  
  
  Yepp, you can see it in the gump.xml dependency description.
  
 
  But that means that we are busting build even more instead of fixing it?
 
 Vadim, this is a point a stressed several times in the last months, but
 noone was really interested. Yes, we have a problem with libs, e.g. we
 have the same lib (velocity) at different places!

 We are not busting the build. Currently, if two blocks require the same
 lib, it has to be in lib/optional. When the blocks directory structure
 was built, someone moved the libs into the blocks directories making it
 impossible to use the same jar in several projects. Now, each time
 a second block needs the jar we have to move it :(
 As I pointed out several times, this can be solved with an updated build
 system where we have all jars in lib/optional. These jars are not copied
 automatically to WEB-INF/lib. They are only copied if a included block
 depends on them.

 Carsten

Re: SourcepropWritingTransformer

2003-08-26 Thread Guido Casper

Gianugo Rabellino wrote:
 I'm about to tackle WebDAV properties handling, and I was happy to
 find that Guido has already provided something. :-)

 I am however a bit uncomfortable with the current implementation and
I
 wanted to see if it's just me not having the correct approach.

I'm uncomfortable with the current approach as well (it's work in
progress :-). That is primarily due to the current design and
implementation of (the seemingly unfinished) SourceProperty class.
Changing this was next on my list (as was discussing
SourcepropsWritingTransformer's input XML :-).

I'm however cautious about breaking SourceDescriptionGenerator, more
so that I found that the slide block isn't marked unstable (Is it too
late to change this?).


 A source property (both in webdav sense and in the  SourceProperty
 implementation) is made of three part: a local name (String), a
 namespace (String) and a value (DOM Element). It's worth noticing
that
 the property value is actually the *holder element* plus it's value
 (that is a text node - in case of a string value - or other
Elements),
 so that effectively you get, in case of webdav,

 getcontenttype xmlns=DAV:text/xml/getcontenttype

 a property name of getcontenttype, a namespace of DAV: and a
value
 of (xml-ized)
 getcontenttype xmlns=DAV:text/xml/getcontenttype. User space
 tools will then give you a value of text/xml, but this is a
 different issue.

 All this said, I fail to understand why this transformer is somehow
 reinveinting XML by using this syntax:

 source:prop name=author namespace=metame/source:prop

I felt like seperating the property namespace from the XML namespaces
was a good idea, since it would be an easy way to deal with
InspectableSource implementations that don't deal with namespaced
properties. On a second thought an alternative would be to have only
one source:prop element and have all immediate children be the
properties.

A value of a property however doesn't necessarily has to be XML.
Especially if you think of other Sources besides WebDAVSource.


 which forces, besides, to use a very risky solution to rebuild the
 property:

String pre = +name+ xmlns=+quote+namespace+quote+;
String post = /+name+;
String xml = pre+value+post;
StringReader reader = new StringReader(xml);
Document doc = parser.parseDocument(new InputSource(reader));
SourceProperty property = new
SourceProperty(doc.getDocumentElement());
 ((InspectableSource)source).setSourceProperty(property);

 One of my biggest no-no is not to use string manipulation to build
 XML: this algo would fail in case the element has any XML reserver
 characters

Yes, I know. See above.
However I would prefer to defer the XML handling of property _values_
to the WebDAVSource and have the SourceProperty class be neutral to
XML.

 or is an XML property value with nested elements.

 What about using good 'ole XML instead? I'm considering something
 like:

source:props
   myns:author xmlns:myns=metame/myns:author
/source:props

 This would allow using standard Transformer tools (startRecording()
 instead than startTextRecording()) to set the properties later. It
 would
 be much safer and a good bit more XMLish (and WebDAVish too). Also,
 this modification could be inserted directly into the
 SourceWritingTransformer without requiring a new transformer just to
 set properties.

It feels a bit like mixing concerns to me (setting properties and
writing content).
Currently the only requirement SourceWritingTransformer has is the
Source to be modifiable. You would need to have a look at SWT's input
XML to know which pseudo protcols can be used with it.

Guido

cvs commit: cocoon-2.1/src/blocks/woody/java/org/apache/cocoon/woody/binding RepeaterJXPathBindingBuilder.java RepeaterJXPathBinding.java

mpo 2003/08/26 06:10:12

  Modified:src/blocks/woody/java/org/apache/cocoon/woody/binding
RepeaterJXPathBindingBuilder.java
RepeaterJXPathBinding.java
  Log:
  Making sure the RepeaterBinding can be used without on-insert-row and 
on-delete-row
  
  Revision  ChangesPath
  1.4   +13 -6 
cocoon-2.1/src/blocks/woody/java/org/apache/cocoon/woody/binding/RepeaterJXPathBindingBuilder.java
  
  Index: RepeaterJXPathBindingBuilder.java
  ===
  RCS file: 
/home/cvs/cocoon-2.1/src/blocks/woody/java/org/apache/cocoon/woody/binding/RepeaterJXPathBindingBuilder.java,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- RepeaterJXPathBindingBuilder.java 30 Jul 2003 15:17:43 -  1.3
  +++ RepeaterJXPathBindingBuilder.java 26 Aug 2003 13:10:12 -  1.4
  @@ -111,24 +111,31 @@
   bindingElm,
   BindingManager.NAMESPACE,
   on-bind);
  -JXPathBindingBase[] childBindings =
  -assistant.makeChildBindings(childWrapElement);
  +
  +if (childWrapElement == null) throw new 
BindingException(RepeaterBinding misses 'on-bind' child definition.  + 
DomHelper.getLocation(bindingElm));
  +
  +JXPathBindingBase[] childBindings = 
assistant.makeChildBindings(childWrapElement);
   
   Element deleteWrapElement =
   DomHelper.getChildElement(
   bindingElm,
   BindingManager.NAMESPACE,
   on-delete-row);
  -JXPathBindingBase[] deleteBindings =
  -assistant.makeChildBindings(deleteWrapElement);
  +JXPathBindingBase[] deleteBindings = null;
  +if(deleteWrapElement != null) {
  +deleteBindings = assistant.makeChildBindings(deleteWrapElement);
  +}
   
   Element insertWrapElement =
   DomHelper.getChildElement(
   bindingElm,
   BindingManager.NAMESPACE,
   on-insert-row);
  -JXPathBindingBase insertBinding =
  -assistant.makeChildBindings(insertWrapElement)[0];
  +JXPathBindingBase insertBinding = null;
  +if (insertWrapElement != null) {
  +insertBinding = assistant.makeChildBindings(insertWrapElement)[0];
  +
  +}
   
   RepeaterJXPathBinding repeaterBinding =
   new RepeaterJXPathBinding(
  
  
  
  1.4   +34 -17
cocoon-2.1/src/blocks/woody/java/org/apache/cocoon/woody/binding/RepeaterJXPathBinding.java
  
  Index: RepeaterJXPathBinding.java
  ===
  RCS file: 
/home/cvs/cocoon-2.1/src/blocks/woody/java/org/apache/cocoon/woody/binding/RepeaterJXPathBinding.java,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- RepeaterJXPathBinding.java12 Aug 2003 12:56:32 -  1.3
  +++ RepeaterJXPathBinding.java26 Aug 2003 13:10:12 -  1.4
  @@ -192,7 +192,12 @@
   
   // check if matchPath was in list of updates, if not -- bind for delete
   if (!updatedRowIds.contains(matchId)) {
  -this.deleteRowBinding.saveFormToModel(frmModel, rowContext);
  +if (this.deleteRowBinding != null) {
  +this.deleteRowBinding.saveFormToModel(frmModel, rowContext);

  +} else {
  +getLogger().warn(RepeaterBinding has detected rows to delete, 
 +
  +but misses the on-delete-row binding to do it.);
  +}
   }
   }
   
  @@ -205,21 +210,29 @@
   }
   
   // end with rows to insert (to make sure they don't get deleted!)
  -Iterator rowIterator = rowsToInsert.iterator();
  -//register the factory!
  -this.insertRowBinding.saveFormToModel(repeater, repeaterContext);
  -while (rowIterator.hasNext()) {
  -Repeater.RepeaterRow thisRow = (Repeater.RepeaterRow) 
rowIterator.next();
  -// --  create the path to let the context be created
  -Pointer newRowContextPointer = repeaterContext.createPath(this.rowPath 
+ [ + indexCount + ]);
  -JXPathContext newRowContext = 
repeaterContext.getRelativeContext(newRowContextPointer);
  -if (getLogger().isDebugEnabled())
  -getLogger().debug(inserted row at  + 
newRowContextPointer.asPath());
  -//+ rebind to children for update
  -this.rowBinding.saveFormToModel(thisRow, newRowContext);
  -getLogger().debug(bound new row);
  -indexCount++;
  +if(rowsToInsert.size()  0) {
  +

Re: cvs commit: cocoon-2.1/src/blocks/html/lib .cvsignore jtidy-04aug2000r7-dev.jar

2003-08-26 Thread Nicola Ken Barozzi

Vadim Gritsenko wrote, On 26/08/2003 14.01:

Carsten Ziegeler wrote:

Vadim Gritsenko wrote:
...
I also would like to see a bit more descriptive commit message. And 
may be entry in status.xml too.
As long as the portal is alpha this would imho only mess up the 
status.xml.
As soon as it's not alpha anymore, yes, it makes sense to add everything
to status.xml.
Then you will have to provide a blurb about portal in status.xml 
*before* next milestone/beta/rc/release, because portal was released 
once as part of 2.1 and users deserve to know what has been changed from 
2.1 to insert version number here - most probably 2.1.1.
As I had outlined before, making blocks live in the same space makes it 
impossible to really see the difference from scratchpad ones and real 
ones, generating these issues.

Since blocks are not scratchpad anymore, and there is no hard 
distinction, I want to see the entry in status.xml now too.

I noticed that jtidy has been moved out of html block and into 
lib/optional. What will happen if I to remove jtidy from the 
lib/optional? Will this break the build?
Yepp, you can see it in the gump.xml dependency description.
But that means that we are busting build even more instead of fixing it?
The only real way in which it can be fixed is to do away with including 
libs in CVS, and instead getting them from the web and in a local 
repository.

I can set up such a system quite quickly if we decide to use it, using 
Krysalis Ruper (that does exactly this).

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

transformer developer

2003-08-26 Thread arnaud daneels








hello,

 i can't find how to develop 
transformer with this method:
- 
i would like to begin to analyse SAX events from the input 
pipeline
 
- without terminate this analyse i would like to put in the output 
pipelinenew events
 
- i don't want to use DOM builder but only SAX events

 
have you explanations or samplesfor resolving this problem 
?

thanks for your 
help

bye
 

 

===  A. DANEELS  
[EMAIL PROTECTED]  
0243083931  
The present email and all information included 
therein do not constitute a legal agreement accorded by Jouve.All legal 
agreements must be formulated in writing on paper by a legal representative of 
JOUVE.If you have received this email by mistake, please inform us of that 
fact and destroy the email and any documents it might contain. Thank you for 
your cooperation.
Le présent mail ainsi que toutes les informations 
qu'il contient ne peuvent en aucun cas être considérés comme un engagement 
juridique de quelque nature que ce soit de JOUVE. Tout accord devra être formulé 
par écrit papier ultérieur signé parun représentant légal de JOUVE. Par 
ailleurs, si vous recevez ce mail par erreur, merci de nous le signaler et de le 
détruire ainsi que l'intégralité du document qui pourrait y être 
joint.

cvs commit: cocoon-2.1/src/blocks/woody/java/org/apache/cocoon/woody/binding RepeaterJXPathBinding.java

mpo 2003/08/26 06:55:46

  Modified:src/blocks/woody/java/org/apache/cocoon/woody/formmodel
Repeater.java
   src/blocks/woody/java/org/apache/cocoon/woody/binding
RepeaterJXPathBinding.java
  Log:
  Making sure that repeater-rows are removed during load().
  Added convenience method to Repeater widget for this.
  
  Revision  ChangesPath
  1.8   +7 -0  
cocoon-2.1/src/blocks/woody/java/org/apache/cocoon/woody/formmodel/Repeater.java
  
  Index: Repeater.java
  ===
  RCS file: 
/home/cvs/cocoon-2.1/src/blocks/woody/java/org/apache/cocoon/woody/formmodel/Repeater.java,v
  retrieving revision 1.7
  retrieving revision 1.8
  diff -u -r1.7 -r1.8
  --- Repeater.java 12 Aug 2003 12:55:43 -  1.7
  +++ Repeater.java 26 Aug 2003 13:55:46 -  1.8
  @@ -103,6 +103,13 @@
   }
   
   /**
  + * Clears all rows from the repeater.
  + */
  +public void removeRows() {
  +rows.clear();
  +}
  +
  +/**
* Gets a widget on a certain row.
* @param rowIndex startin from 0
* @param id a widget id
  
  
  
  1.5   +1 -0  
cocoon-2.1/src/blocks/woody/java/org/apache/cocoon/woody/binding/RepeaterJXPathBinding.java
  
  Index: RepeaterJXPathBinding.java
  ===
  RCS file: 
/home/cvs/cocoon-2.1/src/blocks/woody/java/org/apache/cocoon/woody/binding/RepeaterJXPathBinding.java,v
  retrieving revision 1.4
  retrieving revision 1.5
  diff -u -r1.4 -r1.5
  --- RepeaterJXPathBinding.java26 Aug 2003 13:10:12 -  1.4
  +++ RepeaterJXPathBinding.java26 Aug 2003 13:55:46 -  1.5
  @@ -106,6 +106,7 @@
   public void loadFormFromModel(Widget frmModel, JXPathContext jxpc) {
   // Find the repeater
   Repeater repeater = (Repeater) frmModel.getWidget(this.repeaterId);
  +repeater.removeRows();
   
   // build a jxpath iterator for pointers
   JXPathContext repeaterContext = 
jxpc.getRelativeContext(jxpc.getPointer(this.repeaterPath));

DO NOT REPLY [Bug 20381] - XSLTC: top-level xsl:variable with document() breaks

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20381.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20381

XSLTC: top-level xsl:variable with document() breaks





--- Additional Comments From [EMAIL PROTECTED]  2003-08-26 14:26 ---
FYI 
Bug# 21857 indicates a failure of the document() function to read cocoon:/ urls 
when running under Cocoon. This only occurs in XSLTC. 

This bug, and 21857 may be related.

Woody textarea support and newline trouble

2003-08-26 Thread Timothy Larson

I tried adding textarea support to the field widget by modifying
a template in woody-default.xsl (see end of email for changes).
For example, to make a field widget use a textarea box you would
change the widget template to look like this:

  wt:widget id=sampleTextarea
textarea rows=10 cols=40/
  /wt:widget

The remaining problem is that newlines double for each round trip
of the data.  This is a classic problem with textareas.  Anybody
know a good way to solve this that will work across different
browsers?  Should a new datatype converter be made for this?

--Tim Larson

Original template in woody-default.xsl:

  xsl:template name=field
xsl:param name=fieldelement/
input name={$fieldelement/@id} value={$fieldelement/wi:value}
  xsl:if test=wi:styling
xsl:copy-of select=wi:styling/@*/
  /xsl:if
/input
  /xsl:template

Modified version of template to support textareas:

  xsl:template name=field
xsl:param name=fieldelement/
xsl:choose
  xsl:when test=wi:styling/textarea
textarea name=[EMAIL PROTECTED]
  xsl:apply-templates select=wi:styling/textarea/@*/
  xsl:value-of select=$fieldelement/wi:value/
/textarea
  /xsl:when
  xsl:otherwise
input name={$fieldelement/@id} value={$fieldelement/wi:value}
  xsl:if test=wi:styling
xsl:copy-of select=wi:styling/@*/
  /xsl:if
/input
  /xsl:otherwise
/xsl:choose
  /xsl:template


__
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.yahoo.com

Personality in docs (Was: Re: 'Production' build for Cocoon?)

2003-08-26 Thread Tony Collen

Roger I Martin PhD wrote:

Right now INSTALL.txt needs some things cut out of it:
[stuff-snipped]

I'd like to point out a few Theses of the Cluetrain which apply here:

14. Corporations do not speak in the same voice as these new networked conversations. To their
intended online audiences, companies sound hollow, flat, literally inhuman.

15. In just a few more years, the current homogenized voice of businessthe sound of mission
statements and brochureswill seem as contrived and artificial as the language of the 18th century
French court.

16. Already, companies that speak in the language of the pitch, the dog-and-pony show, are no longer
speaking to anyone.

17. Companies that assume online markets are the same markets that used to watch their ads on
television are kidding themselves.

18. Companies that don't realize their markets are now networked person-to-person, getting smarter
as a result and deeply joined in conversation are missing their best opportunity.

19. Companies can now communicate with their markets directly. If they blow it, it could be their
last chance.

20. Companies need to realize their markets are often laughing. At them.

21. Companies need to lighten up and take themselves less seriously. They need to get a sense of humor.

22. Getting a sense of humor does not mean putting some jokes on the corporate web site. Rather, it
requires big values, a little humility, straight talk, and a genuine point of view.

I don't mind making the docs a little more pofessional sounding but I'd really, really hate to see
the personality stripped from them as well. We're all people here, not robots. I'd rather read
someone's genuine opinion about why Cocoon kicks so much ass instead of reading about the latest
buzzword of the day.

Tony

Re: Personality in docs (Was: Re: 'Production' build for Cocoon?)

2003-08-26 Thread Boon Hian Tek

Tony Collen wrote:

I don't mind making the docs a little more pofessional sounding but 
I'd really, really hate to see the personality stripped from them as 
well.  We're all people here, not robots.  I'd rather read someone's 
genuine opinion about why Cocoon kicks so much ass instead of reading 
about the latest buzzword of the day.
+1

cvs commit: cocoon-2.1/src/blocks/woody/java/org/apache/cocoon/woody/datatype SelectionListBuilder.java

2003-08-26 Thread bruno

bruno   2003/08/26 08:14:04

  Modified:src/blocks/woody/java/org/apache/cocoon/woody/datatype
SelectionListBuilder.java
  Log:
  Return StaticSelectionList instead of SelectionList from build method
  
  Revision  ChangesPath
  1.3   +1 -1  
cocoon-2.1/src/blocks/woody/java/org/apache/cocoon/woody/datatype/SelectionListBuilder.java
  
  Index: SelectionListBuilder.java
  ===
  RCS file: 
/home/cvs/cocoon-2.1/src/blocks/woody/java/org/apache/cocoon/woody/datatype/SelectionListBuilder.java,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- SelectionListBuilder.java 15 Jul 2003 14:11:03 -  1.2
  +++ SelectionListBuilder.java 26 Aug 2003 15:14:04 -  1.3
  @@ -69,7 +69,7 @@
*/
   public class SelectionListBuilder {
   
  -public static SelectionList build(Element selectionListElement, Datatype 
datatype) throws Exception {
  +public static StaticSelectionList build(Element selectionListElement, Datatype 
datatype) throws Exception {
   StaticSelectionList selectionList = new StaticSelectionList(datatype);
   Convertor convertor = null;
   Convertor.FormatCache formatCache = new DefaultFormatCache();

RE: Personality in docs (Was: Re: 'Production' build for Cocoon?)

2003-08-26 Thread Chris Clark

Being the guy that started this little storm I thought I'd wade in with my 2 cents 
worth...

I don't mind the humour in the install.txt.  I thought it was refreshing to see 
somebody who admits that by-and-large, developers hate reading docs and would rather 
just dive in and figure it for themselves.  Granted, if the reader is not a developer, 
but somebody less tech-savvy (say, a Project Manager) then I could certainly see where 
the humour could be lost on them and make a bad first impression.

I think everything could be improved with slightly better organization.  I was looking 
for information on building a Production build.  So I looked for build or deploy 
documents.  I didn't think of going back to the install.txt (after all, I had already 
installed it, right?), although I had read the entire file when I downloaded and 
installed it the first time.

If it were up to me (and yes, I know it could very well be if I had the time!), I 
would create a readme.txt that would point the user to one of install.txt, build.txt, 
deploy.txt and maybe an overview.txt or welcome.txt.  The install could be left pretty 
much the same (just make sure there's a link to the website with all the 
version-specific helps).  The build.txt could cover the modifications to the 
local.build.properties and maybe go into a bit more detail (sentence each) on what the 
various things control.  The welcome/overview could be targeted at the less tech-savvy 
crew (with appropriate language/tone).

So, my vote would be to keep the personality, just flesh out what's there a little 
more and maybe make a concessionary personality-free doc for the non-developer 
audience that expects sterile business language.

Cheers,
Chris

 -Original Message-
 From: Tony Collen [SMTP:[EMAIL PROTECTED]
 Sent: Tuesday, August 26, 2003 12:54 PM
 To:   [EMAIL PROTECTED]
 Subject:  Personality in docs (Was: Re: 'Production' build for Cocoon?)
 
 Roger I Martin PhD wrote:
 
  Right now INSTALL.txt needs some things cut out of it:
 
 [stuff-snipped]
 
 I'd like to point out a few Theses of the Cluetrain which apply here:
 
 14. Corporations do not speak in the same voice as these new networked 
 conversations. To their 
 intended online audiences, companies sound hollow, flat, literally inhuman.
 
 15. In just a few more years, the current homogenized voice of business - the 
 sound of mission 
 statements and brochures - will seem as contrived and artificial as the language 
 of the 18th century 
 French court.
 
 16. Already, companies that speak in the language of the pitch, the dog-and-pony 
 show, are no longer 
 speaking to anyone.
 
 17. Companies that assume online markets are the same markets that used to watch 
 their ads on 
 television are kidding themselves.
 
 18. Companies that don't realize their markets are now networked person-to-person, 
 getting smarter 
 as a result and deeply joined in conversation are missing their best opportunity.
 
 19. Companies can now communicate with their markets directly. If they blow it, it 
 could be their 
 last chance.
 
 20. Companies need to realize their markets are often laughing. At them.
 
 21. Companies need to lighten up and take themselves less seriously. They need to 
 get a sense of humor.
 
 22. Getting a sense of humor does not mean putting some jokes on the corporate web 
 site. Rather, it 
 requires big values, a little humility, straight talk, and a genuine point of view.
 
 I don't mind making the docs a little more pofessional sounding but I'd really, 
 really hate to see 
 the personality stripped from them as well.  We're all people here, not robots.  I'd 
 rather read 
 someone's genuine opinion about why Cocoon kicks so much ass instead of reading 
 about the latest 
 buzzword of the day.
 
 
 Tony

DO NOT REPLY [Bug 22732] New: - Cocoon Servlet can't be included

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22732.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22732

Cocoon Servlet can't be included

   Summary: Cocoon Servlet can't be included
   Product: Cocoon 2
   Version: 2.0.4
  Platform: Other
OS/Version: Other
Status: NEW
  Severity: Normal
  Priority: Other
 Component: core
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Cocoon doesn't check for javax.servlet.include.* request parameters and use them
if present. Its fairly easy to fix in CocoonServlet.

Should then Request reflect the orginal values or the include values?

Anyway, I will figure out how to submit a patch once thats decided.

DO NOT REPLY [Bug 22707] - Syntax Error in build.bat on Windows ME