[jira] [Commented] (TAP5-1729) Sometimes YUICompressor can fail with java.util.EmptyStackException
[ https://issues.apache.org/jira/browse/TAP5-1729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13291660#comment-13291660 ] Dragan Sahpaski commented on TAP5-1729: --- Thanks that one worked just fine. Cheers Sometimes YUICompressor can fail with java.util.EmptyStackException --- Key: TAP5-1729 URL: https://issues.apache.org/jira/browse/TAP5-1729 Project: Tapestry 5 Issue Type: Bug Components: tapestry-yuicompressor Affects Versions: 5.3 Reporter: Howard M. Lewis Ship Priority: Blocker [ERROR] ioc.Registry java.util.EmptyStackException [ERROR] ioc.Registry Operations trace: [ERROR] ioc.Registry [ 1] Streaming asset stack en/core.js [ERROR] ioc.Registry [ 2] Minimizing JavaScript [ERROR] TapestryModule.RequestExceptionHandler Processing of request failed with uncaught exception: org.apache.tapestry5.ioc.internal.OperationException org.apache.tapestry5.ioc.internal.OperationException at org.apache.tapestry5.ioc.internal.OperationTrackerImpl.logAndRethrow(OperationTrackerImpl.java:121) at org.apache.tapestry5.ioc.internal.OperationTrackerImpl.invoke(OperationTrackerImpl.java:88) at org.apache.tapestry5.ioc.internal.OperationTrackerImpl.run(OperationTrackerImpl.java:47) at org.apache.tapestry5.ioc.internal.PerThreadOperationTracker.run(PerThreadOperationTracker.java:76) at org.apache.tapestry5.ioc.internal.RegistryImpl.run(RegistryImpl.java:1109) at org.apache.tapestry5.internal.TapestryInternalUtils.performIO(TapestryInternalUtils.java:576) at org.apache.tapestry5.internal.yuicompressor.AbstractMinimizer.minimize(AbstractMinimizer.java:62) at org.apache.tapestry5.internal.services.assets.MasterResourceMinimizer.minimize(MasterResourceMinimizer.java:44) at $ResourceMinimizer_1250535a97d2196c.minimize(Unknown Source) at org.apache.tapestry5.internal.services.assets.StackAssetRequestHandler.assembleStackContent(StackAssetRequestHandler.java:175) at org.apache.tapestry5.internal.services.assets.StackAssetRequestHandler.assembleStackContent(StackAssetRequestHandler.java:163) at org.apache.tapestry5.internal.services.assets.StackAssetRequestHandler.getUncompressedResource(StackAssetRequestHandler.java:146) at org.apache.tapestry5.internal.services.assets.StackAssetRequestHandler.getResource(StackAssetRequestHandler.java:123) at org.apache.tapestry5.internal.services.assets.StackAssetRequestHandler.access$100(StackAssetRequestHandler.java:40) at org.apache.tapestry5.internal.services.assets.StackAssetRequestHandler$1.perform(StackAssetRequestHandler.java:103) at org.apache.tapestry5.internal.TapestryInternalUtils$5.run(TapestryInternalUtils.java:582) at org.apache.tapestry5.ioc.internal.OperationTrackerImpl$1.invoke(OperationTrackerImpl.java:51) at org.apache.tapestry5.ioc.internal.OperationTrackerImpl$1.invoke(OperationTrackerImpl.java:48) at org.apache.tapestry5.ioc.internal.OperationTrackerImpl.invoke(OperationTrackerImpl.java:74) at org.apache.tapestry5.ioc.internal.OperationTrackerImpl.run(OperationTrackerImpl.java:47) at org.apache.tapestry5.ioc.internal.PerThreadOperationTracker.run(PerThreadOperationTracker.java:76) at org.apache.tapestry5.ioc.internal.RegistryImpl.run(RegistryImpl.java:1109) at org.apache.tapestry5.internal.TapestryInternalUtils.performIO(TapestryInternalUtils.java:576) at org.apache.tapestry5.internal.services.assets.StackAssetRequestHandler.handleAssetRequest(StackAssetRequestHandler.java:96) at org.apache.tapestry5.internal.services.AssetDispatcher.dispatch(AssetDispatcher.java:109) at $Dispatcher_1250535a97d21963.dispatch(Unknown Source) at $Dispatcher_1250535a97d21967.dispatch(Unknown Source) at $Dispatcher_1250535a97d21961.dispatch(Unknown Source) at org.apache.tapestry5.services.TapestryModule$RequestHandlerTerminator.service(TapestryModule.java:302) at org.apache.tapestry5.internal.services.RequestErrorFilter.service(RequestErrorFilter.java:26) at $RequestHandler_1250535a97d21962.service(Unknown Source) at org.apache.tapestry5.services.TapestryModule$3.service(TapestryModule.java:902) at $RequestHandler_1250535a97d21962.service(Unknown Source) at org.apache.tapestry5.services.TapestryModule$2.service(TapestryModule.java:892) at $RequestHandler_1250535a97d21962.service(Unknown Source) at org.apache.tapestry5.internal.services.StaticFilesFilter.service(StaticFilesFilter.java:90) at $RequestHandler_1250535a97d21962.service(Unknown Source) at
[jira] [Closed] (TAP5-1953) Does the cache for resolved page class names grow indefinetly?
[ https://issues.apache.org/jira/browse/TAP5-1953?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thiago H. de Paula Figueiredo closed TAP5-1953. --- Resolution: Invalid Please post questions to the Tapestry users mailing list: http://tapestry.apache.org/mailing-lists.html. Does the cache for resolved page class names grow indefinetly? -- Key: TAP5-1953 URL: https://issues.apache.org/jira/browse/TAP5-1953 Project: Tapestry 5 Issue Type: Question Components: tapestry-core Affects Versions: 5.3.3 Reporter: Carsten Klein Having implemented a decorator for the ComponentClassResolver service, I noticed that my advises and the delegates thereof will be called only during initial resolve of the page class name for a given request path. I wonder if the cache, which prevents subsequent calls to the custom resolver between requests, does grow indefinitely, and if so, would it be possible to change it so, as to not consume all of the available memory in situations of both high load and indefinite numbers of available request paths? Also, I have been unable to find the class/method responsible for caching the results from my custom resolver to this point. Could you please point me to where I may find the caching logic? TIA and keep up the great work! -- Carsten -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TAP5-1955) Documentation on ServiceBinder#bind(ClassT implementationClass) is wrong/lacks extra information
Carsten Klein created TAP5-1955:
---
Summary: Documentation on ServiceBinder#bind(ClassT
implementationClass) is wrong/lacks extra information
Key: TAP5-1955
URL: https://issues.apache.org/jira/browse/TAP5-1955
Project: Tapestry 5
Issue Type: Improvement
Components: tapestry-core
Affects Versions: 5.3.3
Reporter: Carsten Klein
Priority: Minor
The documentation on the above mentioned method states that
Defines a service in terms of an implementation class, without a service
interface. In this case, the service
will not be proxiable (proxying requires a service interface) and {@link
ServiceDef#getServiceInterface()} will
return the implementation class. In this situation, the service will not be
proxied; it will be instantiated
fully on first reference (ignoring its scope, if any) and will not be
decorated.
In tapestry-core InternalModule I found usages of that interface, where you
bind an interface class.
Looking at the code, the implementation will try to resolve the implementation
class and then bind
it using the standard bind(ClassT serviceInterface, Class? extends T
implementationClass) method.
Bound as such, the interface can both be proxied and decorated.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[CONF] Apache Tapestry JavaScript Rewrite
_javascript_ Rewrite
Page edited by Howard M. Lewis Ship
Comment:
added some notes about cdns
Changes (5)
...
* Compressible resources will be automatically GZip compressed if the client supports it
However, _javascript_ support in Tapestry is still unsatisfactory. Too often, Tapestry falls into an [uncanny valley|http://en.wikipedia.org/wiki/Uncanny_valley] where the framework (server-side and client-side) does so much automatically that it becomes accepted that it does everything ... developers later discover, to their dismay, that the last 10% of custom behavior they desire is very hard to implement, because of all the common problems that plague any complex system: insufficient APIs, unexpected leaky abstractions, or just plain bugs.Common examples of the challenges imposed by Tapestry include implementing a Confirm mixin, customizing behavior when a Zone component is dynamically updated, or any number of issues related to Forms, form elements, and Ajax updates. This document is a roadmap for how Tapestry 5.4 will revisit the relationship between server-side Java and client-side _javascript_. Ultimately, we hope to convert this relationship from an obstacle to using Tapestry into an essential reason to select Tapestry in the first place.
h1. Tapestry _javascript_ Limitations (through 5.3)
...
There has not, to date, been an adequate documentation of the {{T5}} and {{Tapestry}} namespaces, beyond the code itself.
h2. The Uncanny Valley Too often, Tapestry falls into an [uncanny valley|http://en.wikipedia.org/wiki/Uncanny_valley] where the framework (server-side and client-side) does so much automatically that it becomes accepted that it does everything ... developers later discover, to their dismay, that the last 10% of custom behavior they desire is very hard to implement, because Tapestry gets in the way. Common examples include implementing a Confirm mixin, customizing behavior when a Zone component is dynamically updated, or any number of issues related to Forms, form elements, and Ajax updates. In effect, Tapestry should get out of the business of doing most things, especially visual things, and stick to publishing messages about things (see the notes below on Publish/Subscribe). Specifically, Tapestry should avoid animations and other visual effects (which also significantly tie Tapestry to a specific client-side foundational framework), and simply facilitate the informing the client-side that events have happend, and allow the user application to decide how to present that information.
h2. Lack of Module Structure
...
In the (hopefully) common case that a module can operate without additional configuration, the @Require annotation will be analagous to the Tapestry 5.2 [@Import|http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/annotations/Import.html] annotation. It will allow one or more modules to be required. This is only useful when the modules are stand-alone (not needing any explicit configuration).
h2. Increased Used Of Publish/Subscribe
An inherent limitation of Tapestry 5.3 and earlier is the too-direct connection between DOM events and client behaviors. Coding in terms of the user clicks and the event handler submits a request makes it very hard to fine tune behavior. For example, much work and experimentation was needed in order to introduce a Confirm mixin that could be used to introduce a confirmation dialog before allowing an event (clicking a link or submitting a form) to continue.
...
Twitter Bootstrap also includes a number of jQuery-based plugins; these will be exposed in the module system.
h1. Content Delivery Network Integration
Tapestry 5.3 has limited ability to integrate into a [content delivery network|http://en.wikipedia.org/wiki/Content_delivery_network]; it can dynamically rewrite URLs for assets (including _javascript_ libraries, CSS files, image files, etc.). However, it assumes that the CDN can pull the content, as needed, from the live site. A desirable feature would be request URL that would produce a JSON-formatted report of all assets that should be mirrored by the CDN: this would include all files that might be exposed to the browser, including virtual assets (such as _javascript_ stacks, aggregated modules, and so forth). This could be leveraged by a tool that would use this information to extract the assets from the live application and exported to the CDN. Determining what assets are available is somewhat problematic as Tapestry mixes server-side only resources (.class files, .tml files, etc.) freely with assets that might be exposed to the
