[jira] Created: (TAP5-1355) Threading issue with SessionStateObjects
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 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? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TAP5-1355) Threading issue with SessionStateObjects
[ https://issues.apache.org/jira/browse/TAP5-1355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Moritz Gmelin updated TAP5-1355: Attachment: taptest.tgz 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: 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? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TAP5-1355) Threading issue with SessionStateObjects
[ https://issues.apache.org/jira/browse/TAP5-1355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Moritz Gmelin updated TAP5-1355: Description: 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/ was: 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? 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: 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] Updated: (TAP5-1355) Threading issue with SessionStateObjects
[ https://issues.apache.org/jira/browse/TAP5-1355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Moritz Gmelin updated TAP5-1355: Attachment: Screenshot.png.jpg This is how it looks like when some of the images get a new session 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.
[CONF] Apache Tapestry HTTPS
HTTPS
Page edited by Kalle Korhonen
Changes (1)
...
{code}
public static void contributeServiceOverrides(MappedConfigurationClass,Object configuration)
{ BaseURLSource source = new BaseURLSource()
...
Full Content
Securing your application with HTTPS
Tapestry assumes your application will be primarily deployed as a standard web application, using HTTP (not HTTPS) as the transport mechanism.
However, many applications will need to have some of their pages secured: only accessible via HTTPS. This could be a login page, or a product ordering wizard, or administrative pages.
All that is necessary to mark a page as secure is to add the @Secure annotation to the page class:
@Secure
public class ProcessOrder
{
. . .
}
When a page is marked as secure, Tapestry will ensure that access to that page uses HTTPS. All links to the page will use the "https" protocol.
If an attempt is made to access a secure page using a non-secure request (a normal HTTP request), Tapestry will send an HTTPS redirect to the client.
Links to non-secure pages from a secure page will do the reverse: a complete URL with an "http" protocol will be used. In other words, Tapestry manages the transition from insecure to secure and back again.
Links to other (secure) pages and to assets will be based on relative URLs and, therefore, secure.
The rationale behind using secure links to assets from secure pages is that it prevents the client web browser from reporting a mixed security level.
Securing Multiple Pages
Rather than placing an @Secure annotation on individual pages, it is possible to enable security for folders of pages. All pages in or beneath the folder will be secured.
This is accomplished by making a contribution to the MetaDataLocator service configuration. For example, to secure all pages in the "admin" folder:
public void contributeMetaDataLocator(MappedConfigurationString,String configuration)
{
configuration.add("admin:" + MetaDataConstants.SECURE_PAGE, "true");
}
Here "admin" is the folder name, and the colon is a separator between the folder name and the the meta data key. SECURE_PAGE is a public constant for value "tapestry.secure-page";
When Tapestry is determining if a page is secure or not, it starts by checking for the @Secure annotation, then it consults the MetaDataLocator service.
If you want to make your entire application secure:
public void contributeMetaDataLocator(MappedConfigurationString,String configuration)
{
configuration.add(MetaDataConstants.SECURE_PAGE, "true");
}
With no colon, the meta data applies to the entire application (including any component libraries used in the application).
Base URL Support
When Tapestry switches back and forth between secure and unsecure mode, it must create a full URL (rather than a relative URL) that identifies the protocol, server host name and perhaps even a port number.
That can be a stumbling point, especially the server host name. In a cluster, behind a fire wall, the server host name available to Tapestry, via the HttpServletRequest.getServerName() method, is often not the server name the client web browser sees ... instead it is the name of the internal server behind the firewall. The firewall server has the correct name from the web browser's point of view.
Because of this, Tapestry includes a hook to allow you to override how these default URLs are created: the BaseURLSource service.
The default implementation is based on just the getServerName() method; it's often not the correct choice even for development.
Fortunately, it is very easy to override this implementation. Here's an example of an override that uses the default port numbers that the Jetty servlet container uses for normal HTTP (port 8080) and for secure HTTPS (port 8443):
public static void contributeServiceOverride(MappedConfigurationClass,Object configuration)
{
BaseURLSource source = new BaseURLSource()
{
public String getBaseURL(boolean secure)
{
String protocol = secure ? "https" : "http";
int port = secure ? 8443 : 8080;
return String.format("%s://localhost:%d", protocol, port);
}
};
configuration.add(BaseURLSource.class, source);
}
This override is hardcoded to generate URLs for localhost; as such you might use it for development but certainly not in production.
Development Mode
When working in development mode, the Secure annotation is ignored. This is controlled by the tapestry.secure-enabled configuration symbol.
Application Server Configuration
Setting up HTTPS support varies from application server to application server.
Jetty:
Jetty 6
[jira] Created: (TAP5-1356) When contributing to a service configuration, values should be coerced to the correct type rather than rejected if not the correct type
When contributing to a service configuration, values should be coerced to the correct type rather than rejected if not the correct type --- Key: TAP5-1356 URL: https://issues.apache.org/jira/browse/TAP5-1356 Project: Tapestry 5 Issue Type: Improvement Components: tapestry-ioc Affects Versions: 5.2.5 Reporter: Howard M. Lewis Ship This will make it much easier to migrate the behavior of services as long as contributions of the old type can be coerced to contributions of the new type. It may also make it easier to contribute symbol constants, as it will be possible to pass true, not true, or literal numbers. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[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=12935607#action_12935607
]
Josh Canfield commented on TAP5-1355:
-
The problem appears to be with a bug fix for TAP5-834.
if (analyzer.isDirty(attributeValue))
{
// 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.
session.setAttribute(attributeName, null);
session.setAttribute(attributeName, attributeValue);
}
For a moment the session attribute is set to null. Sometimes code asks for the
session value before it gets to the next line where it sets it back.
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-1355) Threading issue with SessionStateObjects
[
https://issues.apache.org/jira/browse/TAP5-1355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12935612#action_12935612
]
Thiago H. de Paula Figueiredo commented on TAP5-1355:
-
Hi, Josh!
Instead of reverting the TAP5-834, which would cause other problems, what about
putting that two statements in a synchronized block?
syncronized (session) {
session.setAttribute(attributeName, null);
session.setAttribute(attributeName, attributeValue);
}
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] Reopened: (TAP5-834) BaseOptimizedSessionPersistedObject does not work correctly with Tomcat Jetty
[
https://issues.apache.org/jira/browse/TAP5-834?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh Canfield reopened TAP5-834:
While the reported defect is no longer present, the fix introduced a
significant defect in handling concurrent requests for SessionStateObjects.
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
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] Commented: (TAP5-85) Make Java Class optional for Rendering Pages
[ https://issues.apache.org/jira/browse/TAP5-85?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12935615#action_12935615 ] Thiago H. de Paula Figueiredo commented on TAP5-85: --- I prefer the idea of a Maven plugin that creates the empty classes automatically way more than changing the framework itself, as this would complicate a lot the way pages and components are located. Make Java Class optional for Rendering Pages Key: TAP5-85 URL: https://issues.apache.org/jira/browse/TAP5-85 Project: Tapestry 5 Issue Type: New Feature Affects Versions: 5.0.15 Environment: Microsoft Windows Vista Business Edition, Eclipse 3.3, Maven 2, Jetty 5.5, Tomcat 6 Reporter: Evan M Rawson Priority: Minor You should not need a java class create to view a page. The framework should be able to generate a basic class on the fly. This would aid significantly to the production flow of tapestry applications. Meaning that designers and system architects do not need to setup the basic java class in order to build and test the front end user interface. When a java class representing the page is present then it would override this default generate class that tapestry makes on the fly. EX: right now im creating a pretty decent sized tapestry application (75 to 125 pages). The pages have been mocked up and the interface is being assembled (html/css). I am finding that i am needing to create a bunch of empty java classes in order to view the page to test it; this seems pointless and redundant to me. For example a script in maven could be written to auto generate all of the classes based on the html template dir is stored, saving a few hours of naming and creating. the java developer should not have to create the html pages, technically they should be able to use junit to handle testing their base components which they have created. The backend and frontend should seamlessly integrated with each other. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (TAP5-834) BaseOptimizedSessionPersistedObject does not work correctly with Tomcat Jetty
[
https://issues.apache.org/jira/browse/TAP5-834?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh Canfield closed TAP5-834.
--
Resolution: Fixed
un-reopened... that was dumb we should just track it in the other defect.
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
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] Commented: (TAP5-85) Make Java Class optional for Rendering Pages
[ https://issues.apache.org/jira/browse/TAP5-85?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12935632#action_12935632 ] Josh Canfield commented on TAP5-85: --- I'm strongly opposed to using maven to do this... there is already a perception that tapestry is maven dependent and that's turn-off in some circles. Make Java Class optional for Rendering Pages Key: TAP5-85 URL: https://issues.apache.org/jira/browse/TAP5-85 Project: Tapestry 5 Issue Type: New Feature Affects Versions: 5.0.15 Environment: Microsoft Windows Vista Business Edition, Eclipse 3.3, Maven 2, Jetty 5.5, Tomcat 6 Reporter: Evan M Rawson Priority: Minor You should not need a java class create to view a page. The framework should be able to generate a basic class on the fly. This would aid significantly to the production flow of tapestry applications. Meaning that designers and system architects do not need to setup the basic java class in order to build and test the front end user interface. When a java class representing the page is present then it would override this default generate class that tapestry makes on the fly. EX: right now im creating a pretty decent sized tapestry application (75 to 125 pages). The pages have been mocked up and the interface is being assembled (html/css). I am finding that i am needing to create a bunch of empty java classes in order to view the page to test it; this seems pointless and redundant to me. For example a script in maven could be written to auto generate all of the classes based on the html template dir is stored, saving a few hours of naming and creating. the java developer should not have to create the html pages, technically they should be able to use junit to handle testing their base components which they have created. The backend and frontend should seamlessly integrated with each other. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[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=12935649#action_12935649 ] Josh Canfield commented on TAP5-1355: - @Thiago Yeah, I realized reverting the other defect was wrong, but I had to pack up my computer and re-locate before I could fix it :) I un-reopened it and marked this as a regression. We could synchronize around the session in both the getAttribute method and the restoreDirtyObjects method so that apps would be blocked from getting any attribute value while it was temporarily null. I'm a little hesitant to do that... more of a gut thing than hard data though. I currently prefer the idea of using a wrapper object, but I could be persuaded. 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.
