[jira] Commented: (TAP5-945) Unnecessary and severe lock contention in PerthreadManagerImpl

2009-12-09 Thread Joost Schouten (JIRA)

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

Joost Schouten commented on TAP5-945:
-

I'm not quite sure if it is possible to run Tapestry5 on java 1.4 and if anyone 
does, but looking at the current code the DummyLock will be used with anything 
but java 1.5. Is that what you want? Should it not be; use DummyLock when java 
version  1.5?

 Unnecessary and severe lock contention in PerthreadManagerImpl
 --

 Key: TAP5-945
 URL: https://issues.apache.org/jira/browse/TAP5-945
 Project: Tapestry 5
  Issue Type: Bug
  Components: tapestry-core
Affects Versions: 5.1.0.5
Reporter: Olle Hallin
Assignee: Howard M. Lewis Ship
Priority: Minor
 Fix For: 5.2.0.0


 When load testing our new high-volume site before soft launch, we found that 
 we have severe lock contention in 
 org.apache.tapestry5.ioc.internal.services.PerthreadManagerImpl.
 It synchronizes on this before invoking ThreadLocal.get() and 
 ThreadLocal.remove(), which I believe is unnecessary. 
 During our tests, approximately  35% of all Tomcat threads were waiting for 
 this lock in any of 10 thread dumps taken 15 seconds apart.

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



[jira] Commented: (TAP5-945) Unnecessary and severe lock contention in PerthreadManagerImpl

2009-12-09 Thread Olle Hallin (JIRA)

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

Olle Hallin commented on TAP5-945:
--

T5 requires Java 1.5+


 Unnecessary and severe lock contention in PerthreadManagerImpl
 --

 Key: TAP5-945
 URL: https://issues.apache.org/jira/browse/TAP5-945
 Project: Tapestry 5
  Issue Type: Bug
  Components: tapestry-core
Affects Versions: 5.1.0.5
Reporter: Olle Hallin
Assignee: Howard M. Lewis Ship
Priority: Minor
 Fix For: 5.2.0.0


 When load testing our new high-volume site before soft launch, we found that 
 we have severe lock contention in 
 org.apache.tapestry5.ioc.internal.services.PerthreadManagerImpl.
 It synchronizes on this before invoking ThreadLocal.get() and 
 ThreadLocal.remove(), which I believe is unnecessary. 
 During our tests, approximately  35% of all Tomcat threads were waiting for 
 this lock in any of 10 thread dumps taken 15 seconds apart.

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



[jira] Commented: (TAP5-945) Unnecessary and severe lock contention in PerthreadManagerImpl

2009-12-09 Thread Joost Schouten (JIRA)

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

Joost Schouten commented on TAP5-945:
-

that'll fix it then ;-) thx. Just wondered since the JDK bug was reported 
against 1.4.

 Unnecessary and severe lock contention in PerthreadManagerImpl
 --

 Key: TAP5-945
 URL: https://issues.apache.org/jira/browse/TAP5-945
 Project: Tapestry 5
  Issue Type: Bug
  Components: tapestry-core
Affects Versions: 5.1.0.5
Reporter: Olle Hallin
Assignee: Howard M. Lewis Ship
Priority: Minor
 Fix For: 5.2.0.0


 When load testing our new high-volume site before soft launch, we found that 
 we have severe lock contention in 
 org.apache.tapestry5.ioc.internal.services.PerthreadManagerImpl.
 It synchronizes on this before invoking ThreadLocal.get() and 
 ThreadLocal.remove(), which I believe is unnecessary. 
 During our tests, approximately  35% of all Tomcat threads were waiting for 
 this lock in any of 10 thread dumps taken 15 seconds apart.

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



[jira] Created: (TAP5-946) Unnecessary synchronization in PerThreadOperationTracker

2009-12-09 Thread Olle Hallin (JIRA)
Unnecessary synchronization in PerThreadOperationTracker


 Key: TAP5-946
 URL: https://issues.apache.org/jira/browse/TAP5-946
 Project: Tapestry 5
  Issue Type: Bug
  Components: tapestry-core
Affects Versions: 5.1.0.5
Reporter: Olle Hallin
Priority: Minor


Similar to TAP5-945, there is unneeded synchronization in 
PerThreadOperationTracker around accesses to ThreadLocal.get() and 
ThreadLocal.remove()

It is not needed when running on Java 1.6

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



[jira] Commented: (TAP5-834) BaseOptimizedSessionPersistedObject does not work correctly with Tomcat Jetty

2009-12-09 Thread Andy Blower (JIRA)

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

Andy Blower commented on TAP5-834:
--

It looks to me like you've implemented solution 2 from my bug report above. As 
I said originally, I'm concerned that this will potentially cause hard to find 
concurrency problems which is why I thought the more complicated solution was a 
better option. If there are two threads handling requests for the same user 
session, setting the session attribute to null without synchronisation when one 
request has finished processing while the other is still being handled could 
cause problems, couldn't it?

If you think that this isn't an issue, please could you explain why? Maybe I'm 
missing something in my analysis here?

 BaseOptimizedSessionPersistedObject does not work correctly with Tomcat  
 Jetty
 ---

 Key: TAP5-834
 URL: https://issues.apache.org/jira/browse/TAP5-834
 Project: Tapestry 5
  Issue Type: Bug
  Components: tapestry-core
Affects Versions: 5.1.0.0, 5.1.0.1, 5.1.0.2, 5.1.0.3, 5.1.0.4, 5.1.0.5, 
 5.0.18
Reporter: Andy Blower
Assignee: Howard M. Lewis Ship
Priority: Critical
 Fix For: 5.2.0.0

 Attachments: TAP5-834-patch.txt


 OptimizedSessionPersistedObject's suggestion for implementing 
 isSessionPersistedObjectDirty(), as used by 
 BaseOptimizedSessionPersistedObject, does not work correctly with Tomcat  
 Jetty. (and quite possibly other servlet containers too, but we only use 
 Jetty  Tomcat so have only confirmed it with them)
 OptimizedSessionPersistedObject model relies on the servlet container session 
 object triggering a HttpSessionBindingEvent when an object is re-stored in 
 the session to reset the dirty flag. I've only looked at the source of Tomcat 
 5.5 and 6 but when an object is replaced in the session using setAttribute() 
 the new object and the existing object are compared by reference only, if 
 they both refer to the same object then no HttpSessionBindingEvent is 
 triggered.
 From Tomcat StandardSession.java:
 // Call the valueBound() method if necessary
 if (notify  value instanceof HttpSessionBindingListener) {
 // Don't call any notification if replacing with the same value
 Object oldValue = attributes.get(name);
 if (value != oldValue) {
 event = new HttpSessionBindingEvent(getSession(), name, 
 value);
 try {
 ((HttpSessionBindingListener) value).valueBound(event);
 } catch (Throwable t){
 manager.getContainer().getLogger().error
 (sm.getString(standardSession.bindingEvent), t); 
 }
 }
 }
 So, using OptimizedSessionPersistedObject, there is currently no way of 
 setting the dirty flag to false after the object has been saved in the 
 session - hence we are propagating all of the SSOs across the cluster all of 
 the time because the dirty flag stays set to true.
 I think there are two possible solutions to this issue - I prefer the first 
 by a large margin, but both modify the SessionImpl.restoreDirtyObjects() 
 method.
 1) Add a new method to OptimizedSessionPersistedObject interface to reset the 
 dirty flag, and a corresponding method in SessionPersistedObjectAnalyzer - 
 implementing them as appropriate, then call the new reset method after 
 setting the session attribute in SessionImpl.restoreDirtyObjects().
 2) Remove the session attribute before adding it in 
 SessionImpl.restoreDirtyObjects(). Although I have a worry that this may 
 potentially cause hard to find concurrency problems.

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



[jira] Created: (TAP5-947) Default name submit for submit component breaks javascript function submit()

2009-12-09 Thread Inge Solvoll (JIRA)
Default name submit for submit component breaks javascript function submit()
--

 Key: TAP5-947
 URL: https://issues.apache.org/jira/browse/TAP5-947
 Project: Tapestry 5
  Issue Type: Bug
  Components: tapestry-core
Affects Versions: 5.1.0.5
Reporter: Inge Solvoll


When using submit component without specifying a name or id, the component is 
given the name submit. This causes javascript error if a script later tries 
to invoke form.submit(), because the submit button has hijacked the submit 
function's name.

A developer can easily stumble into this problem himself by naturally naming 
his button submit, but tapestry shouldn't make the worst possible name the 
default one. Change the name/id to submitButton or something similar.

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



svn commit: r888898 - /tapestry/tapestry5/trunk/tapestry-core/src/main/java/org/apache/tapestry5/internal/services/SessionImpl.java

2009-12-09 Thread hlship
Author: hlship
Date: Wed Dec  9 18:07:00 2009
New Revision: 98

URL: http://svn.apache.org/viewvc?rev=98view=rev
Log:
TAP5-834: BaseOptimizedSessionPersistedObject does not work correctly with 
Tomcat  Jetty

Modified:

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

Modified: 
tapestry/tapestry5/trunk/tapestry-core/src/main/java/org/apache/tapestry5/internal/services/SessionImpl.java
URL: 
http://svn.apache.org/viewvc/tapestry/tapestry5/trunk/tapestry-core/src/main/java/org/apache/tapestry5/internal/services/SessionImpl.java?rev=98r1=97r2=98view=diff
==
--- 
tapestry/tapestry5/trunk/tapestry-core/src/main/java/org/apache/tapestry5/internal/services/SessionImpl.java
 (original)
+++ 
tapestry/tapestry5/trunk/tapestry-core/src/main/java/org/apache/tapestry5/internal/services/SessionImpl.java
 Wed Dec  9 18:07:00 2009
@@ -127,7 +127,7 @@
 
 if (analyzer.isDirty(attributeValue))
 {
-// TAP5-384: Jetty  Tomcat work by object identity, will not 
update the attribute
+// TAP5-834: Jetty  Tomcat work by object identity, will not 
update the attribute
 // and fire the session binding event unless there's a real 
change. So we set the
 // attribute to null and then to the new value and that should 
force the necessary
 // notification.




[jira] Commented: (TAP5-817) When sending muliple page requests very fast (using browser refresh button or pressing a link), for the first time a page is loaded, cause Tapestry to crash and become unr

2009-12-09 Thread Howard M. Lewis Ship (JIRA)

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

Howard M. Lewis Ship commented on TAP5-817:
---

Any further updates on this?  Does it still occur?

 When sending muliple page requests very fast (using browser refresh button or 
 pressing a link), for the first time a page is loaded, cause Tapestry to 
 crash and become unresponsive.
 -

 Key: TAP5-817
 URL: https://issues.apache.org/jira/browse/TAP5-817
 Project: Tapestry 5
  Issue Type: Bug
  Components: tapestry-core
Affects Versions: 5.1.0.5
Reporter: Mario Luis Gomes Cavalcanti
Priority: Blocker

 When sending muliple page requests very fast (using browser refresh button or 
 pressing a link), for the first time a page is loaded, cause Tapestry to 
 crash and become unresponsive.
 Steps to reproduce:
 1: Have a very simple page containing just some text or a slow loading page 
 to make it easier to reproduce.
 2: Restart the web server so there are no pages in the memory.
 3: Send multiple requests for the page, very fast using the refresh button or 
 pressing a link multiple times.
 Result = Tapestry never returns the page and becomes unresponsive.
 The bug is happening to all the pages on my website, but only if the page has 
 not been previoulsy loaded, e.q, the page is not already in memory.
 For simple fast loading pages, you have to press the link/refresh button very 
 fast and many, many times. For slower loading pages it is easier to reproduce 
 the bug.
 I am running tapestry 5.10.5 on a Sun Web Server 7 on Windows XP.
 This is a very serious bug!!! I cant go to production with this bug.

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



[jira] Updated: (TAP5-836) URLEventContext is not Serializable - prevents Tapestry use in a Cluster

2009-12-09 Thread Howard M. Lewis Ship (JIRA)

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

Howard M. Lewis Ship updated TAP5-836:
--

Component/s: tapestry-core
   Priority: Major  (was: Critical)

Downgrading this as it is probably user error (rather than an explicit bug in 
the framework).

 URLEventContext is not Serializable - prevents Tapestry use in a Cluster
 

 Key: TAP5-836
 URL: https://issues.apache.org/jira/browse/TAP5-836
 Project: Tapestry 5
  Issue Type: Bug
  Components: tapestry-core
 Environment: CentOS 5.3, Java 1.6.0_14-b08, Tomcat 5.5.27
Reporter: David Rees

 I have a Tapestry application which I am trying to use in a Tomcat cluster.
 Tomcat uses Object Input/Output Streams to replicate session data, which 
 requires that all objects added to a Session implement Serializable.
 In Tapestry 5.0.18 (and all later versions from what I can tell from browsing 
 source), org.apache.tapestry5.internal.URLEventContext does not implement 
 Serializable which prevents us from using Tapestry in a cluster.
 Unfortunately, this means that when we have to deploy a new version of our 
 application, we have to forcibly log everyone out disrupting service.

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



[jira] Commented: (TAP5-836) URLEventContext is not Serializable - prevents Tapestry use in a Cluster

2009-12-09 Thread Howard M. Lewis Ship (JIRA)

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

Howard M. Lewis Ship commented on TAP5-836:
---

I can't think of any place in Tapestry's code where an EventContext would be 
stored in the session.

However, it is not an uncommon pattern to intercept requests for pages that 
require non-anonymous access, redirect through a login page and process, and 
then continue back to the original request.  That's the most likely culprit.

I've implemented this pattern myself, and just extracted the URL context values 
as strings to store them (inside another object) inside the session.

 URLEventContext is not Serializable - prevents Tapestry use in a Cluster
 

 Key: TAP5-836
 URL: https://issues.apache.org/jira/browse/TAP5-836
 Project: Tapestry 5
  Issue Type: Bug
  Components: tapestry-core
 Environment: CentOS 5.3, Java 1.6.0_14-b08, Tomcat 5.5.27
Reporter: David Rees
Priority: Critical

 I have a Tapestry application which I am trying to use in a Tomcat cluster.
 Tomcat uses Object Input/Output Streams to replicate session data, which 
 requires that all objects added to a Session implement Serializable.
 In Tapestry 5.0.18 (and all later versions from what I can tell from browsing 
 source), org.apache.tapestry5.internal.URLEventContext does not implement 
 Serializable which prevents us from using Tapestry in a cluster.
 Unfortunately, this means that when we have to deploy a new version of our 
 application, we have to forcibly log everyone out disrupting service.

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



[jira] Assigned: (TAP5-747) Property expression results in spurious error about root

2009-12-09 Thread Howard M. Lewis Ship (JIRA)

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

Howard M. Lewis Ship reassigned TAP5-747:
-

Assignee: Howard M. Lewis Ship

 Property expression results in spurious error about root
 --

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

 It's a complex expresssion, with a method invocation, but it should work.  
 propertyName is part of my page.  Don't know what root is about! Probably 
 an error related to generating a method invocation.
 # org.apache.tapestry5.ioc.internal.util.TapestryException
 Could not convert 'context.itemModel.get(propertyName).label' into a 
 component parameter binding: Unable to add method 
 org.apache.tapestry5.beaneditor.PropertyModel 
 navigate(widen.collective.blocks.pages.LCGridView) to class 
 $PropertyConduit_121d07fa7a4: [source error] no such class: root
 location
 classpath:widen/collective/blocks/pages/LCGridView.tml, line 12
 7 div
 8 t:loop source=context.listedItems value=item
 9 
 10div style={ float: left; border: 2px solid blue; }
 11
 12t:loop source=context.itemModel.propertyNames 
 value=propertyName
 13${context.itemModel.get(propertyName).label}:
 14t:propertydisplay
 15model=context.itemModel.get(propertyName) object=item /
 16/t:loop
 17/div
 # javassist.CannotCompileException
 [source error] no such class: root
 reason
 [source error] no such class: root
 # javassist.compiler.CompileError
 no such class: root
 Hide uninteresting stack frames Stack trace
 * 
 javassist.compiler.MemberResolver.searchImports(MemberResolver.java:436)
 * 
 javassist.compiler.MemberResolver.lookupClass(MemberResolver.java:412)
 * 
 javassist.compiler.MemberResolver.lookupClassByJvmName(MemberResolver.java:330)
 * javassist.compiler.TypeChecker.atCallExpr(TypeChecker.java:671)
 * 
 javassist.compiler.JvstTypeChecker.atCallExpr(JvstTypeChecker.java:156)
 * javassist.compiler.ast.CallExpr.accept(CallExpr.java:45)
 * javassist.compiler.CodeGen.doTypeCheck(CodeGen.java:241)
 * javassist.compiler.CodeGen.atDeclarator(CodeGen.java:725)
 * javassist.compiler.ast.Declarator.accept(Declarator.java:99)
 * javassist.compiler.CodeGen.atStmnt(CodeGen.java:350)
 * javassist.compiler.ast.Stmnt.accept(Stmnt.java:49)
 * javassist.compiler.CodeGen.atStmnt(CodeGen.java:350)
 * javassist.compiler.ast.Stmnt.accept(Stmnt.java:49)
 * javassist.compiler.CodeGen.atMethodBody(CodeGen.java:291)
 * javassist.compiler.Javac.compileBody(Javac.java:222)
 * javassist.CtBehavior.setBody(CtBehavior.java:360)
 * javassist.CtBehavior.setBody(CtBehavior.java:334)
 * 
 org.apache.tapestry5.ioc.internal.services.ClassFabImpl.addMethod(ClassFabImpl.java:209)
 * 
 org.apache.tapestry5.internal.services.PropertyConduitSourceImpl$PropertyConduitBuilder.createAccessors(PropertyConduitSourceImpl.java:405)
 * 
 org.apache.tapestry5.internal.services.PropertyConduitSourceImpl$PropertyConduitBuilder.createInstance(PropertyConduitSourceImpl.java:260)
 * 
 org.apache.tapestry5.internal.services.PropertyConduitSourceImpl.build(PropertyConduitSourceImpl.java:1205)
 * 
 org.apache.tapestry5.internal.services.PropertyConduitSourceImpl.create(PropertyConduitSourceImpl.java:1080)
 * 
 $PropertyConduitSource_121d07fa650.create($PropertyConduitSource_121d07fa650.java)
 * 
 org.apache.tapestry5.internal.bindings.PropBindingFactory.newBinding(PropBindingFactory.java:49)
  

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



[jira] Created: (TAP5-948) Built-in mechanism to identify self-referential links and/or event/render requests

2009-12-09 Thread Kalle Korhonen (JIRA)
Built-in mechanism to identify self-referential links and/or event/render 
requests
--

 Key: TAP5-948
 URL: https://issues.apache.org/jira/browse/TAP5-948
 Project: Tapestry 5
  Issue Type: Improvement
  Components: tapestry-core
Affects Versions: 5.0.18, 5.0.17, 5.0.16, 5.0.15, 5.1.0.5, 5.1.0.4, 
5.1.0.3, 5.1.0.2, 5.1.0.1, 5.1.0.0
Reporter: Kalle Korhonen


Discussed on Tapestry user thread: 
http://old.nabble.com/Best-practice-for-initializing-page-to-default-context-td26689270.html
One of the cases where the issue manifests itself is that it's more difficult 
to initialize a page to default context than it needs to (and redirect to it) 
since event requests always cause a parameterless onActivate() to be invoked as 
well and there's no (framework-level) support for identifying event and render 
requests. There are many other uses for being able to easily identify links 
referring back to the same page.

Howard says:
I've had to solve this problem for one of my clients as well and I think it's 
something that should go into the framework.  The approach
I took was to identify self-referential links (page render links that are to 
the same page they originate from) using an additional query
parameter. This allows Tapestry to differentiate between requests that start on 
a new page vs. those that continue on the page. Tapestry can
then fire a notification on components to perform initialization (on page 
render requests without the query parameter).

This would be a new lifecycle method, like pageAttached() or pageLoaded().  I'm 
still working on the right terminology, for Widen it is initialized, as in 
method pageInitialized().

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



[jira] Closed: (TAP5-817) When sending muliple page requests very fast (using browser refresh button or pressing a link), for the first time a page is loaded, cause Tapestry to crash and become unresp

2009-12-09 Thread Mario Luis Gomes Cavalcanti (JIRA)

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

Mario Luis Gomes Cavalcanti closed TAP5-817.


Resolution: Not A Problem

This is a bug on Sun Webserver 7 on the Windows platform.

 When sending muliple page requests very fast (using browser refresh button or 
 pressing a link), for the first time a page is loaded, cause Tapestry to 
 crash and become unresponsive.
 -

 Key: TAP5-817
 URL: https://issues.apache.org/jira/browse/TAP5-817
 Project: Tapestry 5
  Issue Type: Bug
  Components: tapestry-core
Affects Versions: 5.1.0.5
Reporter: Mario Luis Gomes Cavalcanti
Priority: Blocker

 When sending muliple page requests very fast (using browser refresh button or 
 pressing a link), for the first time a page is loaded, cause Tapestry to 
 crash and become unresponsive.
 Steps to reproduce:
 1: Have a very simple page containing just some text or a slow loading page 
 to make it easier to reproduce.
 2: Restart the web server so there are no pages in the memory.
 3: Send multiple requests for the page, very fast using the refresh button or 
 pressing a link multiple times.
 Result = Tapestry never returns the page and becomes unresponsive.
 The bug is happening to all the pages on my website, but only if the page has 
 not been previoulsy loaded, e.q, the page is not already in memory.
 For simple fast loading pages, you have to press the link/refresh button very 
 fast and many, many times. For slower loading pages it is easier to reproduce 
 the bug.
 I am running tapestry 5.10.5 on a Sun Web Server 7 on Windows XP.
 This is a very serious bug!!! I cant go to production with this bug.

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



[jira] Commented: (TAP5-817) When sending muliple page requests very fast (using browser refresh button or pressing a link), for the first time a page is loaded, cause Tapestry to crash and become unr

2009-12-09 Thread Howard M. Lewis Ship (JIRA)

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

Howard M. Lewis Ship commented on TAP5-817:
---

It's a relief to know that it's not specifically a Tapestry bug; however if 
there's something Tapestry can do differently to make it work out-of-the-box on 
this platform (without breaking things for other platforms) I'm open to it as 
an improvement.  Thanks for checking up on this.

 When sending muliple page requests very fast (using browser refresh button or 
 pressing a link), for the first time a page is loaded, cause Tapestry to 
 crash and become unresponsive.
 -

 Key: TAP5-817
 URL: https://issues.apache.org/jira/browse/TAP5-817
 Project: Tapestry 5
  Issue Type: Bug
  Components: tapestry-core
Affects Versions: 5.1.0.5
Reporter: Mario Luis Gomes Cavalcanti
Priority: Blocker

 When sending muliple page requests very fast (using browser refresh button or 
 pressing a link), for the first time a page is loaded, cause Tapestry to 
 crash and become unresponsive.
 Steps to reproduce:
 1: Have a very simple page containing just some text or a slow loading page 
 to make it easier to reproduce.
 2: Restart the web server so there are no pages in the memory.
 3: Send multiple requests for the page, very fast using the refresh button or 
 pressing a link multiple times.
 Result = Tapestry never returns the page and becomes unresponsive.
 The bug is happening to all the pages on my website, but only if the page has 
 not been previoulsy loaded, e.q, the page is not already in memory.
 For simple fast loading pages, you have to press the link/refresh button very 
 fast and many, many times. For slower loading pages it is easier to reproduce 
 the bug.
 I am running tapestry 5.10.5 on a Sun Web Server 7 on Windows XP.
 This is a very serious bug!!! I cant go to production with this bug.

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



[jira] Updated: (TAP5-747) Property expressions that include method invocations that in turn reference properties result in spurious error about root

2009-12-09 Thread Howard M. Lewis Ship (JIRA)

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

Howard M. Lewis Ship updated TAP5-747:
--

Summary: Property expressions that include method invocations that in turn 
reference properties result in spurious error about root  (was: Property 
expression results in spurious error about root)

 Property expressions that include method invocations that in turn reference 
 properties result in spurious error about root
 

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

 It's a complex expresssion, with a method invocation, but it should work.  
 propertyName is part of my page.  Don't know what root is about! Probably 
 an error related to generating a method invocation.
 # org.apache.tapestry5.ioc.internal.util.TapestryException
 Could not convert 'context.itemModel.get(propertyName).label' into a 
 component parameter binding: Unable to add method 
 org.apache.tapestry5.beaneditor.PropertyModel 
 navigate(widen.collective.blocks.pages.LCGridView) to class 
 $PropertyConduit_121d07fa7a4: [source error] no such class: root
 location
 classpath:widen/collective/blocks/pages/LCGridView.tml, line 12
 7 div
 8 t:loop source=context.listedItems value=item
 9 
 10div style={ float: left; border: 2px solid blue; }
 11
 12t:loop source=context.itemModel.propertyNames 
 value=propertyName
 13${context.itemModel.get(propertyName).label}:
 14t:propertydisplay
 15model=context.itemModel.get(propertyName) object=item /
 16/t:loop
 17/div
 # javassist.CannotCompileException
 [source error] no such class: root
 reason
 [source error] no such class: root
 # javassist.compiler.CompileError
 no such class: root
 Hide uninteresting stack frames Stack trace
 * 
 javassist.compiler.MemberResolver.searchImports(MemberResolver.java:436)
 * 
 javassist.compiler.MemberResolver.lookupClass(MemberResolver.java:412)
 * 
 javassist.compiler.MemberResolver.lookupClassByJvmName(MemberResolver.java:330)
 * javassist.compiler.TypeChecker.atCallExpr(TypeChecker.java:671)
 * 
 javassist.compiler.JvstTypeChecker.atCallExpr(JvstTypeChecker.java:156)
 * javassist.compiler.ast.CallExpr.accept(CallExpr.java:45)
 * javassist.compiler.CodeGen.doTypeCheck(CodeGen.java:241)
 * javassist.compiler.CodeGen.atDeclarator(CodeGen.java:725)
 * javassist.compiler.ast.Declarator.accept(Declarator.java:99)
 * javassist.compiler.CodeGen.atStmnt(CodeGen.java:350)
 * javassist.compiler.ast.Stmnt.accept(Stmnt.java:49)
 * javassist.compiler.CodeGen.atStmnt(CodeGen.java:350)
 * javassist.compiler.ast.Stmnt.accept(Stmnt.java:49)
 * javassist.compiler.CodeGen.atMethodBody(CodeGen.java:291)
 * javassist.compiler.Javac.compileBody(Javac.java:222)
 * javassist.CtBehavior.setBody(CtBehavior.java:360)
 * javassist.CtBehavior.setBody(CtBehavior.java:334)
 * 
 org.apache.tapestry5.ioc.internal.services.ClassFabImpl.addMethod(ClassFabImpl.java:209)
 * 
 org.apache.tapestry5.internal.services.PropertyConduitSourceImpl$PropertyConduitBuilder.createAccessors(PropertyConduitSourceImpl.java:405)
 * 
 org.apache.tapestry5.internal.services.PropertyConduitSourceImpl$PropertyConduitBuilder.createInstance(PropertyConduitSourceImpl.java:260)
 * 
 org.apache.tapestry5.internal.services.PropertyConduitSourceImpl.build(PropertyConduitSourceImpl.java:1205)
 * 
 org.apache.tapestry5.internal.services.PropertyConduitSourceImpl.create(PropertyConduitSourceImpl.java:1080)
 * 
 $PropertyConduitSource_121d07fa650.create($PropertyConduitSource_121d07fa650.java)
 * 
 org.apache.tapestry5.internal.bindings.PropBindingFactory.newBinding(PropBindingFactory.java:49)
  

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



svn commit: r888935 - in /tapestry/tapestry5/trunk/tapestry-core/src: main/java/org/apache/tapestry5/internal/services/ test/java/org/apache/tapestry5/internal/services/

2009-12-09 Thread hlship
Author: hlship
Date: Wed Dec  9 19:38:46 2009
New Revision: 888935

URL: http://svn.apache.org/viewvc?rev=888935view=rev
Log:
TAP5-747: Property expressions that include method invocations that in turn 
reference properties result in spurious error about root

Added:

tapestry/tapestry5/trunk/tapestry-core/src/test/java/org/apache/tapestry5/internal/services/ComplexObject.java
   (with props)

tapestry/tapestry5/trunk/tapestry-core/src/test/java/org/apache/tapestry5/internal/services/NestedObject.java
   (with props)
Modified:

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

tapestry/tapestry5/trunk/tapestry-core/src/test/java/org/apache/tapestry5/internal/services/PropertyConduitSourceImplTest.java

Modified: 
tapestry/tapestry5/trunk/tapestry-core/src/main/java/org/apache/tapestry5/internal/services/PropertyConduitSourceImpl.java
URL: 
http://svn.apache.org/viewvc/tapestry/tapestry5/trunk/tapestry-core/src/main/java/org/apache/tapestry5/internal/services/PropertyConduitSourceImpl.java?rev=888935r1=888934r2=888935view=diff
==
--- 
tapestry/tapestry5/trunk/tapestry-core/src/main/java/org/apache/tapestry5/internal/services/PropertyConduitSourceImpl.java
 (original)
+++ 
tapestry/tapestry5/trunk/tapestry-core/src/main/java/org/apache/tapestry5/internal/services/PropertyConduitSourceImpl.java
 Wed Dec  9 19:38:46 2009
@@ -48,11 +48,12 @@
 public class PropertyConduitSourceImpl implements PropertyConduitSource, 
InvalidationListener
 {
 private static final MethodSignature GET_SIGNATURE = new 
MethodSignature(Object.class, get,
- 
new Class[] { Object.class }, null);
+new Class[]
+{ Object.class }, null);
 
 private static final MethodSignature SET_SIGNATURE = new 
MethodSignature(void.class, set,
- 
new Class[] { Object.class, Object.class },
- 
null);
+new Class[]
+{ Object.class, Object.class }, null);
 
 private static final Method RANGE;
 
@@ -105,7 +106,8 @@
 }
 
 /**
- * Describes all the gory details of one term (one property or method 
invocation) from within the expression.
+ * Describes all the gory details of one term (one property or method
+ * invocation) from within the expression.
  */
 private interface ExpressionTermInfo extends AnnotationProvider
 {
@@ -116,7 +118,8 @@
 Method getReadMethod();
 
 /**
- * The method to invoke to write the property value, or null. Always 
null for method terms (which are inherently
+ * The method to invoke to write the property value, or null. Always
+ * null for method terms (which are inherently
  * read-only).
  */
 Method getWriteMethod();
@@ -127,12 +130,14 @@
 Class getType();
 
 /**
- * True if an explicit cast to the return type is needed (typically 
because of generics).
+ * True if an explicit cast to the return type is needed (typically
+ * because of generics).
  */
 boolean isCastRequired();
 
 /**
- * Returns a user-presentable name identifying the property or method 
name.
+ * Returns a user-presentable name identifying the property or method
+ * name.
  */
 String getDescription();
 }
@@ -148,7 +153,8 @@
 FORBID,
 
 /**
- * Add code to check for null and short-circuit (i.e., the ?. 
safe-dereference operator)
+ * Add code to check for null and short-circuit (i.e., the ?.
+ * safe-dereference operator)
  */
 ALLOW,
 
@@ -165,8 +171,10 @@
 final String termReference;
 
 /**
- * @param type  type of variable
- * @param termReference name of variable, or a constant value
+ * @param type
+ *type of variable
+ * @param termReference
+ *name of variable, or a constant value
  */
 private GeneratedTerm(Class type, String termReference)
 {
@@ -184,7 +192,8 @@
 private final StringInterner interner;
 
 /**
- * Because of stuff like Hibernate, we sometimes start with a subclass in 
some inaccessible class loader and need to
+ * Because of stuff like Hibernate, we sometimes start with a subclass in
+ * some inaccessible class loader and need to
  * work up to a base class from a common class loader.
  */
 private final MapClass, Class classToEffectiveClass = 
CollectionFactory.newConcurrentMap();
@@ -219,9 +228,9 @@
 
 private final PropertyConduit literalNull;
 
-
 /**
- * Encapsulates the 

[jira] Closed: (TAP5-747) Property expressions that include method invocations that in turn reference properties result in spurious error about root

2009-12-09 Thread Howard M. Lewis Ship (JIRA)

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

Howard M. Lewis Ship closed TAP5-747.
-

   Resolution: Fixed
Fix Version/s: 5.2.0.0

 Property expressions that include method invocations that in turn reference 
 properties result in spurious error about root
 

 Key: TAP5-747
 URL: https://issues.apache.org/jira/browse/TAP5-747
 Project: Tapestry 5
  Issue Type: Bug
  Components: tapestry-core
Affects Versions: 5.1.0.5
Reporter: Howard M. Lewis Ship
Assignee: Howard M. Lewis Ship
Priority: Critical
 Fix For: 5.2.0.0


 It's a complex expresssion, with a method invocation, but it should work.  
 propertyName is part of my page.  Don't know what root is about! Probably 
 an error related to generating a method invocation.
 # org.apache.tapestry5.ioc.internal.util.TapestryException
 Could not convert 'context.itemModel.get(propertyName).label' into a 
 component parameter binding: Unable to add method 
 org.apache.tapestry5.beaneditor.PropertyModel 
 navigate(widen.collective.blocks.pages.LCGridView) to class 
 $PropertyConduit_121d07fa7a4: [source error] no such class: root
 location
 classpath:widen/collective/blocks/pages/LCGridView.tml, line 12
 7 div
 8 t:loop source=context.listedItems value=item
 9 
 10div style={ float: left; border: 2px solid blue; }
 11
 12t:loop source=context.itemModel.propertyNames 
 value=propertyName
 13${context.itemModel.get(propertyName).label}:
 14t:propertydisplay
 15model=context.itemModel.get(propertyName) object=item /
 16/t:loop
 17/div
 # javassist.CannotCompileException
 [source error] no such class: root
 reason
 [source error] no such class: root
 # javassist.compiler.CompileError
 no such class: root
 Hide uninteresting stack frames Stack trace
 * 
 javassist.compiler.MemberResolver.searchImports(MemberResolver.java:436)
 * 
 javassist.compiler.MemberResolver.lookupClass(MemberResolver.java:412)
 * 
 javassist.compiler.MemberResolver.lookupClassByJvmName(MemberResolver.java:330)
 * javassist.compiler.TypeChecker.atCallExpr(TypeChecker.java:671)
 * 
 javassist.compiler.JvstTypeChecker.atCallExpr(JvstTypeChecker.java:156)
 * javassist.compiler.ast.CallExpr.accept(CallExpr.java:45)
 * javassist.compiler.CodeGen.doTypeCheck(CodeGen.java:241)
 * javassist.compiler.CodeGen.atDeclarator(CodeGen.java:725)
 * javassist.compiler.ast.Declarator.accept(Declarator.java:99)
 * javassist.compiler.CodeGen.atStmnt(CodeGen.java:350)
 * javassist.compiler.ast.Stmnt.accept(Stmnt.java:49)
 * javassist.compiler.CodeGen.atStmnt(CodeGen.java:350)
 * javassist.compiler.ast.Stmnt.accept(Stmnt.java:49)
 * javassist.compiler.CodeGen.atMethodBody(CodeGen.java:291)
 * javassist.compiler.Javac.compileBody(Javac.java:222)
 * javassist.CtBehavior.setBody(CtBehavior.java:360)
 * javassist.CtBehavior.setBody(CtBehavior.java:334)
 * 
 org.apache.tapestry5.ioc.internal.services.ClassFabImpl.addMethod(ClassFabImpl.java:209)
 * 
 org.apache.tapestry5.internal.services.PropertyConduitSourceImpl$PropertyConduitBuilder.createAccessors(PropertyConduitSourceImpl.java:405)
 * 
 org.apache.tapestry5.internal.services.PropertyConduitSourceImpl$PropertyConduitBuilder.createInstance(PropertyConduitSourceImpl.java:260)
 * 
 org.apache.tapestry5.internal.services.PropertyConduitSourceImpl.build(PropertyConduitSourceImpl.java:1205)
 * 
 org.apache.tapestry5.internal.services.PropertyConduitSourceImpl.create(PropertyConduitSourceImpl.java:1080)
 * 
 $PropertyConduitSource_121d07fa650.create($PropertyConduitSource_121d07fa650.java)
 * 
 org.apache.tapestry5.internal.bindings.PropBindingFactory.newBinding(PropBindingFactory.java:49)
  

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



[jira] Closed: (TAP5-946) Unnecessary synchronization in PerThreadOperationTracker

2009-12-09 Thread Howard M. Lewis Ship (JIRA)

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

Howard M. Lewis Ship closed TAP5-946.
-

Resolution: Duplicate
  Assignee: Howard M. Lewis Ship

Fixed as TAP5-945.

 Unnecessary synchronization in PerThreadOperationTracker
 

 Key: TAP5-946
 URL: https://issues.apache.org/jira/browse/TAP5-946
 Project: Tapestry 5
  Issue Type: Bug
  Components: tapestry-core
Affects Versions: 5.1.0.5
Reporter: Olle Hallin
Assignee: Howard M. Lewis Ship
Priority: Minor

 Similar to TAP5-945, there is unneeded synchronization in 
 PerThreadOperationTracker around accesses to ThreadLocal.get() and 
 ThreadLocal.remove()
 It is not needed when running on Java 1.6

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



[jira] Closed: (TAP5-833) Component event-handler name cannot include the word From

2009-12-09 Thread Howard M. Lewis Ship (JIRA)

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

Howard M. Lewis Ship closed TAP5-833.
-

Resolution: Won't Fix
  Assignee: Howard M. Lewis Ship

This is a side-effect of the naming convention. If you don't like it, use the 
@OnEvent annotation, which removes the ambiguity about whether from is a 
seperator between the event name and the component id or (in your case) part of 
the event name.

 Component event-handler name cannot include the word From
 ---

 Key: TAP5-833
 URL: https://issues.apache.org/jira/browse/TAP5-833
 Project: Tapestry 5
  Issue Type: Bug
  Components: tapestry-core
Affects Versions: 5.1.0.5
Reporter: Franz Amador
Assignee: Howard M. Lewis Ship
Priority: Minor

 If a component event-handler method name includes the word From, Tapestry 
 throws an exception:
 org.apache.tapestry5.ioc.internal.util.TapestryException: Request event 
 'foofrombar' (on component 
 project/DocumentHolderDocuments:documentsgridactionsbutton) was not handled; 
 you must provide a matching event handler method in the component or in one 
 of its containers.
 The method is being invoked via an AJAX call to this URL:
 resources.createEventLink(fooFromBar).toAbsoluteURI();
 And the handler looks like this:
 public Object onFooFromBar() { ... }
 If I remove the word From, it works fine.  If I change it to Form, it 
 works fine.

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



[jira] Commented: (TAP5-737) Parameter translate of TextField is specified as required, but it's realy not required

2009-12-09 Thread Howard M. Lewis Ship (JIRA)

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

Howard M. Lewis Ship commented on TAP5-737:
---

The parameter really is required, however in nearly all cases, Tapestry is able 
to provide a default value.

 Parameter translate of TextField is specified as required, but it's realy 
 not required
 

 Key: TAP5-737
 URL: https://issues.apache.org/jira/browse/TAP5-737
 Project: Tapestry 5
  Issue Type: Bug
  Components: tapestry-core
Affects Versions: 5.1.0.5
Reporter: Lukasz Jazgar
Priority: Minor

 Components TextField, TextArea and PasswordField have parameter translate, 
 which is specified by annotation and in documentation as required.
 This parameter should not be required and it isn't really. 
 Even in examples of using TextField parameter translate is not used 
 (http://tapestry.apache.org/tapestry5.1/tapestry-core/ref/org/apache/tapestry5/corelib/components/TextField.html).
 Specification in documentation, specification in annotations,  examples and 
 real behaviour should be consistent.

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



[jira] Commented: (TAP5-726) Grid should determine the class row type from a field when there is no BeanModel and GridDataSource

2009-12-09 Thread Howard M. Lewis Ship (JIRA)

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

Howard M. Lewis Ship commented on TAP5-726:
---

The correct solution here is to provide the model explicitly (there's a 
parameter for that).


 Grid should determine the class row type from a field when there is no 
 BeanModel and GridDataSource
 ---

 Key: TAP5-726
 URL: https://issues.apache.org/jira/browse/TAP5-726
 Project: Tapestry 5
  Issue Type: Bug
  Components: tapestry-core
Affects Versions: 5.1.0.5
Reporter: Denis Stepanov
Priority: Minor

 CollectionGridDataSource uses first collection item to determine the class 
 type, but in situation when collection contains different hierarchy 
 implementation there is a ClassCastException

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



[jira] Commented: (TAP5-21) Misleading error message when a component sub-class invokes non-default constructor of parent component class

2009-12-09 Thread Howard M. Lewis Ship (JIRA)

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

Howard M. Lewis Ship commented on TAP5-21:
--

I think that we need to update the documentation to say no constructors 
(beyond default empty constructor) and enforce that up front  with a reasonable 
exception message.

 Misleading error message when a component sub-class invokes non-default 
 constructor of parent component class
 -

 Key: TAP5-21
 URL: https://issues.apache.org/jira/browse/TAP5-21
 Project: Tapestry 5
  Issue Type: Bug
Affects Versions: 5.0.15
 Environment: Linux, Sun JDK 1.6
Reporter: Jens Pfau
Priority: Minor

 Some of my pages inherit from a common abstract base class but even if I move 
 this to root package.base, I receive the following application exception:
 Caused by: java.lang.RuntimeException: java.lang.ClassNotFoundException: 
 caught an exception while obtaining a class file for root 
 package.pages.MyPage
   at 
 org.apache.tapestry.internal.services.ComponentInstantiatorSourceImpl.findClass(ComponentInstantiatorSourceImpl.java:241)
   at 
 org.apache.tapestry.internal.services.ComponentInstantiatorSourceImpl.findInstantiator(ComponentInstantiatorSourceImpl.java:223)
   at 
 $ComponentInstantiatorSource_118ac384906.findInstantiator($ComponentInstantiatorSource_118ac384906.java)
   at 
 org.apache.tapestry.internal.services.PageElementFactoryImpl.newRootComponentElement(PageElementFactoryImpl.java:257)
   at 
 $PageElementFactory_118ac384934.newRootComponentElement($PageElementFactory_118ac384934.java)
   at 
 org.apache.tapestry.internal.services.PageLoaderProcessor.loadRootComponent(PageLoaderProcessor.java:413)
   at 
 org.apache.tapestry.internal.services.PageLoaderProcessor.loadPage(PageLoaderProcessor.java:391)
   at 
 org.apache.tapestry.internal.services.PageLoaderImpl.loadPage(PageLoaderImpl.java:60)
   at $PageLoader_118ac384932.loadPage($PageLoader_118ac384932.java)
   at 
 org.apache.tapestry.internal.services.PagePoolCache.checkout(PagePoolCache.java:188)
   at 
 org.apache.tapestry.internal.services.PagePoolImpl.checkout(PagePoolImpl.java:107)
   at $PagePool_118ac384931.checkout($PagePool_118ac384931.java)
   at 
 org.apache.tapestry.internal.services.RequestPageCacheImpl.get(RequestPageCacheImpl.java:43)
   at $RequestPageCache_118ac384930.get($RequestPageCache_118ac384930.java)
   at $RequestPageCache_118ac384903.get($RequestPageCache_118ac384903.java)
   at 
 org.apache.tapestry.internal.services.LinkFactoryImpl.createPageLink(LinkFactoryImpl.java:239)
   at 
 $LinkFactory_118ac384935.createPageLink($LinkFactory_118ac384935.java)
   at 
 org.apache.tapestry.internal.structure.PageImpl.createPageLink(PageImpl.java:161)
   at 
 org.apache.tapestry.internal.structure.InternalComponentResourcesImpl.createPageLink(InternalComponentResourcesImpl.java:128)
   at 
 org.apache.tapestry.corelib.components.PageLink.beginRender(PageLink.java:73)
   at 
 org.apache.tapestry.corelib.components.PageLink.beginRender(PageLink.java)
   at 
 org.apache.tapestry.internal.structure.ComponentPageElementImpl$11$1.run(ComponentPageElementImpl.java:338)
   at 
 org.apache.tapestry.internal.structure.ComponentPageElementImpl.invoke(ComponentPageElementImpl.java:874)
   ... 62 more
 Caused by: java.lang.ClassNotFoundException: caught an exception while 
 obtaining a class file for root package.pages.MyPage
   at javassist.Loader.findClass(Loader.java:359)
   at 
 org.apache.tapestry.internal.services.ComponentInstantiatorSourceImpl$PackageAwareLoader.findClass(ComponentInstantiatorSourceImpl.java:73)
   at javassist.Loader.loadClass(Loader.java:311)
   at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
   at 
 org.apache.tapestry.internal.services.ComponentInstantiatorSourceImpl.findClass(ComponentInstantiatorSourceImpl.java:237)
   ... 84 more
 Caused by: java.lang.RuntimeException: Base class root 
 package.base.AbstractPage (super class of root package.pages.MyPage) is 
 not in a controlled package and is therefore not valid. You should try moving 
 the class to package root package.base.
   at 
 org.apache.tapestry.internal.services.ComponentClassTransformerImpl.transformComponentClass(ComponentClassTransformerImpl.java:126)
   at 
 $ComponentClassTransformer_118ac384913.transformComponentClass($ComponentClassTransformer_118ac384913.java)
   at 
 org.apache.tapestry.internal.services.ComponentInstantiatorSourceImpl.onLoad(ComponentInstantiatorSourceImpl.java:162)
   at javassist.Loader.findClass(Loader.java:340)
   ... 88 more

-- 
This 

[jira] Assigned: (TAP5-803) ProgressiveDisplay should include a read-only body property of type Block, just like Zone

2009-12-09 Thread Howard M. Lewis Ship (JIRA)

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

Howard M. Lewis Ship reassigned TAP5-803:
-

Assignee: Howard M. Lewis Ship

 ProgressiveDisplay should include a read-only body property of type Block, 
 just like Zone
 -

 Key: TAP5-803
 URL: https://issues.apache.org/jira/browse/TAP5-803
 Project: Tapestry 5
  Issue Type: Improvement
  Components: tapestry-core
Affects Versions: 5.1.0.5
Reporter: Howard M. Lewis Ship
Assignee: Howard M. Lewis Ship

 In other words, allow us to provide a correct return value from the 
 progressivedisplay event handler method ... update the PD with it's 
 server-side body.
 The context for this was performing multiple zone updates (the PD plus 
 additional zones) from the progressive display event handler method. Perhaps 
 this could be added as an example in the PD component reference.

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



svn commit: r888942 - /tapestry/tapestry5/trunk/tapestry-core/src/main/java/org/apache/tapestry5/corelib/components/ProgressiveDisplay.java

2009-12-09 Thread hlship
Author: hlship
Date: Wed Dec  9 20:18:08 2009
New Revision: 888942

URL: http://svn.apache.org/viewvc?rev=888942view=rev
Log:
TAP5-803: ProgressiveDisplay should include a read-only body property of type 
Block, just like Zone

Modified:

tapestry/tapestry5/trunk/tapestry-core/src/main/java/org/apache/tapestry5/corelib/components/ProgressiveDisplay.java

Modified: 
tapestry/tapestry5/trunk/tapestry-core/src/main/java/org/apache/tapestry5/corelib/components/ProgressiveDisplay.java
URL: 
http://svn.apache.org/viewvc/tapestry/tapestry5/trunk/tapestry-core/src/main/java/org/apache/tapestry5/corelib/components/ProgressiveDisplay.java?rev=888942r1=888941r2=888942view=diff
==
--- 
tapestry/tapestry5/trunk/tapestry-core/src/main/java/org/apache/tapestry5/corelib/components/ProgressiveDisplay.java
 (original)
+++ 
tapestry/tapestry5/trunk/tapestry-core/src/main/java/org/apache/tapestry5/corelib/components/ProgressiveDisplay.java
 Wed Dec  9 20:18:08 2009
@@ -15,6 +15,7 @@
 package org.apache.tapestry5.corelib.components;
 
 import org.apache.tapestry5.*;
+import org.apache.tapestry5.ajax.MultiZoneUpdate;
 import org.apache.tapestry5.annotations.*;
 import org.apache.tapestry5.dom.Element;
 import org.apache.tapestry5.internal.services.ComponentResultProcessorWrapper;
@@ -26,16 +27,21 @@
 import java.io.IOException;
 
 /**
- * A component used to implement the a 
href=http://en.wikipedia.org/wiki/Progressive_enhancement;progressive
- * enhancement/a web design strategy; the component renders itself with a 
simplified initial content (i.e., loading
- * ...) and an Ajax request then supplies the component's true body. This 
results in much faster page loads. You can
+ * A component used to implement the a
+ * href=http://en.wikipedia.org/wiki/Progressive_enhancement;progressive
+ * enhancement/a web design strategy; the component renders itself with a
+ * simplified initial content (i.e., loading
+ * ...) and an Ajax request then supplies the component's true body. This
+ * results in much faster page loads. You can
  * even nest these!
  * p/
- * The component simply does not render its body on initial render. On the 
subsequent action event request, it fires a
- * {...@link org.apache.tapestry5.EventConstants#PROGRESSIVE_DISPLAY} event to 
inform the container about the (optional)
- * event context. The event handler method may return a renderable object; if 
not then the component's body is rendered
- * as the partial markup response.
- *
+ * The component simply does not render its body on initial render. On the
+ * subsequent action event request, it fires a
+ * {...@link org.apache.tapestry5.EventConstants#PROGRESSIVE_DISPLAY} event to
+ * inform the container about the (optional) event context. The event handler
+ * method may return a renderable object; if not then the component's body is
+ * rendered as the partial markup response.
+ * 
  * @since 5.1.0.1
  */
 @SupportsInformalParameters
@@ -44,15 +50,16 @@
 public class ProgressiveDisplay
 {
 /**
- * The initial content to display until the real content arrives. Defaults 
to Loading ... and an Ajax activity
+ * The initial content to display until the real content arrives. Defaults
+ * to Loading ... and an Ajax activity
  * icon.
  */
 @Parameter(defaultPrefix = BindingConstants.LITERAL, value = 
block:defaultInitial)
 private Block initial;
 
 /**
- * If provided, this is the event context, which will be provided via the 
{...@link
- * org.apache.tapestry5.EventConstants#PROGRESSIVE_DISPLAY event}.
+ * If provided, this is the event context, which will be provided via the
+ * {...@link org.apache.tapestry5.EventConstants#PROGRESSIVE_DISPLAY 
event}.
  */
 @Parameter
 private Object[] context;
@@ -67,8 +74,10 @@
 private ComponentEventResultProcessor resultProcessor;
 
 /**
- * Name of a function on the client-side Tapestry.ElementEffect object 
that is invoked after the elements's body
- * content has been updated. If not specified, then the basic highlight 
method is used, which performs a classic
+ * Name of a function on the client-side Tapestry.ElementEffect object that
+ * is invoked after the elements's body
+ * content has been updated. If not specified, then the basic highlight
+ * method is used, which performs a classic
  * yellow fade to indicate to the user that and update has taken place.
  */
 @Parameter(defaultPrefix = BindingConstants.LITERAL)
@@ -89,8 +98,7 @@
 
 JSONObject spec = new JSONObject();
 
-if (InternalUtils.isNonBlank(update))
-spec.put(update, update.toLowerCase());
+if (InternalUtils.isNonBlank(update)) spec.put(update, 
update.toLowerCase());
 
 spec.put(element, clientId);
 spec.put(url, link.toAbsoluteURI());
@@ -102,14 +110,14 @@
 
 Object onAction(EventContext context) throws 

[jira] Closed: (TAP5-803) ProgressiveDisplay should include a read-only body property of type Block, just like Zone

2009-12-09 Thread Howard M. Lewis Ship (JIRA)

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

Howard M. Lewis Ship closed TAP5-803.
-

   Resolution: Fixed
Fix Version/s: 5.2.0.0

 ProgressiveDisplay should include a read-only body property of type Block, 
 just like Zone
 -

 Key: TAP5-803
 URL: https://issues.apache.org/jira/browse/TAP5-803
 Project: Tapestry 5
  Issue Type: Improvement
  Components: tapestry-core
Affects Versions: 5.1.0.5
Reporter: Howard M. Lewis Ship
Assignee: Howard M. Lewis Ship
 Fix For: 5.2.0.0


 In other words, allow us to provide a correct return value from the 
 progressivedisplay event handler method ... update the PD with it's 
 server-side body.
 The context for this was performing multiple zone updates (the PD plus 
 additional zones) from the progressive display event handler method. Perhaps 
 this could be added as an example in the PD component reference.

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



[jira] Assigned: (TAP5-713) Change template parser to not use STAX, as it is not (yet) compatible with Google App Engine

2009-12-09 Thread Howard M. Lewis Ship (JIRA)

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

Howard M. Lewis Ship reassigned TAP5-713:
-

Assignee: Howard M. Lewis Ship

 Change template parser to not use STAX, as it is not (yet) compatible with 
 Google App Engine
 

 Key: TAP5-713
 URL: https://issues.apache.org/jira/browse/TAP5-713
 Project: Tapestry 5
  Issue Type: Improvement
  Components: tapestry-core
Affects Versions: 5.1.0.5
Reporter: Howard M. Lewis Ship
Assignee: Howard M. Lewis Ship
 Attachments: SaxTemplateParserImpl.java, SaxTemplateParserImpl.java, 
 SaxTemplateParserImpl.java, SaxTemplateParserImpl.java, 
 SaxTemplateParserImpl.java


 The StAX APIs are not on the GAE white list.
 Should be reasonable ot change the code, by using a SAX parser that parses 
 the template into a list of tokens, and then iterate down the token list as 
 we do today using StAX.  End result will be fewer dependencies to boot.

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



[jira] Assigned: (TAP5-632) Property names (in property expressions) should be able to read or update public variables

2009-12-09 Thread Howard M. Lewis Ship (JIRA)

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

Howard M. Lewis Ship reassigned TAP5-632:
-

Assignee: Howard M. Lewis Ship

 Property names (in property expressions) should be able to read or update 
 public variables
 --

 Key: TAP5-632
 URL: https://issues.apache.org/jira/browse/TAP5-632
 Project: Tapestry 5
  Issue Type: Improvement
  Components: tapestry-core
Affects Versions: 5.1.0.3, 5.0.18
Reporter: Howard M. Lewis Ship
Assignee: Howard M. Lewis Ship

 This leads to some ambiguities.
 Should we compare the property name to the field name after stripping some 
 punctuation from the field name (i.e., _, $).
 Should we list public field names as well as property names (probably) if 
 there is no match?
 Which has higher priority: field name or property (via accessor method)?  I 
 think property/accessor method.
 It would also be nice if the PropertyAccess service was made aware of public 
 fields. That would be nice, to allow annotations on the field to be exposed 
 uniformly.

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



svn commit: r888946 - in /tapestry/tapestry5/trunk/tapestry-core/src: main/java/org/apache/tapestry5/ main/java/org/apache/tapestry5/internal/services/ main/java/org/apache/tapestry5/services/ test/ap

2009-12-09 Thread robertdzeigler
Author: robertdzeigler
Date: Wed Dec  9 20:28:13 2009
New Revision: 888946

URL: http://svn.apache.org/viewvc?rev=888946view=rev
Log:
TAP5-815: Asset dispatcher allows any file inside the webapp visible and 
downloadable
Return 404 instead of 403 for restricted paths; removes chenillekit 
contribution; adds default contribution for context assets; adds integration 
test.

Added:
tapestry/tapestry5/trunk/tapestry-core/src/test/app1/AssetProtectionDemo.tml
tapestry/tapestry5/trunk/tapestry-core/src/test/app1/availablefile.txt
tapestry/tapestry5/trunk/tapestry-core/src/test/app1/unavailablefile.txt

tapestry/tapestry5/trunk/tapestry-core/src/test/java/org/apache/tapestry5/integration/app1/pages/AssetProtectionDemo.java
Modified:

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

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

tapestry/tapestry5/trunk/tapestry-core/src/main/java/org/apache/tapestry5/services/TapestryModule.java

tapestry/tapestry5/trunk/tapestry-core/src/test/java/org/apache/tapestry5/integration/IntegrationTests.java

tapestry/tapestry5/trunk/tapestry-core/src/test/java/org/apache/tapestry5/integration/app1/pages/Index.java

tapestry/tapestry5/trunk/tapestry-core/src/test/java/org/apache/tapestry5/integration/app1/services/AppModule.java

Modified: 
tapestry/tapestry5/trunk/tapestry-core/src/main/java/org/apache/tapestry5/SymbolConstants.java
URL: 
http://svn.apache.org/viewvc/tapestry/tapestry5/trunk/tapestry-core/src/main/java/org/apache/tapestry5/SymbolConstants.java?rev=888946r1=888945r2=888946view=diff
==
--- 
tapestry/tapestry5/trunk/tapestry-core/src/main/java/org/apache/tapestry5/SymbolConstants.java
 (original)
+++ 
tapestry/tapestry5/trunk/tapestry-core/src/main/java/org/apache/tapestry5/SymbolConstants.java
 Wed Dec  9 20:28:13 2009
@@ -275,4 +275,13 @@
  */
 public static final String BLACKBIRD  = tapestry.blackbird;
 
+/**
+ * Whether assets in the web application's context directory are available 
by default.
+ * If true (the default), tapestry will provide conributions to the 
appropriate services (RegexAuthorizer) to allow access
+ * to .js, .jpg, .jpeg, .png, .gif, and .css assets that reside within the 
application context.
+ * If false, no such contributions will be made, and access to those 
resources will be restricted
+ * without explicit user contributions.
+ */
+public static final String CONTEXT_ASSETS_AVAILABLE 
=tapestry.context-assets-available;
+
 }

Modified: 
tapestry/tapestry5/trunk/tapestry-core/src/main/java/org/apache/tapestry5/internal/services/AssetProtectionDispatcher.java
URL: 
http://svn.apache.org/viewvc/tapestry/tapestry5/trunk/tapestry-core/src/main/java/org/apache/tapestry5/internal/services/AssetProtectionDispatcher.java?rev=888946r1=888945r2=888946view=diff
==
--- 
tapestry/tapestry5/trunk/tapestry-core/src/main/java/org/apache/tapestry5/internal/services/AssetProtectionDispatcher.java
 (original)
+++ 
tapestry/tapestry5/trunk/tapestry-core/src/main/java/org/apache/tapestry5/internal/services/AssetProtectionDispatcher.java
 Wed Dec  9 20:28:13 2009
@@ -77,7 +77,7 @@
 if (auth.accessDenied(resourcePath))
 {
 logger.debug(Denying access to  + resourcePath);
-
response.sendError(HttpServletResponse.SC_FORBIDDEN,resourcePath);
+response.sendError(HttpServletResponse.SC_NOT_FOUND, 
resourcePath);
 return true;
 }
 }

Modified: 
tapestry/tapestry5/trunk/tapestry-core/src/main/java/org/apache/tapestry5/services/TapestryModule.java
URL: 
http://svn.apache.org/viewvc/tapestry/tapestry5/trunk/tapestry-core/src/main/java/org/apache/tapestry5/services/TapestryModule.java?rev=888946r1=888945r2=888946view=diff
==
--- 
tapestry/tapestry5/trunk/tapestry-core/src/main/java/org/apache/tapestry5/services/TapestryModule.java
 (original)
+++ 
tapestry/tapestry5/trunk/tapestry-core/src/main/java/org/apache/tapestry5/services/TapestryModule.java
 Wed Dec  9 20:28:13 2009
@@ -2113,6 +2113,8 @@
 configuration.add(SymbolConstants.ENCODE_LOCALE_INTO_PATH, true);
 
 configuration.add(SymbolConstants.BLACKBIRD_ENABLED, false);
+
+configuration.add(SymbolConstants.CONTEXT_ASSETS_AVAILABLE, true);
 }
 
 
@@ -2508,13 +2510,16 @@
 public void contributeRegexAuthorizer(ConfigurationString regex,
 @Symbol(tapestry.scriptaculous.path) String scriptPath,
 @Symbol(tapestry.blackbird.path) String blackbirdPath,
-

[jira] Commented: (TAP5-726) Grid should determine the class row type from a field when there is no BeanModel and GridDataSource

2009-12-09 Thread Denis Stepanov (JIRA)

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

Denis Stepanov commented on TAP5-726:
-

I know, you can close it if you want, in all cases we are using our own 
GridSource and BeanModel

 Grid should determine the class row type from a field when there is no 
 BeanModel and GridDataSource
 ---

 Key: TAP5-726
 URL: https://issues.apache.org/jira/browse/TAP5-726
 Project: Tapestry 5
  Issue Type: Bug
  Components: tapestry-core
Affects Versions: 5.1.0.5
Reporter: Denis Stepanov
Priority: Minor

 CollectionGridDataSource uses first collection item to determine the class 
 type, but in situation when collection contains different hierarchy 
 implementation there is a ClassCastException

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



svn commit: r888982 - in /tapestry/tapestry-site/trunk/src/site/xdoc: index.xml news.xml

2009-12-09 Thread drobiazko
Author: drobiazko
Date: Wed Dec  9 21:26:51 2009
New Revision: 888982

URL: http://svn.apache.org/viewvc?rev=888982view=rev
Log:
Added news about new committer.

Modified:
tapestry/tapestry-site/trunk/src/site/xdoc/index.xml
tapestry/tapestry-site/trunk/src/site/xdoc/news.xml

Modified: tapestry/tapestry-site/trunk/src/site/xdoc/index.xml
URL: 
http://svn.apache.org/viewvc/tapestry/tapestry-site/trunk/src/site/xdoc/index.xml?rev=888982r1=888981r2=888982view=diff
==
--- tapestry/tapestry-site/trunk/src/site/xdoc/index.xml (original)
+++ tapestry/tapestry-site/trunk/src/site/xdoc/index.xml Wed Dec  9 21:26:51 
2009
@@ -32,7 +32,8 @@
h5New!/h5
ul style=list-style:none
 
-lia href=news.html#20091027Thiago elected to PMC/a/li
+   lia href=news.html#20091125New 
committer: Ulrich Stärk/a/li
+   lia href=news.html#20091027Thiago 
elected to PMC/a/li
li
a 
href=news.html#20090913New Tapestry 5 book available as eBook/a
/li

Modified: tapestry/tapestry-site/trunk/src/site/xdoc/news.xml
URL: 
http://svn.apache.org/viewvc/tapestry/tapestry-site/trunk/src/site/xdoc/news.xml?rev=888982r1=888981r2=888982view=diff
==
--- tapestry/tapestry-site/trunk/src/site/xdoc/news.xml (original)
+++ tapestry/tapestry-site/trunk/src/site/xdoc/news.xml Wed Dec  9 21:26:51 2009
@@ -11,7 +11,14 @@
p
Keep up to date with the latest events in the 
Tapestry world.
 /p
+   a name=20091125 /
+   subsection name=Ulrich Stärk
+   strongNov 25 2009/strong
 
+
+   pUlrich Stärk, a very active Tapestry 
community member, has been voted in as a Tapestry committer. Welcome aboard, 
Uli!/p
+   /subsection
+   
a name=20091027 /
subsection name=Thiago H. de Paula Figueiredo joins 
the PMC
strongOct 27 2009/strong