[jira] Commented: (TAP5-1302) tapestry-component-report fails due to doxia dependency error

2011-01-07 Thread Antal van Kalleveen (JIRA)

[ 
https://issues.apache.org/jira/browse/TAP5-1302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12978681#action_12978681
 ] 

Antal van Kalleveen commented on TAP5-1302:
---

I'm having the same issue, updating the site plugin to version 2.0-beta-5 did 
not resolve the problem. Here is an excerpt of my plugin dependencies:


[INFO] Plugin Resolved: tapestry-component-report-5.2.4.jar
[INFO] Plugin Dependency Resolved: maven-project-2.0.9.jar
[INFO] Plugin Dependency Resolved: maven-plugin-api-2.0.9.jar
[INFO] Plugin Dependency Resolved: plexus-utils-1.5.6.jar
[INFO] Plugin Dependency Resolved: maven-plugin-descriptor-2.0.9.jar
[INFO] Plugin Dependency Resolved: maven-reporting-impl-2.0.4.1.jar
[INFO] Plugin Dependency Resolved: doxia-site-renderer-1.0-alpha-11.jar
[INFO] Plugin Dependency Resolved: commons-lang-2.1.jar
[INFO] Plugin Dependency Resolved: tapestry-ioc-5.2.4.jar
[INFO] Plugin Dependency Resolved: xom-1.1.jar
[INFO] Plugin Dependency Resolved: tools.jar
[INFO] Plugin Resolved: maven-clean-plugin-2.4.1.jar
[INFO] Plugin Dependency Resolved: maven-plugin-api-2.0.6.jar
[INFO] Plugin Dependency Resolved: plexus-utils-2.0.5.jar
[INFO] Plugin Resolved: maven-surefire-plugin-2.5.jar
[INFO] Plugin Dependency Resolved: maven-plugin-api-2.0.9.jar
[INFO] Plugin Dependency Resolved: surefire-booter-2.5.jar
[INFO] Plugin Dependency Resolved: plexus-utils-1.5.9.jar
[INFO] Plugin Dependency Resolved: maven-artifact-2.0.9.jar
[INFO] Plugin Dependency Resolved: maven-project-2.0.9.jar
[INFO] Plugin Dependency Resolved: maven-core-2.0.9.jar
[INFO] Plugin Dependency Resolved: maven-toolchain-2.0.9.jar
[INFO] Plugin Resolved: maven-site-plugin-2.0-beta-5.jar
[INFO] Plugin Dependency Resolved: maven-plugin-api-2.0.jar
[INFO] Plugin Dependency Resolved: maven-artifact-2.0.2.jar
[INFO] Plugin Dependency Resolved: maven-project-2.0.jar
[INFO] Plugin Dependency Resolved: maven-settings-2.0.jar
[INFO] Plugin Dependency Resolved: doxia-site-renderer-1.0-alpha-8.jar
[INFO] Plugin Dependency Resolved: maven-reporting-api-2.0.2.jar
[INFO] Plugin Dependency Resolved: plexus-utils-1.1.jar
[INFO] Plugin Dependency Resolved: jetty-6.0.0beta12.jar



 tapestry-component-report fails due to doxia dependency error
 -

 Key: TAP5-1302
 URL: https://issues.apache.org/jira/browse/TAP5-1302
 Project: Tapestry 5
  Issue Type: Bug
  Components: tapestry-component-report
Affects Versions: 5.2.0, 5.1.0.5
Reporter: Inge
Priority: Critical

 First of all, I encountered this bug, which prevents component report to run 
 on Windows 7:
 https://issues.apache.org/jira/browse/TAP5-871
 After applying the patch found in that issue, I ran into the next one:
 java.lang.NoSuchMethodError: 
 org.apache.maven.doxia.module.xhtml.XhtmlSink.writeEndTagWithoutEOL(Ljavax/swing/text/html/HTML$Tag;)V
at 
 org.apache.maven.doxia.module.xhtml.XhtmlSink.link_(XhtmlSink.java:1066)
at 
 org.apache.tapestry.mojo.ComponentReport.executeReport(ComponentReport.java:240)
at 
 org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMavenReport.java:90)
at 
 org.apache.maven.reporting.AbstractMavenReport.execute(AbstractMavenReport.java:65)
at 
 org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:454)
at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:559)
at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:513)
at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:483)
at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:331)
at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:292)
at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:142)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:345)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:132)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:290)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:592)
at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at 

[jira] Commented: (TAP5-1355) Threading issue with SessionStateObjects

2011-01-07 Thread Moritz Gmelin (JIRA)

[ 
https://issues.apache.org/jira/browse/TAP5-1355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12978691#action_12978691
 ] 

Moritz Gmelin commented on TAP5-1355:
-

Hi,

is there any progress on this? Any chance that this will be fixed in 5.2.4.1?

Moritz

 Threading issue with SessionStateObjects
 

 Key: TAP5-1355
 URL: https://issues.apache.org/jira/browse/TAP5-1355
 Project: Tapestry 5
  Issue Type: Bug
  Components: tapestry-core
Affects Versions: 5.2.4
Reporter: Moritz Gmelin
 Attachments: Screenshot.png.jpg, taptest.tgz


 When a page request consists of multiple HTTP request (e.g. page and some 
 dynamically generated images) and all those requests access a 
 SessionStateObject, it happens that a new session (with an empty SSO) is 
 created for some of the request threads.
 I was able to create a very simple example to recreate that problem:
   -A simple page that displays 20 dynamically generated images in a loop.
   -In the page, a SSO, holding a number value is initialized to a random 
 number.
   -Each of the dynamic images read that number and draws it.
   -Make sure that a HTTP-Request is made for every image on the page (by 
 adding some random number to the event link)
 The effect that you'll see after some reloads of the page (maybe you need to 
 reload 30 times) is that some images will draw 0 as SSO value instead of the 
 number set in the page @BeginRender method. Those fields will be marked in 
 red in the demo so you can quickly see them. 
 I definitely beleive that tapestry should take care of this. It is a use case 
 for SSOs that is probably too common to ignore. 
 Why can't this be automatically integrated into the ApplicationStateManager?
  
 The demo has been deployed here
 http://www.avetana.de/taptest/

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Commented: (TAP5-1407) multizoneupdate should be easier to use - not a chain

2011-01-07 Thread Howard M. Lewis Ship (JIRA)

[ 
https://issues.apache.org/jira/browse/TAP5-1407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12978883#action_12978883
 ] 

Howard M. Lewis Ship commented on TAP5-1407:


Actually, I'm thinking the MultiZoneUpdate object could be deprecated, and a 
service take its place.  MZU is just a bit unwieldy to use, despite some work 
on it in 5.2 and, in the long run, it doesn't actually prevent some amount of 
per-thread state from being stored ... in other words, over-engineered.  

 multizoneupdate should be easier to use - not a chain
 -

 Key: TAP5-1407
 URL: https://issues.apache.org/jira/browse/TAP5-1407
 Project: Tapestry 5
  Issue Type: Improvement
  Components: tapestry-core
Affects Versions: 5.2.4
Reporter: Paul Stanton
 Fix For: 5.2.4


 Currently MultiZoneUpdate is a chain of MultiZoneUpdates, ie
 public class MultiZoneUpdate
 {
 ...
 public MultiZoneUpdate add(String zoneId, Object renderer)
 {
 return new MultiZoneUpdate(zoneId, renderer, this);
 }
 ...
 }
 usage:
 MultiZoneUpdate mzu = new MultiZoneUpdate(zone2, zone1); // ugly!
 mzu = mzu.add(zone2, zone2); // ugly!
 mzu = mzu.add(zone3, zone3); // ugly!
 ...
 return mzu;
 This becomes hard to use when event handlers call common methods which 
 contribute zone updates.
 Also, it is possible to request multiple updates for the one zone which 
 doesn't make much sense.
 In some cases it would be much easier if you could construct a 
 MultiZoneUpdate object without actually contributing a zone update directive. 
 ie:
 MultiZoneUpdate mzu = new MultiZoneUpdate();
 mzu.add(zone2, zone1);
 mzu.add(zone2, zone2);
 mzu.add(zone3, zone3);
 mzu.add(zone3, zone3); // knocks out prev zone3 update
 ...
 return mzu;
 I have created a utility class which helps me work around this issue (and 
 issue #TAP5-1406), however note it relies on the dummy zone hack.:
 import java.util.HashMap;
 import java.util.Map.Entry;
 import org.apache.tapestry5.ComponentResources;
 import org.apache.tapestry5.MarkupWriter;
 import org.apache.tapestry5.ajax.MultiZoneUpdate;
 import org.apache.tapestry5.internal.services.PageRenderQueue;
 import org.apache.tapestry5.json.JSONObject;
 import org.apache.tapestry5.services.PartialMarkupRenderer;
 import org.apache.tapestry5.services.PartialMarkupRendererFilter;
 import org.apache.tapestry5.services.javascript.JavaScriptSupport;
 public class XHRResponseHelper
 {
   private HashMapString, Object zoneUpdates;
   private boolean scriptAdded;
   public XHRResponseHelper()
   {
   this.zoneUpdates = new HashMapString, Object();
   scriptAdded = false;
   }
   public void addScriptCall(final String script, PageRenderQueue 
 pageRenderQueue, final JavaScriptSupport javascriptSupport)
   {
   scriptAdded = true;
   pageRenderQueue.addPartialMarkupRendererFilter(new 
 PartialMarkupRendererFilter()
   {
   public void renderMarkup(MarkupWriter writer, 
 JSONObject reply, PartialMarkupRenderer renderer)
   {
   javascriptSupport.addScript(script);
   renderer.renderMarkup(writer, reply);
   }
   });
   }
   public void addZoneUpdate(String zoneId, ComponentResources 
 componentResources)
   {
   addZoneUpdate(zoneId, 
 componentResources.getEmbeddedComponent(zoneId));
   }
   public void addZoneUpdate(String zoneId, Object renderer)
   {
   zoneUpdates.put(zoneId, renderer);
   }
   public MultiZoneUpdate buildMultiZoneUpdate(ComponentResources 
 componentResources)
   {
   // work around issue  - 
 https://issues.apache.org/jira/browse/TAP5-1406
   if (zoneUpdates.isEmpty()  scriptAdded)
   addZoneUpdate(dummyZone, componentResources);
   MultiZoneUpdate mzu = null;
   for (EntryString, Object entry : zoneUpdates.entrySet())
   {
   if (mzu == null)
   mzu = new MultiZoneUpdate(entry.getKey(), 
 entry.getValue());
   else
   mzu.add(entry.getKey(), entry.getValue());
   }
   return mzu; // null if zoneUpdates is empty
   }
 }
 usage:
 XHRResponseHelper response = new XHRResponseHelper();
 response.addZoneUpdate(myZone, componentResources);
 response.addZoneUpdate(myZone2, block);
 response.addScriptCall(alert('script');, pageRenderQueue, 
 javascriptSupport);
 return response.buildMultiZoneUpdate(componentResources);
 hope that helps.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a 

[jira] Commented: (TAP5-1407) multizoneupdate should be easier to use - not a chain

2011-01-07 Thread Paul Stanton (JIRA)

[ 
https://issues.apache.org/jira/browse/TAP5-1407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12978935#action_12978935
 ] 

Paul Stanton commented on TAP5-1407:


good, that is kind of what i'm suggesting too.

if it were a service, would it be an environmental? if so, wouldn't it fall 
into the trap of being bound to one 'component layer'?

in one 'xhr-response' i often need to create zone updates for zones at 
different levels ie (note the method 
'addSomeZoneUpdatesUsingYourOwnComponentResources'):

public class MyPage
{
...
@InjectComponent
private MyComponent myComponent;

private MultiZoneUpdate onMyEvent()
{
XHRResponseHelper response = new XHRResponseHelper();
response.addZoneUpdate(myZone, componentResources);

myComponent.addSomeZoneUpdatesUsingYourOwnComponentResources(response);

response.addScriptCall(alert('script');, pageRenderQueue, javascriptSupport);
return response.buildMultiZoneUpdate(componentResources);
}

this is why i have the environmentals as parameters for my helper class .. so 
that the response can be contributed to from multiple 'environments' ie 
components.

 multizoneupdate should be easier to use - not a chain
 -

 Key: TAP5-1407
 URL: https://issues.apache.org/jira/browse/TAP5-1407
 Project: Tapestry 5
  Issue Type: Improvement
  Components: tapestry-core
Affects Versions: 5.2.4
Reporter: Paul Stanton
 Fix For: 5.2.4


 Currently MultiZoneUpdate is a chain of MultiZoneUpdates, ie
 public class MultiZoneUpdate
 {
 ...
 public MultiZoneUpdate add(String zoneId, Object renderer)
 {
 return new MultiZoneUpdate(zoneId, renderer, this);
 }
 ...
 }
 usage:
 MultiZoneUpdate mzu = new MultiZoneUpdate(zone2, zone1); // ugly!
 mzu = mzu.add(zone2, zone2); // ugly!
 mzu = mzu.add(zone3, zone3); // ugly!
 ...
 return mzu;
 This becomes hard to use when event handlers call common methods which 
 contribute zone updates.
 Also, it is possible to request multiple updates for the one zone which 
 doesn't make much sense.
 In some cases it would be much easier if you could construct a 
 MultiZoneUpdate object without actually contributing a zone update directive. 
 ie:
 MultiZoneUpdate mzu = new MultiZoneUpdate();
 mzu.add(zone2, zone1);
 mzu.add(zone2, zone2);
 mzu.add(zone3, zone3);
 mzu.add(zone3, zone3); // knocks out prev zone3 update
 ...
 return mzu;
 I have created a utility class which helps me work around this issue (and 
 issue #TAP5-1406), however note it relies on the dummy zone hack.:
 import java.util.HashMap;
 import java.util.Map.Entry;
 import org.apache.tapestry5.ComponentResources;
 import org.apache.tapestry5.MarkupWriter;
 import org.apache.tapestry5.ajax.MultiZoneUpdate;
 import org.apache.tapestry5.internal.services.PageRenderQueue;
 import org.apache.tapestry5.json.JSONObject;
 import org.apache.tapestry5.services.PartialMarkupRenderer;
 import org.apache.tapestry5.services.PartialMarkupRendererFilter;
 import org.apache.tapestry5.services.javascript.JavaScriptSupport;
 public class XHRResponseHelper
 {
   private HashMapString, Object zoneUpdates;
   private boolean scriptAdded;
   public XHRResponseHelper()
   {
   this.zoneUpdates = new HashMapString, Object();
   scriptAdded = false;
   }
   public void addScriptCall(final String script, PageRenderQueue 
 pageRenderQueue, final JavaScriptSupport javascriptSupport)
   {
   scriptAdded = true;
   pageRenderQueue.addPartialMarkupRendererFilter(new 
 PartialMarkupRendererFilter()
   {
   public void renderMarkup(MarkupWriter writer, 
 JSONObject reply, PartialMarkupRenderer renderer)
   {
   javascriptSupport.addScript(script);
   renderer.renderMarkup(writer, reply);
   }
   });
   }
   public void addZoneUpdate(String zoneId, ComponentResources 
 componentResources)
   {
   addZoneUpdate(zoneId, 
 componentResources.getEmbeddedComponent(zoneId));
   }
   public void addZoneUpdate(String zoneId, Object renderer)
   {
   zoneUpdates.put(zoneId, renderer);
   }
   public MultiZoneUpdate buildMultiZoneUpdate(ComponentResources 
 componentResources)
   {
   // work around issue  - 
 https://issues.apache.org/jira/browse/TAP5-1406
   if (zoneUpdates.isEmpty()  scriptAdded)
   addZoneUpdate(dummyZone, componentResources);
   MultiZoneUpdate mzu = null;
   for (EntryString, Object entry : zoneUpdates.entrySet())
   {
   if (mzu == null)
   mzu = new MultiZoneUpdate(entry.getKey(), 
 

[jira] Updated: (TAP5-1407) multizoneupdate should be easier to use - not a chain

2011-01-07 Thread Paul Stanton (JIRA)

 [ 
https://issues.apache.org/jira/browse/TAP5-1407?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Paul Stanton updated TAP5-1407:
---

Description: 
Currently MultiZoneUpdate is a chain of MultiZoneUpdates, ie

public class MultiZoneUpdate
{
...
public MultiZoneUpdate add(String zoneId, Object renderer)
{
return new MultiZoneUpdate(zoneId, renderer, this);
}
...
}

usage:

MultiZoneUpdate mzu = new MultiZoneUpdate(zone2, zone1); // ugly!
mzu = mzu.add(zone2, zone2); // ugly!
mzu = mzu.add(zone3, zone3); // ugly!
...
return mzu;

This becomes hard to use when event handlers call common methods which 
contribute zone updates.

Also, it is possible to request multiple updates for the one zone which doesn't 
make much sense.

In some cases it would be much easier if you could construct a MultiZoneUpdate 
object without actually contributing a zone update directive. ie:

MultiZoneUpdate mzu = new MultiZoneUpdate();
mzu.add(zone2, zone1);
mzu.add(zone2, zone2);
mzu.add(zone3, zone3);
mzu.add(zone3, zone3); // knocks out prev zone3 update
...
return mzu;

I have created a utility class which helps me work around this issue (and issue 
#TAP5-1406), however note it relies on the dummy zone hack.:


import java.util.HashMap;
import java.util.Map.Entry;

import org.apache.tapestry5.ComponentResources;
import org.apache.tapestry5.MarkupWriter;
import org.apache.tapestry5.ajax.MultiZoneUpdate;
import org.apache.tapestry5.internal.services.PageRenderQueue;
import org.apache.tapestry5.json.JSONObject;
import org.apache.tapestry5.services.PartialMarkupRenderer;
import org.apache.tapestry5.services.PartialMarkupRendererFilter;
import org.apache.tapestry5.services.javascript.JavaScriptSupport;

public class XHRResponseHelper
{
private HashMapString, Object zoneUpdates;
private boolean scriptAdded;

public XHRResponseHelper()
{
this.zoneUpdates = new HashMapString, Object();
scriptAdded = false;
}

public void addScriptCall(final String script, PageRenderQueue 
pageRenderQueue, final JavaScriptSupport javascriptSupport)
{
scriptAdded = true;
pageRenderQueue.addPartialMarkupRendererFilter(new 
PartialMarkupRendererFilter()
{
public void renderMarkup(MarkupWriter writer, 
JSONObject reply, PartialMarkupRenderer renderer)
{
javascriptSupport.addScript(script);
renderer.renderMarkup(writer, reply);
}
});
}

public void addZoneUpdate(String zoneId, ComponentResources 
componentResources)
{
addZoneUpdate(zoneId, 
componentResources.getEmbeddedComponent(zoneId));
}

public void addZoneUpdate(String zoneId, Object renderer)
{
zoneUpdates.put(zoneId, renderer);
}

public MultiZoneUpdate buildMultiZoneUpdate(ComponentResources 
componentResources)
{
// work around issue  - 
https://issues.apache.org/jira/browse/TAP5-1406
if (zoneUpdates.isEmpty()  scriptAdded)
addZoneUpdate(dummyZone, componentResources);

MultiZoneUpdate mzu = null;

for (EntryString, Object entry : zoneUpdates.entrySet())
{
if (mzu == null)
mzu = new MultiZoneUpdate(entry.getKey(), 
entry.getValue());
else
mzu = mzu.add(entry.getKey(), entry.getValue());
}

return mzu; // null if zoneUpdates is empty
}
}

usage:

XHRResponseHelper response = new XHRResponseHelper();
response.addZoneUpdate(myZone, componentResources);
response.addZoneUpdate(myZone2, block);
response.addScriptCall(alert('script');, pageRenderQueue, javascriptSupport);
return response.buildMultiZoneUpdate(componentResources);


hope that helps.

  was:
Currently MultiZoneUpdate is a chain of MultiZoneUpdates, ie

public class MultiZoneUpdate
{
...
public MultiZoneUpdate add(String zoneId, Object renderer)
{
return new MultiZoneUpdate(zoneId, renderer, this);
}
...
}

usage:

MultiZoneUpdate mzu = new MultiZoneUpdate(zone2, zone1); // ugly!
mzu = mzu.add(zone2, zone2); // ugly!
mzu = mzu.add(zone3, zone3); // ugly!
...
return mzu;

This becomes hard to use when event handlers call common methods which 
contribute zone updates.

Also, it is possible to request multiple updates for the one zone which doesn't 
make much sense.

In some cases it would be much easier if you could construct a MultiZoneUpdate 
object without actually contributing a zone update directive. ie:

MultiZoneUpdate mzu = new MultiZoneUpdate();
mzu.add(zone2, zone1);
mzu.add(zone2, zone2);

svn commit: r1056524 - in /tapestry/tapestry5/trunk: tapestry-core/src/main/java/org/apache/tapestry5/dom/ tapestry-core/src/main/java/org/apache/tapestry5/internal/services/javascript/ tapestry-func/

2011-01-07 Thread hlship
Author: hlship
Date: Fri Jan  7 21:31:05 2011
New Revision: 1056524

URL: http://svn.apache.org/viewvc?rev=1056524view=rev
Log:
TAP5-1390: Convert Predicate, Mapper and Worker from abstract base classes
to single method interfaces (for future lambda compatibility)
Move other operations to static methods of F

Modified:

tapestry/tapestry5/trunk/tapestry-core/src/main/java/org/apache/tapestry5/dom/Element.java

tapestry/tapestry5/trunk/tapestry-core/src/main/java/org/apache/tapestry5/internal/services/javascript/DateFieldStack.java

tapestry/tapestry5/trunk/tapestry-func/src/main/java/org/apache/tapestry5/func/AbstractFlow.java

tapestry/tapestry5/trunk/tapestry-func/src/main/java/org/apache/tapestry5/func/F.java

tapestry/tapestry5/trunk/tapestry-func/src/main/java/org/apache/tapestry5/func/Mapper.java

tapestry/tapestry5/trunk/tapestry-func/src/main/java/org/apache/tapestry5/func/Mapper2.java

tapestry/tapestry5/trunk/tapestry-func/src/main/java/org/apache/tapestry5/func/Predicate.java

tapestry/tapestry5/trunk/tapestry-func/src/main/java/org/apache/tapestry5/func/Worker.java

tapestry/tapestry5/trunk/tapestry-func/src/main/java/org/apache/tapestry5/func/ZippedFlowImpl.java

tapestry/tapestry5/trunk/tapestry-func/src/test/java/org/apache/tapestry5/func/FuncTest.java

tapestry/tapestry5/trunk/tapestry-func/src/test/java/org/apache/tapestry5/func/ZippedFlowTests.java

tapestry/tapestry5/trunk/tapestry-ioc/src/main/java/org/apache/tapestry5/ioc/internal/RegistryImpl.java

Modified: 
tapestry/tapestry5/trunk/tapestry-core/src/main/java/org/apache/tapestry5/dom/Element.java
URL: 
http://svn.apache.org/viewvc/tapestry/tapestry5/trunk/tapestry-core/src/main/java/org/apache/tapestry5/dom/Element.java?rev=1056524r1=1056523r2=1056524view=diff
==
--- 
tapestry/tapestry5/trunk/tapestry-core/src/main/java/org/apache/tapestry5/dom/Element.java
 (original)
+++ 
tapestry/tapestry5/trunk/tapestry-core/src/main/java/org/apache/tapestry5/dom/Element.java
 Fri Jan  7 21:31:05 2011
@@ -1,10 +1,10 @@
-// Copyright 2006, 2007, 2008, 2009, 2010 The Apache Software Foundation
+// Copyright 2006, 2007, 2008, 2009, 2010, 2011 The Apache Software Foundation
 //
 // Licensed under the Apache License, Version 2.0 (the License);
 // you may not use this file except in compliance with the License.
 // You may obtain a copy of the License at
 //
-// http://www.apache.org/licenses/LICENSE-2.0
+// http://www.apache.org/licenses/LICENSE-2.0
 //
 // Unless required by applicable law or agreed to in writing, software
 // distributed under the License is distributed on an AS IS BASIS,
@@ -52,7 +52,7 @@ public final class Element extends Node
 private static final String CLASS_ATTRIBUTE = class;
 
 /**
- * URI of the namespace which contains the element.  A quirk in XML is 
that the element may be in a namespace it
+ * URI of the namespace which contains the element. A quirk in XML is that 
the element may be in a namespace it
  * defines itself, so resolving the namespace to a prefix must wait until 
render time (since the Element is created
  * before the namespaces for it are defined).
  */
@@ -93,7 +93,7 @@ public final class Element extends Node
 
 /**
  * Returns the containing element for this element. This will be null for 
the root element of a document.
- *
+ * 
  * @deprecated since 5.1.0.1, use {...@link Node#getContainer()} instead
  */
 public Element getParent()
@@ -103,10 +103,12 @@ public final class Element extends Node
 
 /**
  * Adds an attribute to the element, but only if the attribute name does 
not already exist.
- *
- * @param name  the name of the attribute to add
- * @param value the value for the attribute. A value of null is allowed, 
and no attribute will be added to the
- *  element.
+ * 
+ * @param name
+ *the name of the attribute to add
+ * @param value
+ *the value for the attribute. A value of null is allowed, and 
no attribute will be added to the
+ *element.
  */
 public Element attribute(String name, String value)
 {
@@ -115,11 +117,14 @@ public final class Element extends Node
 
 /**
  * Adds a namespaced attribute to the element, but only if the attribute 
name does not already exist.
- *
- * @param namespace the namespace to contain the attribute, or null
- * @param name  the name of the attribute to add
- * @param value the value for the attribute. A value of null is 
allowed, and no attribute will be added to the
- *  element.
+ * 
+ * @param namespace
+ *the namespace to contain the attribute, or null
+ * @param name
+ *the name of the attribute to add
+ * @param value
+ *the value for the 

[CONF] Apache Tapestry Persistent State

2011-01-07 Thread confluence







Persistent State
Page edited by Bob Harner


Comment:
First attempt at warning as suggested by Pierce Wetter yesterday


 Changes (2)
 



...
{code}  
Any other component or page that declares a field *of the same type*, regardless of name, and marks it with the SessionState annotation will share the same value. Its that simple.  However, using @SessionState _safely_ requires care: 
 
{warning} DO NOT USE THIS FOR SIMPLE TYPES! Only use @SessionState on variables that are of a custom-built class designed expressly for this purpose!  Read more below. {warning}  With @SessionState, you are creating session-wide data that is not specifically tied to the variable name you used, or even to the class in which that variable was defined. As with all session data, there is the possibility of collisions, not just within your application but with other modules/libraries.  {code:title=Example of Collision -- Dont do this!}   @SessionState   private String myState; // Unsafe -- String is not a custom type@sessionState   private String myOtherState;// This overwrites the myState value, because its also a String! {code}  For these reasons, NEVER USE @SessionState FOR SIMPLE-TYPE VARIABLES. It is ALWAYS worth taking the time to build a special class to hold your session state information, because it will force you to consolidate that information into a single, logical unit that cant be accidentally accessed by other classes.  
_For Tapestry 4 Users:_ a big change here is that you dont need to provide any configuration for the SSO before using it, nor do you provide a logical name. Tapestry 5 uses the class name to identify the SSO, so theres no need for a logical name.  
...

Full Content

Persistent State

Often, you will have a situation where you have a bit of data that is needed across multiple pages. Perhaps you are creating a multi-page wizard, or perhaps you have an object that tracks the user's identify once logged in.

Ordinary persistent page data is not appropriate, since persistent fields apply to a specific page and aren't shared across pages.

Instead, you want to use a Session State Object (an SSO).

With an SSO, the value is automatically stored outside the page; with the default storage strategy, it is stored in the session. Such a value is global to all pages for the same user, but is stored seperately for different users.

A field holding an SSO is marked with the SessionState annotation.

Example:



public class MyPage
{
  @SessionState
  private MyState myState;
  
  . . .
}



Any other component or page that declares a field of the same type, regardless of name, and marks it with the SessionState annotation will share the same value. It's that simple.  However, using @SessionState safely requires care:

DO NOT USE THIS FOR SIMPLE TYPES! Only use @SessionState on variables that are of a custom-built class designed expressly for this purpose!  Read more below.

With @SessionState, you are creating session-wide data that is not specifically tied to the variable name you used, or even to the class in which that variable was defined. As with all session data, there is the possibility of collisions, not just within your application but with other modules/libraries.

Example of Collision  Don't do this!

  @SessionState
  private String myState; // Unsafe -- String is not a custom type

  @sessionState
  private String myOtherState;// This overwrites the myState value, because it's also a String!



For these reasons, NEVER USE @SessionState FOR SIMPLE-TYPE VARIABLES. It is ALWAYS worth taking the time to build a special class to hold your session state information, because it will force you to consolidate that information into a single, logical unit that can't be accidentally accessed by other classes.

For Tapestry 4 Users: a big change here is that you don't need to provide any configuration for the SSO before using it, nor do you provide a logical name. Tapestry 5 uses the class name to identify the SSO, so there's no need for a logical name.

The first time you access an SSO, it is created automatically. Typically, the SSO will have a public no-args constructor ... but you may inject dependencies into the SSO via its constructor, as you can with a Tapestry IoC service implementation.

Assigning a value to an SSO field will store that value. Assigning null to an SSO field will remove the SSO (reading the field subsequently will force a new SSO instance to be created).

Check for Creation

Scalable web applications do not create the server-side session needlessly. If you can avoid creating the session, especially on first access to your web application, you will be able to handle an order of 

svn commit: r1056573 - /tapestry/tapestry5/branches/maint-5-2/

2011-01-07 Thread hlship
Author: hlship
Date: Sat Jan  8 00:46:51 2011
New Revision: 1056573

URL: http://svn.apache.org/viewvc?rev=1056573view=rev
Log:
Create branch maint-5-2

Added:
tapestry/tapestry5/branches/maint-5-2/   (props changed)
  - copied from r1035364, tapestry/tapestry5/trunk/

Propchange: tapestry/tapestry5/branches/maint-5-2/
--
--- svn:ignore (added)
+++ svn:ignore Sat Jan  8 00:46:51 2011
@@ -0,0 +1,11 @@
+bin
+target
+bin-test
+temp-testng-customsuite.xml
+*.iml
+*.ipr
+*.iws
+.classpath
+.project
+.settings
+.externalToolBuilders

Propchange: tapestry/tapestry5/branches/maint-5-2/
--
--- svn:mergeinfo (added)
+++ svn:mergeinfo Sat Jan  8 00:46:51 2011
@@ -0,0 +1,4 @@
+/tapestry/tapestry5/branches/5.0:717929-719744,723395-728733
+/tapestry/tapestry5/branches/hlship-5.0-perf:726734-728728
+/tapestry/tapestry5/tags/releases/5.0.17:719745
+/tapestry/tapestry5/tags/releases/hlship-5.0-perf:726733




[jira] Assigned: (TAP5-1372) BaseURLSource uses getLocalPort() rather than getServerPort()

2011-01-07 Thread Howard M. Lewis Ship (JIRA)

 [ 
https://issues.apache.org/jira/browse/TAP5-1372?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Howard M. Lewis Ship reassigned TAP5-1372:
--

Assignee: Howard M. Lewis Ship

 BaseURLSource uses getLocalPort() rather than getServerPort()
 -

 Key: TAP5-1372
 URL: https://issues.apache.org/jira/browse/TAP5-1372
 Project: Tapestry 5
  Issue Type: Bug
  Components: tapestry-core
Affects Versions: 5.2.4
Reporter: Andy Blower
Assignee: Howard M. Lewis Ship
Priority: Critical

 Line 31 of BaseURLSourceImpl:
 int port = request.getLocalPort();
 Which calls same method in the underlying ServletRequest.
 getLocalPort javadoc: Returns the Internet Protocol (IP) port number of the 
 interface on which the request was received.
 getServerPort javadoc: Returns the port number to which the request was 
 sent. It is the value of the part after : in the codeHost/code header, 
 if any, or the server port where the client connection was accepted on.
 I think that the second is the one that should be used and since this port 
 number is paired with the host returned from getServerName() rather than 
 getLocalName(), this seems like a bug to me. Admittedly one that only causes 
 problems in clustered  load balanced environments, but it's just affected 
 our site so it would be great if it could be fixed for 5.2 final release. A 
 final release of Tapestry should not have a bug like this in it!
 Unless anyone has a convincing argument why it should be this way, of 
 course...

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Assigned: (TAP5-1355) Threading issue with SessionStateObjects

2011-01-07 Thread Josh Canfield (JIRA)

 [ 
https://issues.apache.org/jira/browse/TAP5-1355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Josh Canfield reassigned TAP5-1355:
---

Assignee: Josh Canfield

 Threading issue with SessionStateObjects
 

 Key: TAP5-1355
 URL: https://issues.apache.org/jira/browse/TAP5-1355
 Project: Tapestry 5
  Issue Type: Bug
  Components: tapestry-core
Affects Versions: 5.2.4
Reporter: Moritz Gmelin
Assignee: Josh Canfield
 Attachments: Screenshot.png.jpg, taptest.tgz


 When a page request consists of multiple HTTP request (e.g. page and some 
 dynamically generated images) and all those requests access a 
 SessionStateObject, it happens that a new session (with an empty SSO) is 
 created for some of the request threads.
 I was able to create a very simple example to recreate that problem:
   -A simple page that displays 20 dynamically generated images in a loop.
   -In the page, a SSO, holding a number value is initialized to a random 
 number.
   -Each of the dynamic images read that number and draws it.
   -Make sure that a HTTP-Request is made for every image on the page (by 
 adding some random number to the event link)
 The effect that you'll see after some reloads of the page (maybe you need to 
 reload 30 times) is that some images will draw 0 as SSO value instead of the 
 number set in the page @BeginRender method. Those fields will be marked in 
 red in the demo so you can quickly see them. 
 I definitely beleive that tapestry should take care of this. It is a use case 
 for SSOs that is probably too common to ignore. 
 Why can't this be automatically integrated into the ApplicationStateManager?
  
 The demo has been deployed here
 http://www.avetana.de/taptest/

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[CONF] Apache Tapestry Session Storage

2011-01-07 Thread confluence







Session Storage
Page edited by Bob Harner


Comment:
Renamed to Session Storage. added SessionAttribute section at bottom (somebody had removed it from the Persistent Page Data page). Tweaked the new Pitfalls section. 


 Changes (44)
 



h1. Persistent State 
{float:right|background="" {contentbylabel:title=Related Articles|showLabels=false|showSpace=false|spa...@self|labels=persistence} {float}  
 
Often, you will have a situation where you have a bit of data that is needed across multiple pages. Perhaps you are creating a multi-page wizard, or perhaps you have an object that tracks the users identify once logged in. 
h1. Session Storage 
 
Ordinary [persistent page data|#persist.html] is not appropriate, since persistent fields apply to a specific page and arent shared across pages. 
Often, you will have a bit of data that is needed across multiple pages. Perhaps you are creating a multi-page wizard, or you have an object that tracks the users identify once logged in, or maybe a shopping cart. 
 
Instead, you want to use a _Session State Object_ (an SSO). 
Ordinary [Persistent Page Data] wont work for this, since persistent fields are available only to a specific page, not shared across multiple pages. 
 
With an SSO, the value is automatically stored outside the page; with the default storage strategy, it is stored in the session. Such a value is global to all pages _for the same user_, but is stored seperately for different users. 
Tapestry provides two mechanisms for storing such data: Session State Objects and Session Attributes. When deciding between the two, its best to use Session State Objects for complex objects, and Session Attributes for simple types. 
 
A field holding an SSO is marked with the [SessionState|http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/annotations/SessionState.html] annotation. 
h2. Session State Objects 
 
With a Session State Object (SSO), the value is automatically stored outside the page; with the default storage strategy, it is stored in the session. Such a value is global to all pages _for the same user_, but is stored separately for different users.  A field holding an SSO is marked with the @[SessionState|http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/annotations/SessionState.html] annotation.  
Example:  
...
{   @SessionState 
  private MyState myState; 
  private ShoppingCart shoppingCart; 
   . . . 
...
 {warning} 
DO NOT USE THIS FOR SIMPLE TYPES! Only use @SessionState on variables that are of a custom-built class designed expressly for this purpose!  Read more below. 
DO NOT USE @SessionState FOR SIMPLE TYPES! Only use it on variables that are of a custom-built class designed expressly for this purpose!  *See the Pitfalls section below*. 
{warning}  
With @SessionState, you are creating session-wide data that is not specifically tied to the variable name you used, or even to the class in which that variable was defined. As with all session data, there is the possibility of collisions, not just within your application but with other modules/libraries. 
The first time you access an SSO, it is created automatically. Typically, the SSO will have a public no-args constructor ... but you may inject dependencies into the SSO via its constructor, as you can with a Tapestry IoC service implementation. 
 
{code:title=Example of Collision -- Dont do this!}   @SessionState   private String myState; // Unsafe -- String is not a custom type 
_For Tapestry 4 Users:_ a big change here is that you dont need to provide any configuration for the SSO before using it, nor do you provide a logical name. Tapestry 5 uses the class name to identify the SSO, so theres no need for a logical name. 
 
  @sessionState   private String myOtherState;// This overwrites the myState value, because its also a String! {code} 
Assigning a value to an SSO field will store that value. Assigning null to an SSO field will remove the SSO (reading the field subsequently will force a new SSO instance to be created). 
 
For these reasons, NEVER USE @SessionState FOR SIMPLE-TYPE VARIABLES. It is ALWAYS worth taking the time to build a special class to hold your session state information, because it will force you to consolidate that information into a single, logical unit that cant be accidentally accessed by other classes. 
h2. Pitfalls 

[CONF] Apache Tapestry Persistent State

2011-01-07 Thread confluence







Persistent State
Page  added by Bob Harner

 

 This page has been moved to Session Storage


   
Change Notification Preferences
   
   View Online
   








[CONF] Apache Tapestry Persistent Page Data

2011-01-07 Thread confluence







Persistent Page Data
Page edited by Bob Harner


Comment:
Added simple exmamples for @Persist. Rewording lead paragraphs for clarity.  Wishing the word "persistence" weren't so overloaded.


 Changes (15)
 



...
h1. Persistent Page Data  
Most instance variables in Tapestry are automatically cleared at the end of each request. 
{info}The use of the term persistence here refers to _page-level_ persistence, NOT database persistence.{info} 
 
Most instance variables in Tapestry are automatically cleared at the end of each request. This is important, as it pertains to how Tapestry pages are shared, over time, by many users. 
 
However, you often want to store some persistent data on a _single_ page, and have access to it in later requests. Long term storage of data should go in a database of some form, but server-side state for the duration of the as users interaction with the application should go in the HttpSession (though Tapestry provides a few other options as well). 
However, you often want to store some data on a _single_ page, and have access to it in later requests to that same page, without having to store it in a database between requests.  (To store values across multiple pages, see [Session Storage].) 
 
*Note:* To store values that may be accessed across multiple pages, uses a [session state object|Session Storage]. 
Making page data persist across requests to a single page is accomplished with the @[Persist|http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/annotations/Persist.html] annotation. This annotation is applied to private instance fields of components: 
 
Making a field persistent is accomplished with the [Persist annotation|http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/annotations/Persist.html]. Again, this does _not_ refer to database persistence, it refers to session persistence.  This annotation is applied to private instance fields of components.  
{code:java}   @Persist 
...
{code}  
Annotated Such annotated fields will store retain their state between requests. Generally, speaking, this means that the value is stored into the session (but other approaches are possible). 
 
Whenever you make a change to a persistent field, its value is stored. 
Whenever you make a change to a persistent field, its value is saved. On later requests to the same page, the value for the field is restored. 
 
On later requests, the value for such persistent fields is reloaded from storage.  
h2. Persistence Strategies  
...
Session strategy is the default strategy used unless otherwise overridden.  
{code:title=Example: Session Strategy}   @Persist   private into value; {code}  
h3. Flash Strategy  
...
The flash is typically used to store temporary messages that should only be displayed to the user once.  
{code:title=Example: Flash Strategy}   @Persist(flash)   private into value; {code}  
h3. Client Strategy  
...
Use client persistence with care, and store a minimal amount of data. Try to store the identity (that is, primary key) of an object, rather than the object itself.  
{code:title=Example: Client Strategy}   @Persist(client)   private into value; {code}  
h2. Persistence Strategy Inheritance  
...

Full Content


Related Articles


 
 Session Storage





 
 Persistent Page Data




 

Persistent Page Data

The use of the term "persistence" here refers to page-level persistence, NOT database persistence.

Most instance variables in Tapestry are automatically cleared at the end of each request. This is important, as it pertains to how Tapestry pages are shared, over time, by many users.

However, you often want to store some data on a single page, and have access to it in later requests to that same page, without having to store it in a database between requests.  (To store values across multiple pages, see Session Storage.)

Making page data persist across requests to a single page is accomplished with the @Persist annotation. This annotation is applied to private instance fields of components:



  @Persist