[jira] Commented: (TAP5-1302) tapestry-component-report fails due to doxia dependency error
[ 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
[ 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
[
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
[
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
[
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/
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
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/
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()
[ 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
[ 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
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
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
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
