[ https://issues.apache.org/jira/browse/TAP5-945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12787747#action_12787747
]
Howard M. Lewis Ship commented on TAP5-945:
-------------------------------------------
As I mentioned on the mailing list, this addresses a bug that may still be present in Sun
JDK 1.5, that ThreadLocal is not fully thread safe (!) in some situations ... the kind of
situations that Tapestry hits.
This could be recoded in a couple of ways. We could use a configuration symbol or JVM system
property to enable/disable the synchronization. We could add a test for JDK 1.6 to disable
the synchronization. We could use a ReentrantReadWriteLock to allow shared readers (the common
case).
> 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
> Priority: Minor
>
> 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.
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
Priority: Minor
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.
[ https://issues.apache.org/jira/browse/TAP5-945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12787453#action_12787453
]
Olle Hallin commented on TAP5-945:
----------------------------------
We tested with 1000 virtual users and 300 Tomcat threads.
> 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
> Priority: Minor
>
> 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.
> The URL rewrite code instantiates LinkImpl's in a very ordinary way. > It uses relative paths when the rewritten URL belongs to the same > server as the original and a absolute one when the server name was > changed. I guess the problem, as you described, is how LinkImpl deals > with setting query parameters. I thought that maybe the URL rewiter should detect any already available parameters and add them again the usual way though addParameter. But I guess that comes down to personal preference. I like (as per your suggestion) the LinkImpl to be a bit more clever and fix the problem like in my patch. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org For additional commands, e-mail: dev-help@tapestry.apache.org
Em Tue, 08 Dec 2009 06:45:18 -0200, Joost Schouten (ml) <joost_ml@jsportal.com> escreveu: > That'd be great. Thanks a lot and keep me posted if another solution > would be preferable. I can imagine that maybe some work could be done on > the way the URL rewrite stuff instantiates the LinkImpl's. The URL rewrite code instantiates LinkImpl's in a very ordinary way. It uses relative paths when the rewritten URL belongs to the same server as the original and a absolute one when the server name was changed. I guess the problem, as you described, is how LinkImpl deals with setting query parameters. -- Thiago H. de Paula Figueiredo Independent Java, Apache Tapestry 5 and Hibernate consultant, developer, and instructor Owner, software architect and developer, Ars Machina Tecnologia da Informa豫o Ltda. http://www.arsmachina.com.br --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org For additional commands, e-mail: dev-help@tapestry.apache.org
[ https://issues.apache.org/jira/browse/TAP5-936?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ulrich St채rk updated TAP5-936:
------------------------------
Fix Version/s: 5.2.0.0
5.0.19
5.1.0.6
> Tapestry wiki link links to nothing for locales other then en
> -------------------------------------------------------------
>
> Key: TAP5-936
> URL: https://issues.apache.org/jira/browse/TAP5-936
> Project: Tapestry 5
> Issue Type: Bug
> Components: documentation
> Affects Versions: 5.2, 5.1.0.5, 5.0.18
> Reporter: Ulrich St채rk
> Assignee: Ulrich St채rk
> Priority: Minor
> Fix For: 5.2.0.0, 5.1.0.6, 5.0.19
>
> Original Estimate: 0h
> Remaining Estimate: 0h
>
> The wiki link should link explicitly to http://wiki.apache.org/tapestry/FrontPage, otherwise
MoinMoin will choose a start page according to the user's browser's locale which in my case
(de) leads to an empty page.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[ https://issues.apache.org/jira/browse/TAP5-936?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ulrich St채rk closed TAP5-936.
-----------------------------
Resolution: Fixed
> Tapestry wiki link links to nothing for locales other then en
> -------------------------------------------------------------
>
> Key: TAP5-936
> URL: https://issues.apache.org/jira/browse/TAP5-936
> Project: Tapestry 5
> Issue Type: Bug
> Components: documentation
> Affects Versions: 5.2, 5.1.0.5, 5.0.18
> Reporter: Ulrich St채rk
> Assignee: Ulrich St채rk
> Priority: Minor
> Fix For: 5.1.0.6, 5.0.19, 5.2.0.0
>
> Original Estimate: 0h
> Remaining Estimate: 0h
>
> The wiki link should link explicitly to http://wiki.apache.org/tapestry/FrontPage, otherwise
MoinMoin will choose a start page according to the user's browser's locale which in my case
(de) leads to an empty page.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Author: uli
Date: Tue Dec 8 09:27:07 2009
New Revision: 888299
URL: http://svn.apache.org/viewvc?rev=888299&view=rev
Log:
TAP5-936: Tapestry wiki link links to nothing for locales other then en
Modified:
tapestry/tapestry5/branches/5.0/src/site/site.xml
tapestry/tapestry5/branches/5.1.0.x-dev/src/site/site.xml
tapestry/tapestry5/trunk/src/site/site.xml
Modified: tapestry/tapestry5/branches/5.0/src/site/site.xml
URL: http://svn.apache.org/viewvc/tapestry/tapestry5/branches/5.0/src/site/site.xml?rev=888299&r1=888298&r2=888299&view=diff
==============================================================================
--- tapestry/tapestry5/branches/5.0/src/site/site.xml (original)
+++ tapestry/tapestry5/branches/5.0/src/site/site.xml Tue Dec 8 09:27:07 2009
@@ -124,7 +124,7 @@
</menu>
<menu name="Resources">
- <item name="Wiki" href="http://wiki.apache.org/tapestry"/>
+ <item name="Wiki" href="http://wiki.apache.org/tapestry/FrontPage"/>
<item name="Wiki HowTos" href="http://wiki.apache.org/tapestry/Tapestry5HowTos"/>
</menu>
Modified: tapestry/tapestry5/branches/5.1.0.x-dev/src/site/site.xml
URL: http://svn.apache.org/viewvc/tapestry/tapestry5/branches/5.1.0.x-dev/src/site/site.xml?rev=888299&r1=888298&r2=888299&view=diff
==============================================================================
--- tapestry/tapestry5/branches/5.1.0.x-dev/src/site/site.xml (original)
+++ tapestry/tapestry5/branches/5.1.0.x-dev/src/site/site.xml Tue Dec 8 09:27:07 2009
@@ -137,7 +137,7 @@
</menu>
<menu name="Resources">
- <item name="Wiki" href="http://wiki.apache.org/tapestry"/>
+ <item name="Wiki" href="http://wiki.apache.org/tapestry/FrontPage"/>
<item name="Wiki HowTos" href="http://wiki.apache.org/tapestry/Tapestry5HowTos"/>
</menu>
Modified: tapestry/tapestry5/trunk/src/site/site.xml
URL: http://svn.apache.org/viewvc/tapestry/tapestry5/trunk/src/site/site.xml?rev=888299&r1=888298&r2=888299&view=diff
==============================================================================
--- tapestry/tapestry5/trunk/src/site/site.xml (original)
+++ tapestry/tapestry5/trunk/src/site/site.xml Tue Dec 8 09:27:07 2009
@@ -138,7 +138,7 @@
</menu>
<menu name="Resources">
- <item name="Wiki" href="http://wiki.apache.org/tapestry"/>
+ <item name="Wiki" href="http://wiki.apache.org/tapestry/FrontPage"/>
<item name="Wiki HowTos" href="http://wiki.apache.org/tapestry/Tapestry5HowTos"/>
</menu>
[ https://issues.apache.org/jira/browse/TAP5-936?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ulrich St채rk updated TAP5-936:
------------------------------
Assignee: Ulrich St채rk
Affects Version/s: (was: 5.2.0.0)
5.2
Remaining Estimate: 0h
Original Estimate: 0h
> Tapestry wiki link links to nothing for locales other then en
> -------------------------------------------------------------
>
> Key: TAP5-936
> URL: https://issues.apache.org/jira/browse/TAP5-936
> Project: Tapestry 5
> Issue Type: Bug
> Components: documentation
> Affects Versions: 5.2, 5.1.0.5, 5.0.18
> Reporter: Ulrich St채rk
> Assignee: Ulrich St채rk
> Priority: Minor
> Original Estimate: 0h
> Remaining Estimate: 0h
>
> The wiki link should link explicitly to http://wiki.apache.org/tapestry/FrontPage, otherwise
MoinMoin will choose a start page according to the user's browser's locale which in my case
(de) leads to an empty page.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
That'd be great. Thanks a lot and keep me posted if another solution would be preferable. I can imagine that maybe some work could be done on the way the URL rewrite stuff instantiates the LinkImpl's. Cheers, Joost Robert Zeigler wrote: > I'll take a look at it, once I've closed my other ticket(s). > > Robert > > On Dec 5, 2009, at 12/59:00 AM , Joost Schouten (ml) wrote: > >> Hi, >> >> Could one of the comitters have a look at the provided patch at: >> https://issues.apache.org/jira/browse/TAP5-937 ? >> >> Is it possible to get it included in T5.2.0-SNAPSHOT? It would remove >> the need for me to build a custom version on every version update or >> new developer deploy. And not to forget, it fixes a bug ;-) >> >> Cheers, >> Joost >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org >> For additional commands, e-mail: dev-help@tapestry.apache.org > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org > For additional commands, e-mail: dev-help@tapestry.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org For additional commands, e-mail: dev-help@tapestry.apache.org
[ https://issues.apache.org/jira/browse/TAP5-937?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joost Schouten updated TAP5-937:
--------------------------------
Attachment: parameter_addition_patch.txt
patch checks if the baseURI already contains a '?', if so start adding the new params with
an '&', otherwise start with a '?'. Also added a test for a situation where a base URI
with parameters on the path in instantiated.
> LinkImpl does not handle parameters propery when passed into the constructor
> ----------------------------------------------------------------------------
>
> Key: TAP5-937
> URL: https://issues.apache.org/jira/browse/TAP5-937
> Project: Tapestry 5
> Issue Type: Bug
> Components: tapestry-core
> Affects Versions: 5.1
> Reporter: Joost Schouten
> Attachments: parameter_addition_patch.txt
>
>
> I noticed this after using the AjaxFormLoop AddRowLink on a page which has an onActivate
and onPassivate resulting in the addition of a "t:ac" to the url. Debugging showed me that
the t:ac is already present on instantiation of the LinkImpl. When calling toAbsoluteUri the
parameters are added in a way where they will always start with a "?". Obvisouly resulting
in an invalid URL with two ?'s
> I'm building a failing test at this stage and will provide a patch once resolved.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[ https://issues.apache.org/jira/browse/TAP5-937?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joost Schouten updated TAP5-937:
--------------------------------
Attachment: (was: parameter_addition_patch.txt)
> LinkImpl does not handle parameters propery when passed into the constructor
> ----------------------------------------------------------------------------
>
> Key: TAP5-937
> URL: https://issues.apache.org/jira/browse/TAP5-937
> Project: Tapestry 5
> Issue Type: Bug
> Components: tapestry-core
> Affects Versions: 5.1
> Reporter: Joost Schouten
>
> I noticed this after using the AjaxFormLoop AddRowLink on a page which has an onActivate
and onPassivate resulting in the addition of a "t:ac" to the url. Debugging showed me that
the t:ac is already present on instantiation of the LinkImpl. When calling toAbsoluteUri the
parameters are added in a way where they will always start with a "?". Obvisouly resulting
in an invalid URL with two ?'s
> I'm building a failing test at this stage and will provide a patch once resolved.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
The bottom-up search for messages is how Tapestry is looking for translations now. But the problem is that we are talking about replacing existing translation. Tapestry stops searching when the component's message catalog contains a particular key. You need somehow to tell Tapestry to continue searching even if the key is already found. So what is the most elegant way to do it? Howard suggested to add a parameter of the types Messages to all the components, right? In this case a user is responsible to for constructing the message instance that is bound into the component's parameter. What I'm proposing is the similar solution how ValidationMessagesSource is working. You just override the path to the message catalog of the component. That's it. On Tue, Dec 8, 2009 at 5:04 AM, Robert Zeigler <robertz@scazdl.org> wrote: > Unless you put the definitions in your application's app.properties, right? > Then you still have to provide the custom resources component-by-component, > but the translations go in a single place. > > Robert > > > On Dec 7, 2009, at 12/75:53 PM , Igor Drobiazko wrote: > > Hm, what about components that are used in several pages? In this case I >> have to repeat the translations again and again. >> >> On Sun, Dec 6, 2009 at 9:02 PM, Howard Lewis Ship <hlship@gmail.com> >> wrote: >> >> Perhaps what's really needed is for components to more frequently have >>> a parameter used to override its internal messages with a new messages >>> object (presumably form the page). >>> >>> On Thu, Dec 3, 2009 at 8:52 AM, Massimo Lusetti <mlusetti@gmail.com> >>> wrote: >>> >>>> On Thu, Dec 3, 2009 at 7:52 AM, Igor Drobiazko < >>>> igor.drobiazko@gmail.com> >>>> >>> wrote: >>> >>>> >>>> I accompiished this by a service named ComponentMessagesOverride. The >>>>> >>>> mapped >>> >>>> configuration of the service is used to contribute new paths for >>>>> >>>> component >>> >>>> message catalogs. This service is used in an advise method to override >>>>> >>>> the >>> >>>> result of ComponentMessagesSource#getMessages. This temporary hack is ok >>>>> >>>> for >>> >>>> an application but what is the benefit to do it in tapestry-core? We can >>>>> change the implementation of ComponentMessagesSource directly. >>>>> >>>> >>>> While here I would like to pose to your attention a use case where i >>>> found myself repeatedly. >>>> >>>> It happens that I produce a "common" components (like a series of >>>> Submit components acting togheter) where i want the pages that use it >>>> to provide the "messages" for labels. So this could be accomplish by >>>> extending the inheritance of the message catalog from components to >>>> pages that include the components (or other components as well) to >>>> application wide catalog. >>>> >>>> So for instance a components could provide defaults labels but pages >>>> are given the opportunity to override it while leave the "application >>>> wide" message catalog to have the last word on it. >>>> >>>> Does it sounds reasonable? >>>> >>>> Cheers >>>> -- >>>> Massimo >>>> http://meridio.blogspot.com >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org >>>> For additional commands, e-mail: dev-help@tapestry.apache.org >>>> >>>> >>>> >>> >>> >>> -- >>> Howard M. Lewis Ship >>> >>> Creator of Apache Tapestry >>> >>> The source for Tapestry training, mentoring and support. Contact me to >>> learn how I can get you up and productive in Tapestry fast! >>> >>> (971) 678-5210 >>> http://howardlewisship.com >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org >>> For additional commands, e-mail: dev-help@tapestry.apache.org >>> >>> >>> >> >> -- >> Best regards, >> >> Igor Drobiazko >> http://tapestry5.de/blog >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org > For additional commands, e-mail: dev-help@tapestry.apache.org > > -- Best regards, Igor Drobiazko http://tapestry5.de/blog
I'll take a look at it, once I've closed my other ticket(s). Robert On Dec 5, 2009, at 12/59:00 AM , Joost Schouten (ml) wrote: > Hi, > > Could one of the comitters have a look at the provided patch at: https://issues.apache.org/jira/browse/TAP5-937 > ? > > Is it possible to get it included in T5.2.0-SNAPSHOT? It would > remove the need for me to build a custom version on every version > update or new developer deploy. And not to forget, it fixes a bug ;-) > > Cheers, > Joost > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org > For additional commands, e-mail: dev-help@tapestry.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org For additional commands, e-mail: dev-help@tapestry.apache.org
Unless you put the definitions in your application's app.properties, right? Then you still have to provide the custom resources component- by-component, but the translations go in a single place. Robert On Dec 7, 2009, at 12/75:53 PM , Igor Drobiazko wrote: > Hm, what about components that are used in several pages? In this > case I > have to repeat the translations again and again. > > On Sun, Dec 6, 2009 at 9:02 PM, Howard Lewis Ship <hlship@gmail.com> > wrote: > >> Perhaps what's really needed is for components to more frequently >> have >> a parameter used to override its internal messages with a new >> messages >> object (presumably form the page). >> >> On Thu, Dec 3, 2009 at 8:52 AM, Massimo Lusetti <mlusetti@gmail.com> >> wrote: >>> On Thu, Dec 3, 2009 at 7:52 AM, Igor Drobiazko <igor.drobiazko@gmail.com >>> > >> wrote: >>> >>>> I accompiished this by a service named ComponentMessagesOverride. >>>> The >> mapped >>>> configuration of the service is used to contribute new paths for >> component >>>> message catalogs. This service is used in an advise method to >>>> override >> the >>>> result of ComponentMessagesSource#getMessages. This temporary >>>> hack is ok >> for >>>> an application but what is the benefit to do it in tapestry-core? >>>> We can >>>> change the implementation of ComponentMessagesSource directly. >>> >>> While here I would like to pose to your attention a use case where i >>> found myself repeatedly. >>> >>> It happens that I produce a "common" components (like a series of >>> Submit components acting togheter) where i want the pages that use >>> it >>> to provide the "messages" for labels. So this could be accomplish by >>> extending the inheritance of the message catalog from components to >>> pages that include the components (or other components as well) to >>> application wide catalog. >>> >>> So for instance a components could provide defaults labels but pages >>> are given the opportunity to override it while leave the >>> "application >>> wide" message catalog to have the last word on it. >>> >>> Does it sounds reasonable? >>> >>> Cheers >>> -- >>> Massimo >>> http://meridio.blogspot.com >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org >>> For additional commands, e-mail: dev-help@tapestry.apache.org >>> >>> >> >> >> >> -- >> Howard M. Lewis Ship >> >> Creator of Apache Tapestry >> >> The source for Tapestry training, mentoring and support. Contact me >> to >> learn how I can get you up and productive in Tapestry fast! >> >> (971) 678-5210 >> http://howardlewisship.com >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org >> For additional commands, e-mail: dev-help@tapestry.apache.org >> >> > > > -- > Best regards, > > Igor Drobiazko > http://tapestry5.de/blog --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org For additional commands, e-mail: dev-help@tapestry.apache.org
Hm, what about components that are used in several pages? In this case I have to repeat the translations again and again. On Sun, Dec 6, 2009 at 9:02 PM, Howard Lewis Ship <hlship@gmail.com> wrote: > Perhaps what's really needed is for components to more frequently have > a parameter used to override its internal messages with a new messages > object (presumably form the page). > > On Thu, Dec 3, 2009 at 8:52 AM, Massimo Lusetti <mlusetti@gmail.com> > wrote: > > On Thu, Dec 3, 2009 at 7:52 AM, Igor Drobiazko <igor.drobiazko@gmail.com> > wrote: > > > >> I accompiished this by a service named ComponentMessagesOverride. The > mapped > >> configuration of the service is used to contribute new paths for > component > >> message catalogs. This service is used in an advise method to override > the > >> result of ComponentMessagesSource#getMessages. This temporary hack is ok > for > >> an application but what is the benefit to do it in tapestry-core? We can > >> change the implementation of ComponentMessagesSource directly. > > > > While here I would like to pose to your attention a use case where i > > found myself repeatedly. > > > > It happens that I produce a "common" components (like a series of > > Submit components acting togheter) where i want the pages that use it > > to provide the "messages" for labels. So this could be accomplish by > > extending the inheritance of the message catalog from components to > > pages that include the components (or other components as well) to > > application wide catalog. > > > > So for instance a components could provide defaults labels but pages > > are given the opportunity to override it while leave the "application > > wide" message catalog to have the last word on it. > > > > Does it sounds reasonable? > > > > Cheers > > -- > > Massimo > > http://meridio.blogspot.com > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org > > For additional commands, e-mail: dev-help@tapestry.apache.org > > > > > > > > -- > Howard M. Lewis Ship > > Creator of Apache Tapestry > > The source for Tapestry training, mentoring and support. Contact me to > learn how I can get you up and productive in Tapestry fast! > > (971) 678-5210 > http://howardlewisship.com > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org > For additional commands, e-mail: dev-help@tapestry.apache.org > > -- Best regards, Igor Drobiazko http://tapestry5.de/blog
Congrats! On Mon, Dec 7, 2009 at 10:31 AM, <uli@apache.org> wrote: > Author: uli > Date: Mon Dec �7 18:31:35 2009 > New Revision: 888068 > > URL: http://svn.apache.org/viewvc?rev=888068&view=rev > Log: > Add myself (Ulrich St�rk) to the committers lists. > > Modified: > � 쟴apestry/tapestry-site/trunk/pom.xml > � 쟴apestry/tapestry-site/trunk/src/site/xdoc/committers.xml > � 쟴apestry/tapestry5/trunk/pom.xml > > Modified: tapestry/tapestry-site/trunk/pom.xml > URL: http://svn.apache.org/viewvc/tapestry/tapestry-site/trunk/pom.xml?rev=888068&r1=888067&r2=888068&view=diff > ============================================================================== > --- tapestry/tapestry-site/trunk/pom.xml (original) > +++ tapestry/tapestry-site/trunk/pom.xml Mon Dec �7 18:31:35 2009 > @@ -168,6 +168,15 @@ > � � � � � � </roles> > � � � � � � <timezone>-3</timezone> > � � � � </developer> > + � � � �<developer> > + � � � � � �<id>uli</id> > + � � � � � �<name>Ulrich Stärk</name> > + � � � � � �<email>uli@apache.org</email> > + � � � � � �<roles> > + � � � � � � � �<role>Developer</role> > + � � � � � �</roles> > + � � � � � �<timezone>+1</timezone> > + � � � �</developer> > � � </developers> > > � � <distributionManagement> > > Modified: tapestry/tapestry-site/trunk/src/site/xdoc/committers.xml > URL: http://svn.apache.org/viewvc/tapestry/tapestry-site/trunk/src/site/xdoc/committers.xml?rev=888068&r1=888067&r2=888068&view=diff > ============================================================================== > --- tapestry/tapestry-site/trunk/src/site/xdoc/committers.xml (original) > +++ tapestry/tapestry-site/trunk/src/site/xdoc/committers.xml Mon Dec �7 18:31:35 2009 > @@ -73,6 +73,12 @@ > � � � � � � � � � � <td>May 2007</td> > � � � � � � � � � � <td/> > � � � � � � � � </tr> > + � � � � � � � �<tr> > + � � � � � � � � � �<td>Ulrich St채rk</td> > + � � � � � � � � � �<td>-</td> > + � � � � � � � � � �<td>Nov 2009</td> > + � � � � � � � � � �<td/> > + � � � � � � � �</tr> > > � � � � � � � � <tr> > � � � � � � � � � � <td>Brian K. Wallace</td> > > Modified: tapestry/tapestry5/trunk/pom.xml > URL: http://svn.apache.org/viewvc/tapestry/tapestry5/trunk/pom.xml?rev=888068&r1=888067&r2=888068&view=diff > ============================================================================== > --- tapestry/tapestry5/trunk/pom.xml (original) > +++ tapestry/tapestry5/trunk/pom.xml Mon Dec �7 18:31:35 2009 > @@ -113,6 +113,15 @@ > � � � � � � </roles> > � � � � � � <timezone>-3</timezone> > � � � � </developer> > + � � � �<developer> > + � � � � � �<id>uli</id> > + � � � � � �<name>Ulrich Stärk</name> > + � � � � � �<email>uli@apache.org</email> > + � � � � � �<roles> > + � � � � � � � �<role>Developer</role> > + � � � � � �</roles> > + � � � � � �<timezone>+1</timezone> > + � � � �</developer> > � � </developers> > > � � <ciManagement> > > > -- Howard M. Lewis Ship Creator of Apache Tapestry The source for Tapestry training, mentoring and support. Contact me to learn how I can get you up and productive in Tapestry fast! (971) 678-5210 http://howardlewisship.com --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org For additional commands, e-mail: dev-help@tapestry.apache.org
[ https://issues.apache.org/jira/browse/TAP5-813?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ulrich St채rk closed TAP5-813.
-----------------------------
Resolution: Fixed
> the component rendering page of the user guide is not generated by maven
> ------------------------------------------------------------------------
>
> Key: TAP5-813
> URL: https://issues.apache.org/jira/browse/TAP5-813
> Project: Tapestry 5
> Issue Type: Bug
> Components: documentation
> Affects Versions: 5.2
> Reporter: Ulrich St채rk
> Assignee: Ulrich St채rk
> Priority: Minor
> Fix For: 5.2.0.0
>
> Attachments: TAP5-813.txt
>
> Original Estimate: 0h
> Remaining Estimate: 0h
>
> Due to missing braces, maven does not generate the component rendering page ot the user
guide.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[ https://issues.apache.org/jira/browse/TAP5-813?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ulrich St채rk updated TAP5-813:
------------------------------
Fix Version/s: 5.2.0.0
Remaining Estimate: 0h
Original Estimate: 0h
> the component rendering page of the user guide is not generated by maven
> ------------------------------------------------------------------------
>
> Key: TAP5-813
> URL: https://issues.apache.org/jira/browse/TAP5-813
> Project: Tapestry 5
> Issue Type: Bug
> Components: documentation
> Affects Versions: 5.2
> Reporter: Ulrich St채rk
> Assignee: Ulrich St채rk
> Priority: Minor
> Fix For: 5.2.0.0
>
> Attachments: TAP5-813.txt
>
> Original Estimate: 0h
> Remaining Estimate: 0h
>
> Due to missing braces, maven does not generate the component rendering page ot the user
guide.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Author: uli
Date: Mon Dec 7 19:54:17 2009
New Revision: 888110
URL: http://svn.apache.org/viewvc?rev=888110&view=rev
Log:
TAP5-813: the component rendering page of the user guide is not generated by maven
Modified:
tapestry/tapestry5/trunk/src/site/apt/guide/rendering.apt
Modified: tapestry/tapestry5/trunk/src/site/apt/guide/rendering.apt
URL: http://svn.apache.org/viewvc/tapestry/tapestry5/trunk/src/site/apt/guide/rendering.apt?rev=888110&r1=888109&r2=888110&view=diff
==============================================================================
--- tapestry/tapestry5/trunk/src/site/apt/guide/rendering.apt (original)
+++ tapestry/tapestry5/trunk/src/site/apt/guide/rendering.apt Mon Dec 7 19:54:17 2009
@@ -295,7 +295,7 @@
The order in which the mixins of a given class (@MixinAfter or mixins before) execute is
determined
by the ordering constraints specified for the mixins. If no constrains are provided, the
order is undefined.
- See {{{mixins.html}component mixins} for more details.
+ See {{{mixins.html}component mixins}} for more details.
* Parents before Child
[ https://issues.apache.org/jira/browse/TAP5-813?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ulrich St채rk reassigned TAP5-813:
---------------------------------
Assignee: Ulrich St채rk
> the component rendering page of the user guide is not generated by maven
> ------------------------------------------------------------------------
>
> Key: TAP5-813
> URL: https://issues.apache.org/jira/browse/TAP5-813
> Project: Tapestry 5
> Issue Type: Bug
> Components: documentation
> Affects Versions: 5.2
> Reporter: Ulrich St채rk
> Assignee: Ulrich St채rk
> Priority: Minor
> Attachments: TAP5-813.txt
>
>
> Due to missing braces, maven does not generate the component rendering page ot the user
guide.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Author: uli
Date: Mon Dec 7 18:31:35 2009
New Revision: 888068
URL: http://svn.apache.org/viewvc?rev=888068&view=rev
Log:
Add myself (Ulrich St채rk) to the committers lists.
Modified:
tapestry/tapestry-site/trunk/pom.xml
tapestry/tapestry-site/trunk/src/site/xdoc/committers.xml
tapestry/tapestry5/trunk/pom.xml
Modified: tapestry/tapestry-site/trunk/pom.xml
URL: http://svn.apache.org/viewvc/tapestry/tapestry-site/trunk/pom.xml?rev=888068&r1=888067&r2=888068&view=diff
==============================================================================
--- tapestry/tapestry-site/trunk/pom.xml (original)
+++ tapestry/tapestry-site/trunk/pom.xml Mon Dec 7 18:31:35 2009
@@ -168,6 +168,15 @@
</roles>
<timezone>-3</timezone>
</developer>
+ <developer>
+ <id>uli</id>
+ <name>Ulrich Stärk</name>
+ <email>uli@apache.org</email>
+ <roles>
+ <role>Developer</role>
+ </roles>
+ <timezone>+1</timezone>
+ </developer>
</developers>
<distributionManagement>
Modified: tapestry/tapestry-site/trunk/src/site/xdoc/committers.xml
URL: http://svn.apache.org/viewvc/tapestry/tapestry-site/trunk/src/site/xdoc/committers.xml?rev=888068&r1=888067&r2=888068&view=diff
==============================================================================
--- tapestry/tapestry-site/trunk/src/site/xdoc/committers.xml (original)
+++ tapestry/tapestry-site/trunk/src/site/xdoc/committers.xml Mon Dec 7 18:31:35 2009
@@ -73,6 +73,12 @@
<td>May 2007</td>
<td/>
</tr>
+ <tr>
+ <td>Ulrich St횄짚rk</td>
+ <td>-</td>
+ <td>Nov 2009</td>
+ <td/>
+ </tr>
<tr>
<td>Brian K. Wallace</td>
Modified: tapestry/tapestry5/trunk/pom.xml
URL: http://svn.apache.org/viewvc/tapestry/tapestry5/trunk/pom.xml?rev=888068&r1=888067&r2=888068&view=diff
==============================================================================
--- tapestry/tapestry5/trunk/pom.xml (original)
+++ tapestry/tapestry5/trunk/pom.xml Mon Dec 7 18:31:35 2009
@@ -113,6 +113,15 @@
</roles>
<timezone>-3</timezone>
</developer>
+ <developer>
+ <id>uli</id>
+ <name>Ulrich Stärk</name>
+ <email>uli@apache.org</email>
+ <roles>
+ <role>Developer</role>
+ </roles>
+ <timezone>+1</timezone>
+ </developer>
</developers>
<ciManagement>
On Sun, Dec 6, 2009 at 9:02 PM, Howard Lewis Ship <hlship@gmail.com> wrote: > Perhaps what's really needed is for components to more frequently have > a parameter used to override its internal messages with a new messages > object (presumably form the page). Yep, that should be the solution if not limited to the containing page but extended to all "containing components". Do you like a Jira issue about this one? Cheers -- Massimo http://meridio.blogspot.com --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org For additional commands, e-mail: dev-help@tapestry.apache.org
Perhaps what's really needed is for components to more frequently have a parameter used to override its internal messages with a new messages object (presumably form the page). On Thu, Dec 3, 2009 at 8:52 AM, Massimo Lusetti <mlusetti@gmail.com> wrote: > On Thu, Dec 3, 2009 at 7:52 AM, Igor Drobiazko <igor.drobiazko@gmail.com> wrote: > >> I accompiished this by a service named ComponentMessagesOverride. The mapped >> configuration of the service is used to contribute new paths for component >> message catalogs. This service is used in an advise method to override the >> result of ComponentMessagesSource#getMessages. This temporary hack is ok for >> an application but what is the benefit to do it in tapestry-core? We can >> change the implementation of ComponentMessagesSource directly. > > While here I would like to pose to your attention a use case where i > found myself repeatedly. > > It happens that I produce a "common" components (like a series of > Submit components acting togheter) where i want the pages that use it > to provide the "messages" for labels. So this could be accomplish by > extending the inheritance of the message catalog from components to > pages that include the components (or other components as well) to > application wide catalog. > > So for instance a components could provide defaults labels but pages > are given the opportunity to override it while leave the "application > wide" message catalog to have the last word on it. > > Does it sounds reasonable? > > Cheers > -- > Massimo > http://meridio.blogspot.com > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org > For additional commands, e-mail: dev-help@tapestry.apache.org > > -- Howard M. Lewis Ship Creator of Apache Tapestry The source for Tapestry training, mentoring and support. Contact me to learn how I can get you up and productive in Tapestry fast! (971) 678-5210 http://howardlewisship.com --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org For additional commands, e-mail: dev-help@tapestry.apache.org
[ https://issues.apache.org/jira/browse/TAP5-840?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robin Komiwes updated TAP5-840:
-------------------------------
Attachment: patch.txt
As I needed HTML5 for some projects, I made the fix.
I've explored many ways, such as DTDOverriding , custom external entity resolving...Without
success. I also tried to use TemplateParserImpl.resolveEntity() and to add a hack for HTML5
like it's made for HTML4. But still no success.
Finally, I tried with XMLInputFactory.IS_REPLACING_ENTITY_REFERENCES property set to false
, a new TemplateToken implementation for entities, and it works.
Now, every entities, with or without a doctype set, are now simply output "as it".
I created a new symbol to offer the possibility to go back to the old system.
PFA the patch with tests.
> Support character references in tml files with HTML 5 Doctype
> -------------------------------------------------------------
>
> Key: TAP5-840
> URL: https://issues.apache.org/jira/browse/TAP5-840
> Project: Tapestry 5
> Issue Type: Improvement
> Components: tapestry-core
> Affects Versions: 5.0.18
> Reporter: Ben Gidley
> Attachments: patch.txt
>
>
> Currently to support HTML character references (e.g. ©) you need to put a HTML
Doctype at the top of the TML file.
> e.g. <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
> However for HTML 5 they have stopped using XML doctypes and instead use
> <!DOCTYPE html>
> If you change tapestry page to use this you can no longer use entities as the XML parser
doesn't know what to do.
> Ideally there should be some kind of logic that detects <!DOCTYPE html> and include
a suitable DTD to resolve the common HTML entities. The HTML 5 specification defines the allowed
named character references - http://dev.w3.org/html5/spec/Overview.html#named-character-references.
There doesn't seem to be a DTD of allowed references maintained anymore.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Hi, Could one of the comitters have a look at the provided patch at: https://issues.apache.org/jira/browse/TAP5-937 ? Is it possible to get it included in T5.2.0-SNAPSHOT? It would remove the need for me to build a custom version on every version update or new developer deploy. And not to forget, it fixes a bug ;-) Cheers, Joost --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org For additional commands, e-mail: dev-help@tapestry.apache.org
On Fri, Dec 4, 2009 at 7:37 AM, Igor Drobiazko <igor.drobiazko@gmail.com> wrote: > This would be a nice addition but does not solve the problem. Components are > reusable and their message catalog should be reusable too. I don't want to > provide messages for a component in every page using it. What is needed is > just a "redirect" to another package to look for message catalog. As you said it would be an addition so an extension like system... > Now the messages are searched in a low-specific to a most-specific order. If > a component message catalog contains an entry for a particular key the > application wide catalog will be never considered. So you don't have any > chance to override existing translations of a component. For backward > compatibility reasons this behavior should not be changed. Well even i perfectly understand the "backward compatibilty" shield effect i think that some thoughts should be deserved to such an option. Cheers -- Massimo http://meridio.blogspot.com --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org For additional commands, e-mail: dev-help@tapestry.apache.org
[ https://issues.apache.org/jira/browse/TAP5-445?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12785963#action_12785963
]
Gabriel Falkenberg commented on TAP5-445:
-----------------------------------------
Just so that people finding this page via Google has something to copy/paste to turn off GZIP-compression
in their Tapestry 5 apps:
public static void contributeApplicationDefaults(MappedConfiguration<String, String>
configuration)
{
configuration.add(SymbolConstants.GZIP_COMPRESSION_ENABLED, "false");
}
> Add ability to turn off GZIP compression easily, for both static assets and dynamic page
renders
> ------------------------------------------------------------------------------------------------
>
> Key: TAP5-445
> URL: https://issues.apache.org/jira/browse/TAP5-445
> Project: Tapestry 5
> Issue Type: Improvement
> Components: tapestry-core
> Affects Versions: 5.1.0.0
> Reporter: Fernando
> Assignee: Howard M. Lewis Ship
> Fix For: 5.1.0.0
>
>
> I have to report a huge regression because of Tapestry Compression.
> I just tried running with the latest tapestry and it worked just fine most of the time
( going against browsers ), but we interact with the Facebook proxy, and it looks like they
got totally confused with the tapestry compression support, thus they would only serve up
an error page. Luckily, with Tapestry's new configuration override feature (thank you howard),
I was able to turn it off easily, and have my app working again.
> public void contributeHttpServletRequestHandler( OrderedConfiguration<HttpServletRequestFilter>
configuration ) {
> configuration.override( "GZIP", null );
> }
> So I wanted to report this regression, it might be the case that I'm the only one affected,
but we don't for sure, and probably people will never realize why it doesn't work. I don't
know if any other issues might arise from tapestry-compression, but I will want to make sure
I can turn the feature off as I need to.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
> > While here I would like to pose to your attention a use case where i > found myself repeatedly. > > It happens that I produce a "common" components (like a series of > Submit components acting togheter) where i want the pages that use it > to provide the "messages" for labels. So this could be accomplish by > extending the inheritance of the message catalog from components to > pages that include the components (or other components as well) to > application wide catalog. > This would be a nice addition but does not solve the problem. Components are reusable and their message catalog should be reusable too. I don't want to provide messages for a component in every page using it. What is needed is just a "redirect" to another package to look for message catalog. > > So for instance a components could provide defaults labels but pages > are given the opportunity to override it while leave the "application > wide" message catalog to have the last word on it. > Now the messages are searched in a low-specific to a most-specific order. If a component message catalog contains an entry for a particular key the application wide catalog will be never considered. So you don't have any chance to override existing translations of a component. For backward compatibility reasons this behavior should not be changed. > > Does it sounds reasonable? > > Cheers > -- > Massimo > http://meridio.blogspot.com > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org > For additional commands, e-mail: dev-help@tapestry.apache.org > > -- Best regards, Igor Drobiazko http://tapestry5.de/blog
> > Perhaps someone will create a good Apache-specific cheat sheet. I would appreciate, use, and help revise such a document. With medium-sized or large contributions, I prefer to structure things as a series of small patches rather than a single mondo patch -- that way, the contribution is easier for other community members to review. I haven't yet found the time to get past git's initial learning curve, but from what I understand, git-svn would make that workflow simpler. First hint: Depending on how git was installed, git-svn may not be in your path. If git-svn is available but not accessible, "git svn" may work instead. (This is the situation if you use the current version of <http://code.google.com/p/git-osx-installer/>.) Marvin Humphrey --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org For additional commands, e-mail: dev-help@tapestry.apache.org
I meant to reply to the list. On Thu, Dec 3, 2009 at 8:28 AM, Doug Cutting <cutting@apache.org> wrote: > Howard Lewis Ship wrote: >> >> If you haven't used Git extensively, you should try it. > > I have tried it. 쟅t is fast, but I couldn't manage to get it to work > seamlessly in my workflow, keeping a branch per patch, re-syncing these with > trunk, and using git-svn to commit a branch back to trunk. 쟊ike Eclipse, it > would probably make my life easier in the long run once I got over the > learning hump, but I've not had the time to do so. 쟑erhaps someone will > create a good Apache-specific cheat sheet. > > (Did you mean to reply to the list or not?) > > Doug > -- Howard M. Lewis Ship Creator of Apache Tapestry The source for Tapestry training, mentoring and support. Contact me to learn how I can get you up and productive in Tapestry fast! (971) 678-5210 http://howardlewisship.com --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org For additional commands, e-mail: dev-help@tapestry.apache.org
On Thu, Dec 3, 2009 at 7:52 AM, Igor Drobiazko <igor.drobiazko@gmail.com> wrote: > I accompiished this by a service named ComponentMessagesOverride. The mapped > configuration of the service is used to contribute new paths for component > message catalogs. This service is used in an advise method to override the > result of ComponentMessagesSource#getMessages. This temporary hack is ok for > an application but what is the benefit to do it in tapestry-core? We can > change the implementation of ComponentMessagesSource directly. While here I would like to pose to your attention a use case where i found myself repeatedly. It happens that I produce a "common" components (like a series of Submit components acting togheter) where i want the pages that use it to provide the "messages" for labels. So this could be accomplish by extending the inheritance of the message catalog from components to pages that include the components (or other components as well) to application wide catalog. So for instance a components could provide defaults labels but pages are given the opportunity to override it while leave the "application wide" message catalog to have the last word on it. Does it sounds reasonable? Cheers -- Massimo http://meridio.blogspot.com --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org For additional commands, e-mail: dev-help@tapestry.apache.org
[ https://issues.apache.org/jira/browse/TAP5-930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12785233#action_12785233
]
Peter Rietzler commented on TAP5-930:
-------------------------------------
Here is a simple tml that shows the problem
- clicking on the button triggers the correct behavior -> two messages 'onsubmit' and 'onsubmit
from event handler'
- clicking on the link triggers only one message -> 'onsubmit' (any other event handlers
are not executed because in LinkSubmit.js only onsubmit is executed)
<html xmlns:t="http://tapestry.apache.org/schema/tapestry_5_1_0.xsd" xmlns:p="tapestry:parameter"
>
<body>
<t:form id="form" onsubmit="alert('onsubmit')">
<t:linkSubmit>Submit Form</t:linkSubmit>
<t:submit/>
</t:form>
<script type="text/javascript">
$("form").addEventListener("submit", function() {
alert('onsubmit from event handler');
}, false);
</script>
</body>
</html>
> linksubmit does not fire sumbit event in 5.1.0.5
> ------------------------------------------------
>
> Key: TAP5-930
> URL: https://issues.apache.org/jira/browse/TAP5-930
> Project: Tapestry 5
> Issue Type: Bug
> Affects Versions: 5.1
> Environment: java 1.6
> windows 7
> tapestry 5.1.0.5
> firefox 3.5 or google chrome
> Reporter: Sergey Kashin
> Priority: Critical
> Attachments: linksubmit.js
>
>
> linksubmit does not fire sumbit form
> where is no any action
> if i change linksubmit to submit buttom all works fine
> Template:
> ----------------------------------------------------------------------------------
> <?xml version="1.0" encoding="windows-1251"?>
> <html xmlns:t="http://tapestry.apache.org/schema/tapestry_5_0_0.xsd" xmlns:p="tapestry:parameter">
> <t:form t:id="frm" >
> <t:textfield value="txt"></t:textfield><br/>
> <t:linksubmit t:id="save" >Save</t:linksubmit> . <t:linksubmit
t:id="cancel" >Cancel</t:linksubmit>
> </t:form>
> </html>
> ----------------------------------------------------------------------------------
> java code:
> ----------------------------------------------------------------------------------
> private Object formEventReturn;
> @Property
> private String txt;
> void onSelectedFromSave() {
> // do whatever;
> formEventReturn = Index.class; // go to AnotherPage
> }
> void onSelectedFromCancel() {
> // do whatever
> formEventReturn = null; // stay on this page
> }
> Object onSuccessFromFrm() {
> //do things specific to form Foo
> return formEventReturn;
> }
> ----------------------------------------------------------------------------------
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
I accompiished this by a service named ComponentMessagesOverride. The mapped
configuration of the service is used to contribute new paths for component
message catalogs. This service is used in an advise method to override the
result of ComponentMessagesSource#getMessages. This temporary hack is ok for
an application but what is the benefit to do it in tapestry-core? We can
change the implementation of ComponentMessagesSource directly.
On Wed, Dec 2, 2009 at 11:54 PM, Howard Lewis Ship <hlship@gmail.com> wrote:
> This is something I've been meaning to look at as well. I'd like to
> check what I've done for my client to see what I had to hack to
> accomplish this, to ensure that we don't go through a couple of cycles
> of this. I'm working for that client tomorrow, so I'll document that's
> needed then.
>
> I think the entire approach needs to be a bit more pluggable (though
> decorating the service is also an option).
>
>
> On Wed, Dec 2, 2009 at 12:59 PM, Igor Drobiazko
> <igor.drobiazko@gmail.com> wrote:
> > I would like to fix TAP5-915 and have to make ComponentMessagesSource a
> part
> > of the public API. I know we should be reluctant to move services from
> > internal packages but this feature is a must. Tapestry allows you to
> > override almost every part of the framework, but not the message catalog
> of
> > the components. Do you have any objections?
> >
> > The idea is to provide a mapped configuration for the service in which a
> > component class is mapped to a path. In the following example the message
> > catalog of DateField is obtained from foo/bar/baz and not from
> > /org/apache/tapestry5/corelib/components
> >
> > public void
> > contributeComponentMessagesSource(MappedConfiguration<Class,String>
> > configuration)
> > {
> > configuration.add(DateField.class, "/foo/bar/baz");
> > }
> >
> > --
> > Best regards,
> >
> > Igor Drobiazko
> > http://tapestry5.de/blog
> >
>
>
>
> --
> Howard M. Lewis Ship
>
> Creator of Apache Tapestry
>
> The source for Tapestry training, mentoring and support. Contact me to
> learn how I can get you up and productive in Tapestry fast!
>
> (971) 678-5210
> http://howardlewisship.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>
--
Best regards,
Igor Drobiazko
http://tapestry5.de/blog
[ https://issues.apache.org/jira/browse/TAP5-815?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12785188#action_12785188
]
Geoff Callender commented on TAP5-815:
--------------------------------------
Hey Robert,
I haven't had a chance to review the AssetProtectionDispatcher, but can you confirm its default
setup matches the following bits of the servlet spec? I think the servlet spec describes the
behaviour that developers would reasonably expect, regardless of the fact that T5 doesn't
use servlets.
1. ALWAYS deny clients access to WEB-INF:
"any requests from the client to access the resources in WEB-INF/ directory must be returned
with a SC_NOT_FOUND(404) response." (Servlet Spec 2.4 section 9.5)
2. ALWAYS deny clients access to META-INF:
"any requests to access the resources in META-INF directory must be returned with a SC_NOT_FOUND(404)
response." (Servlet spec 2.4 section 9.6)
3. By default, allow access to static resources:
"Web containers are required to support access to web resources by clients that have not authenticated
themselves to the container. This is the common mode of access to web resources on the Internet."
(Servlet Spec 2.4 section 12.7)
If resources such as .tml files need to be hidden then either move them into WEB-INF/classes
(which I'd argue is where they belong anyway as they are a non-configurable part of the app)
or blacklist them.
As for displaying index pages as the client traverses the resources, I think we're all agreed
it's wrong.
Geoff
> Asset dispatcher allows any file inside the webapp visible and downloadable
> ---------------------------------------------------------------------------
>
> Key: TAP5-815
> URL: https://issues.apache.org/jira/browse/TAP5-815
> Project: Tapestry 5
> Issue Type: Bug
> Affects Versions: 5.1.0.5
> Reporter: Thiago H. de Paula Figueiredo
> Assignee: Robert Zeigler
> Priority: Blocker
>
> Take any asset and you have an URL like domain.com/assets/ctx/f10407a6c1753e39/css/main.css.
If you request domain.com/assets/ctx/f10407a6c1753e39/, a list containing all the files inside
the webapp root is shown. It gives you the hint at downloading any file you want, including
anyting inside WEB-INF and assets that should be protected by ResourceDigestGenerator.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Em Wed, 02 Dec 2009 20:54:09 -0200, Howard Lewis Ship <hlship@gmail.com> escreveu: > I think the entire approach needs to be a bit more pluggable (though > decorating the service is also an option). Service decoration in Tapestry-IoC is very powerful. Once I was in a hurry and needed to override a service implementation. I tried using ServiceOverride, but I got the "service depends on itself" exception. Then I just added a decorate method, instantiated the new service implementation and returned it, completely ignoring the original implementation and not doing any decoration. Works like a charm. :) -- Thiago H. de Paula Figueiredo Independent Java, Apache Tapestry 5 and Hibernate consultant, developer, and instructor Owner, software architect and developer, Ars Machina Tecnologia da Informa豫o Ltda. http://www.arsmachina.com.br --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org For additional commands, e-mail: dev-help@tapestry.apache.org
This is something I've been meaning to look at as well. I'd like to
check what I've done for my client to see what I had to hack to
accomplish this, to ensure that we don't go through a couple of cycles
of this. I'm working for that client tomorrow, so I'll document that's
needed then.
I think the entire approach needs to be a bit more pluggable (though
decorating the service is also an option).
On Wed, Dec 2, 2009 at 12:59 PM, Igor Drobiazko
<igor.drobiazko@gmail.com> wrote:
> I would like to fix TAP5-915 and have to make ComponentMessagesSource a part
> of the public API. I know we should be reluctant to move services from
> internal packages but this feature is a must. Tapestry allows you to
> override almost every part of the framework, but not the message catalog of
> the components. Do you have any objections?
>
> The idea is to provide a mapped configuration for the service in which a
> component class is mapped to a path. In the following example the message
> catalog of 잻ateField is obtained from foo/bar/baz and not from
> /org/apache/tapestry5/corelib/components
>
> public void
> contributeComponentMessagesSource(MappedConfiguration<Class,String>
> configuration)
> {
> � � configuration.add(DateField.class, "/foo/bar/baz");
> }
>
> --
> Best regards,
>
> Igor Drobiazko
> http://tapestry5.de/blog
>
--
Howard M. Lewis Ship
Creator of Apache Tapestry
The source for Tapestry training, mentoring and support. Contact me to
learn how I can get you up and productive in Tapestry fast!
(971) 678-5210
http://howardlewisship.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
There's definitely a bit of conflict going on here. On the one hand, Apache's central message is all about community, but at the same time (for the sake of the legal umbrella and CLA's) we are embracing a tool (SVN) specifically to act as a choke point preventing community involvement. As a side note, I believe Ted Leung had a story at ApacheCon about the loss of several months of Subversion commits and how, fortunately, he had an archive of the commit mails and the knowledge to reapply all the changes from those commit mails. In the world of Git, you could follow that route, or recover official changes from any repository of any committer or other user. We've seen a side effect of Git's "code immortality" with Why the Lucky Stiff, who deleted his online presence (including many GitHub projects) a few months ago, but new GitHub projects were created from other user's forks, losing none of his history. The point is, it chagrins me to use a lesser tool, especially since outside of one area, it does not address (from a technical perspective) the goals of the Apache community. On Wed, Dec 2, 2009 at 1:02 PM, Doug Cutting <cutting@apache.org> wrote: > Howard Lewis Ship wrote: >> >> So what I'm hearing is that as long as external code is delivered via >> a JIRA patch, and the JIRA issue is referenced in the commit, then >> there's no difference between Git and SVN from a legal stand point. > > It's not black and white. 쟕he Jira signoff and even a CLA aren't strictly > required, since the license itself says that its terms apply to anything > that's intentionally submitted. 쟄owever we like to have good documentation > of that intent. 쟆ira's checkbox provides this. 쟕he ICLA provides this. > > A concern with Git is that a committer might push and pull changes from > others, work on them, then commit the collaboratively produced code, with no > clear point to document the intent of those others. > > Of concern with this pattern is, as mentioned, the decreased documentation > of intent. 잹ut also of concern is the decreased visibility of these > interactions to the community. 쟙ith subversion+Jira, a project has a single > patch repository and a single source code repository that all interactions > go through, so that any member of the community can monitor progress on > every issue in a single place. 잹ut, when folks are collaborating in a > distributed manner there's no longer a single point to monitor: to track the > project one must monitor the individual Git repos of each developer. > > To use an analogy, it's a bit like C++'s operator overloading, which I view > as a bad idea (pretend you agree with me, for the sake of this discussion). > 쟅n C++ projects you need to enforce a coding guideline against using this > language feature. 쟅n Java projects you have no such need, since Java simply > doesn't have operator overloading. 쟔imilarly, Subversion doesn't easily > support distributed development, while Git does. 쟕he ASF wishes to > discourage distributed development and is thus wary of embracing Git as a > primary tool. > > Finally, there's the infra issue: subversion is our highest priority > service, the one infra works hardest to keep running reliably without data > loss. 쟑roperly supporting another source code management system would not > be free and would spread our infrastructure resources even more thinly and > can thus not be considered lightly. > > Doug > > > -- Howard M. Lewis Ship Creator of Apache Tapestry The source for Tapestry training, mentoring and support. Contact me to learn how I can get you up and productive in Tapestry fast! (971) 678-5210 http://howardlewisship.com --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org For additional commands, e-mail: dev-help@tapestry.apache.org
I had this problem before and I had to hack some internals services to make
it works.
I'm definitely OK to make this API public.
On Wed, Dec 2, 2009 at 9:59 PM, Igor Drobiazko <igor.drobiazko@gmail.com>wrote:
> I would like to fix TAP5-915 and have to make ComponentMessagesSource a
> part
> of the public API. I know we should be reluctant to move services from
> internal packages but this feature is a must. Tapestry allows you to
> override almost every part of the framework, but not the message catalog of
> the components. Do you have any objections?
>
> The idea is to provide a mapped configuration for the service in which a
> component class is mapped to a path. In the following example the message
> catalog of DateField is obtained from foo/bar/baz and not from
> /org/apache/tapestry5/corelib/components
>
> public void
> contributeComponentMessagesSource(MappedConfiguration<Class,String>
> configuration)
> {
> configuration.add(DateField.class, "/foo/bar/baz");
> }
>
> --
> Best regards,
>
> Igor Drobiazko
> http://tapestry5.de/blog
>
I would like to fix TAP5-915 and have to make ComponentMessagesSource a part
of the public API. I know we should be reluctant to move services from
internal packages but this feature is a must. Tapestry allows you to
override almost every part of the framework, but not the message catalog of
the components. Do you have any objections?
The idea is to provide a mapped configuration for the service in which a
component class is mapped to a path. In the following example the message
catalog of DateField is obtained from foo/bar/baz and not from
/org/apache/tapestry5/corelib/components
public void
contributeComponentMessagesSource(MappedConfiguration<Class,String>
configuration)
{
configuration.add(DateField.class, "/foo/bar/baz");
}
--
Best regards,
Igor Drobiazko
http://tapestry5.de/blog