Re: [Tapestry Central] Announcing Tapestry 5.2
Here's the documentation page: http://tapestry.apache.org/reload.html On Mon, Dec 20, 2010 at 5:25 AM, Vangel V. Ajanovski wrote: > On 20.12.2010 10:41, Yohan Yudanara wrote: >> As expected, live class reload does not work on service without an interface. >> I have try it. > There was a post by Howard detailing the idea behind the live reload. > Search for it and read it to understand in more details. > > In simplified words: The idea is that you call the interface methods and > there is a "switch" that sits in-between and monitors your calls. This > switch finds the implementation class and redirects your method call to > the methods of the implementation class of the service. > So if this "switch" detects that there was a change in the > implementation class, it will reload the new version and redirect the > call to the new method. > > With this explanation I think it is pretty clear that you should not > even wonder and try if it would work without an interface. It cannot. > > JRebel is supposedly a good tool that can be used to have live reloading > in every piece of your code. I have not used it myself. > > - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: [Tapestry Central] Announcing Tapestry 5.2
On 20.12.2010 10:41, Yohan Yudanara wrote: > As expected, live class reload does not work on service without an interface. > I have try it. There was a post by Howard detailing the idea behind the live reload. Search for it and read it to understand in more details. In simplified words: The idea is that you call the interface methods and there is a "switch" that sits in-between and monitors your calls. This switch finds the implementation class and redirects your method call to the methods of the implementation class of the service. So if this "switch" detects that there was a change in the implementation class, it will reload the new version and redirect the call to the new method. With this explanation I think it is pretty clear that you should not even wonder and try if it would work without an interface. It cannot. JRebel is supposedly a good tool that can be used to have live reloading in every piece of your code. I have not used it myself. smime.p7s Description: S/MIME Cryptographic Signature
Re: [Tapestry Central] Announcing Tapestry 5.2
As expected, live class reload does not work on service without an interface. I have try it. On Fri, Dec 17, 2010 at 8:45 PM, Michael Gentry wrote: > Well, I've used services without an interface before, so maybe it'll > work, although I suspect it won't. I'll give it a try in a few days. > :-) > > Thanks Robert! > > mrg > > > On Fri, Dec 17, 2010 at 1:48 AM, Robert Zeigler wrote: >> Not sure that the DataObjects will work... the live service class reloading >> basically works b/c there's the public interface, and the "private" >> implementation, and the only class that has a reference to the private >> implementation is the proxy. At least, that's how I understand it. ;) Not >> sure how that would fly with the data objects, unless you defined an >> interface on top of each of your data objects... which sounds kinda ugly... > > - > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > For additional commands, e-mail: users-h...@tapestry.apache.org > > - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: [Tapestry Central] Announcing Tapestry 5.2
Yeah... you can do that... I'm just not sure if those services are proxied. I will definitely be curious to hear if it works... keep me posted. :) Robert On Dec 17, 2010, at 12/177:45 AM , Michael Gentry wrote: > Well, I've used services without an interface before, so maybe it'll > work, although I suspect it won't. I'll give it a try in a few days. > :-) > > Thanks Robert! > > mrg > > > On Fri, Dec 17, 2010 at 1:48 AM, Robert Zeigler wrote: >> Not sure that the DataObjects will work... the live service class reloading >> basically works b/c there's the public interface, and the "private" >> implementation, and the only class that has a reference to the private >> implementation is the proxy. At least, that's how I understand it. ;) Not >> sure how that would fly with the data objects, unless you defined an >> interface on top of each of your data objects... which sounds kinda ugly... > > - > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > For additional commands, e-mail: users-h...@tapestry.apache.org - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: [Tapestry Central] Announcing Tapestry 5.2
Great! I was waiting the release to try it out 5.2 :) Congrats for the great job ___ Everton Agner Ramos 2010/12/17 antalk > > Congrats on the new release, i hope to port our 2 existing webapps soon ! > -- > View this message in context: > http://tapestry.1045711.n5.nabble.com/Tapestry-Central-Announcing-Tapestry-5-2-tp3308716p3309558.html > Sent from the Tapestry - User mailing list archive at Nabble.com. > > - > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > For additional commands, e-mail: users-h...@tapestry.apache.org > >
Re: [Tapestry Central] Announcing Tapestry 5.2
Congrats on the new release, i hope to port our 2 existing webapps soon ! -- View this message in context: http://tapestry.1045711.n5.nabble.com/Tapestry-Central-Announcing-Tapestry-5-2-tp3308716p3309558.html Sent from the Tapestry - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: [Tapestry Central] Announcing Tapestry 5.2
Well, I've used services without an interface before, so maybe it'll work, although I suspect it won't. I'll give it a try in a few days. :-) Thanks Robert! mrg On Fri, Dec 17, 2010 at 1:48 AM, Robert Zeigler wrote: > Not sure that the DataObjects will work... the live service class reloading > basically works b/c there's the public interface, and the "private" > implementation, and the only class that has a reference to the private > implementation is the proxy. At least, that's how I understand it. ;) Not > sure how that would fly with the data objects, unless you defined an > interface on top of each of your data objects... which sounds kinda ugly... - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
RE: [Tapestry Central] Announcing Tapestry 5.2
Wow. Thank you very much. Indeed, as I upgraded to 5.2 a couple of days ago I'm pleased to see I've been running your final stable release. I see the Wikipedia page has had a clean sweep - perhaps controversially removing references to earlier versions. Mmmm - they must have been disappeared to the gulag. Great work guys - looking forward to future releases. c. - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: [Tapestry Central] Announcing Tapestry 5.2
Congratulations! We were just discusing here at work to rewrite our main web application from JSP to T5. I wanted to send some useful links to my coworkers for them to start reading about T5. I stumbled upon http://tapestry.apache.org/introduction.html which needs to be updated - the text must be very old as it covers 5.1 release. I filed https://issues.apache.org/jira/browse/TAP5-1376. And now lets's try the new version, I hope ChenilleKit will upgrade deps from 5.2.2 to 5.2.4 soon :-) Cheers, Borut 2010/12/16 Howard > I'm very proud to announce that the next major release of Tapestry, > release 5.2, is now available as Tapestry version 5.2.4. > This is the first stable release of Tapestry since 5.1.0.5 (back in > April 2009), which is far too long a cycle. You might wonder: what's > been the holdup? The answer, for myself personally, is that I've been > using Tapestry on two very, very different applications for two very, > very different clients and I've been updating Tapestry to embrace the > real world concerns of both of them. At the same time, I've done about > a dozen public and private Tapestry training sessions and gathered > reams of input from my students. > Let's talk about some of the major enhancements in this release: > Removal of Page Pooling > Prior versions of Tapestry used a page pool; for each page, Tapestry > would track multiple instances of the page, binding one page instance > to a particular request. This was an important part of Tapestry's > appeal ... all the issues related to multi-threading were taken over by > the framework, and you could code your pages and components as simple > POJOs, without worrying about the threading issues caused by running > inside a servlet container. > Unfortunately pages are big: it's not just one object but instead the > root of a large tree of objects: components and templates, bindings for > component parameters, component resources, and all the extra > infrastructure (lists and maps and such) to tie it together. Some of > the largest Tapestry projects have hit memory problems when they > combined deeply componentized pages with large numbers of parallel > threads. > Tapestry 5.2 rewrites the rules here; only a single page tree is now > needed for each page; the page and component classes have an extra > transformation step that moves per-request data out of the objects > themselves and into a per-thread Map object. Now, any number of > requests can operate at the same time, without requiring additional > page instances. Even better, the old page pooling mechanism included > some locking and blocking that also gets jettisoned in the new > approach. It's just a big win all around. Live Service Reloading > People love the ability to change page and component classes in a > Tapestry application and see the changes immediately; prior to 5.2 the > same people would be disappointed that they couldn't change their > services and see changes just as immediately. Tapestry 5.2 eliminates > that restriction in most cases. > This is super handy for services such as DAOs (data access objects) > where it is now possible to tweak a Hibernate query and see the results > as immediately as changing some content in a template. This is another > Tapestry feature that you'll find you can't live without once you use > it the first time! ClassTransformation API Improvements > At the heart of Tapestry is the Class Transformation API; the > extensible pipeline that is the basis for how Tapestry transforms > simple POJOs into working components. Prior to 5.2, if you wanted to do > any interesting transformations, you had to master the Javassist > psuedo-Java language. > Tapestry 5.2 reworks the API; it is now possible to do all kinds of > interesting transformations in strict Java code; Javassist has been > walled off, with an eventual goal to eliminate it entirely. Query > Parameter Support > Tapestry traditionally has stored information in the HTTP request path. > For example, a URL might be /viewaccount/12345; the viewaccount part of > the URL is the name of a page, and the 12345 part is the ID of an > Account object. Tapestry calls the latter part the page activation > context (which can contain one or more values). > That works well when the a page has a fixed set of values for the page > activation context, but not so well when the values may vary. For > instance, you may be doing a search and want to store optional query > parameters to identify the query term or the page number. > Tapestry 5.2 adds the @ActivationRequestParameter annotation that > automates the process of gathering such data, encoding into URLs as > query parameters, and making it available in subsequent requests. > Testing > A lot of work has gone into Tapestry's testing support, especially the > base classes that support integration testing using Selenium. The new > base classes make it easy to write test cases that work independently, > or as part of a larger test, automatically starti
Re: [Tapestry Central] Announcing Tapestry 5.2
Not sure that the DataObjects will work... the live service class reloading basically works b/c there's the public interface, and the "private" implementation, and the only class that has a reference to the private implementation is the proxy. At least, that's how I understand it. ;) Not sure how that would fly with the data objects, unless you defined an interface on top of each of your data objects... which sounds kinda ugly... Robert On Dec 16, 2010, at 12/169:31 PM , Michael Gentry wrote: > Early Christmas! > > I'm curious to see how the page pooling changes work out. About six > weeks ago one of our production apps blew up on us due to the page > pool. We thought we had large enough sizes defined, but an external > API we depended upon started responding very slowly (after months of > responding quickly) and that led to our pages being checked out of the > pool for minutes at a time, which quickly exhausted the pool. I think > with the removal of the page pool, our app would've survived better > (even though the portion using the external API would've still been > crippled). > > I'm also going to see if I can treat my Cayenne DataObjects as a > "service" for live class reloading now, too. > > Thanks Howard and everyone else who contributed! > > mrg > > > On Thu, Dec 16, 2010 at 5:44 PM, Howard Lewis Ship wrote: >> With formatting: >> http://tapestryjava.blogspot.com/2010/12/announcing-tapestry-52.html > > - > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > For additional commands, e-mail: users-h...@tapestry.apache.org - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: [Tapestry Central] Announcing Tapestry 5.2
For me, replacing the version number on pom.xml is working. If you use tapestry-spring, u should change spring version from 2.5.6 to spring 3.0.0.RELEASE or later.. On Fri, Dec 17, 2010 at 8:44 AM, Angelo C. wrote: > > Congrats to the Tapestry 5 Team for a great job! > now, how easy to upgrade from the 5.1 to 5.2? just replacing the version > number? any upgrade guide? > -- > View this message in context: > http://tapestry.1045711.n5.nabble.com/Tapestry-Central-Announcing-Tapestry-5-2-tp3308716p3308860.html > Sent from the Tapestry - User mailing list archive at Nabble.com. > > - > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > For additional commands, e-mail: users-h...@tapestry.apache.org > > - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: [Tapestry Central] Announcing Tapestry 5.2
Early Christmas! I'm curious to see how the page pooling changes work out. About six weeks ago one of our production apps blew up on us due to the page pool. We thought we had large enough sizes defined, but an external API we depended upon started responding very slowly (after months of responding quickly) and that led to our pages being checked out of the pool for minutes at a time, which quickly exhausted the pool. I think with the removal of the page pool, our app would've survived better (even though the portion using the external API would've still been crippled). I'm also going to see if I can treat my Cayenne DataObjects as a "service" for live class reloading now, too. Thanks Howard and everyone else who contributed! mrg On Thu, Dec 16, 2010 at 5:44 PM, Howard Lewis Ship wrote: > With formatting: > http://tapestryjava.blogspot.com/2010/12/announcing-tapestry-52.html - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: [Tapestry Central] Announcing Tapestry 5.2
that's good, will try that. talking about test, is there any sample where you use Groovy to do the test? -- View this message in context: http://tapestry.1045711.n5.nabble.com/Tapestry-Central-Announcing-Tapestry-5-2-tp3308716p3308913.html Sent from the Tapestry - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: [Tapestry Central] Announcing Tapestry 5.2
For the most part, it is just changing the version number. See the release notes for a few additional details, if you are doing some more advanced things. Of course, you should do some testing after changing versions! On Thu, Dec 16, 2010 at 5:44 PM, Angelo C. wrote: > > Congrats to the Tapestry 5 Team for a great job! > now, how easy to upgrade from the 5.1 to 5.2? just replacing the version > number? any upgrade guide? > -- > View this message in context: > http://tapestry.1045711.n5.nabble.com/Tapestry-Central-Announcing-Tapestry-5-2-tp3308716p3308860.html > Sent from the Tapestry - User mailing list archive at Nabble.com. > > - > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > For additional commands, e-mail: users-h...@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
Re: [Tapestry Central] Announcing Tapestry 5.2
Congrats to the Tapestry 5 Team for a great job! now, how easy to upgrade from the 5.1 to 5.2? just replacing the version number? any upgrade guide? -- View this message in context: http://tapestry.1045711.n5.nabble.com/Tapestry-Central-Announcing-Tapestry-5-2-tp3308716p3308860.html Sent from the Tapestry - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: [Tapestry Central] Announcing Tapestry 5.2
With formatting: http://tapestryjava.blogspot.com/2010/12/announcing-tapestry-52.html On Thu, Dec 16, 2010 at 2:22 PM, Howard wrote: > I'm very proud to announce that the next major release of Tapestry, > release 5.2, is now available as Tapestry version 5.2.4. > This is the first stable release of Tapestry since 5.1.0.5 (back in > April 2009), which is far too long a cycle. You might wonder: what's > been the holdup? The answer, for myself personally, is that I've been > using Tapestry on two very, very different applications for two very, > very different clients and I've been updating Tapestry to embrace the > real world concerns of both of them. At the same time, I've done about > a dozen public and private Tapestry training sessions and gathered > reams of input from my students. > Let's talk about some of the major enhancements in this release: > Removal of Page Pooling > Prior versions of Tapestry used a page pool; for each page, Tapestry > would track multiple instances of the page, binding one page instance > to a particular request. This was an important part of Tapestry's > appeal ... all the issues related to multi-threading were taken over by > the framework, and you could code your pages and components as simple > POJOs, without worrying about the threading issues caused by running > inside a servlet container. > Unfortunately pages are big: it's not just one object but instead the > root of a large tree of objects: components and templates, bindings for > component parameters, component resources, and all the extra > infrastructure (lists and maps and such) to tie it together. Some of > the largest Tapestry projects have hit memory problems when they > combined deeply componentized pages with large numbers of parallel > threads. > Tapestry 5.2 rewrites the rules here; only a single page tree is now > needed for each page; the page and component classes have an extra > transformation step that moves per-request data out of the objects > themselves and into a per-thread Map object. Now, any number of > requests can operate at the same time, without requiring additional > page instances. Even better, the old page pooling mechanism included > some locking and blocking that also gets jettisoned in the new > approach. It's just a big win all around. Live Service Reloading > People love the ability to change page and component classes in a > Tapestry application and see the changes immediately; prior to 5.2 the > same people would be disappointed that they couldn't change their > services and see changes just as immediately. Tapestry 5.2 eliminates > that restriction in most cases. > This is super handy for services such as DAOs (data access objects) > where it is now possible to tweak a Hibernate query and see the results > as immediately as changing some content in a template. This is another > Tapestry feature that you'll find you can't live without once you use > it the first time! ClassTransformation API Improvements > At the heart of Tapestry is the Class Transformation API; the > extensible pipeline that is the basis for how Tapestry transforms > simple POJOs into working components. Prior to 5.2, if you wanted to do > any interesting transformations, you had to master the Javassist > psuedo-Java language. > Tapestry 5.2 reworks the API; it is now possible to do all kinds of > interesting transformations in strict Java code; Javassist has been > walled off, with an eventual goal to eliminate it entirely. Query > Parameter Support > Tapestry traditionally has stored information in the HTTP request path. > For example, a URL might be /viewaccount/12345; the viewaccount part of > the URL is the name of a page, and the 12345 part is the ID of an > Account object. Tapestry calls the latter part the page activation > context (which can contain one or more values). > That works well when the a page has a fixed set of values for the page > activation context, but not so well when the values may vary. For > instance, you may be doing a search and want to store optional query > parameters to identify the query term or the page number. > Tapestry 5.2 adds the @ActivationRequestParameter annotation that > automates the process of gathering such data, encoding into URLs as > query parameters, and making it available in subsequent requests. > Testing > A lot of work has gone into Tapestry's testing support, especially the > base classes that support integration testing using Selenium. The new > base classes make it easy to write test cases that work independently, > or as part of a larger test, automatically starting and stopping > Selenium and Jetty as appropriate. Further, Tapestry expands on > Selenium's failure behavior, so that failures result in a capture of > the page contents as both HTML and a PNG image file. It is simply much > faster and much easier to write real, useful tests for Tapestry. > JSR-303 Support > Tapestry now supports the Bean Validation JSR, converting the standard > validatio
[Tapestry Central] Announcing Tapestry 5.2
I'm very proud to announce that the next major release of Tapestry, release 5.2, is now available as Tapestry version 5.2.4. This is the first stable release of Tapestry since 5.1.0.5 (back in April 2009), which is far too long a cycle. You might wonder: what's been the holdup? The answer, for myself personally, is that I've been using Tapestry on two very, very different applications for two very, very different clients and I've been updating Tapestry to embrace the real world concerns of both of them. At the same time, I've done about a dozen public and private Tapestry training sessions and gathered reams of input from my students. Let's talk about some of the major enhancements in this release: Removal of Page Pooling Prior versions of Tapestry used a page pool; for each page, Tapestry would track multiple instances of the page, binding one page instance to a particular request. This was an important part of Tapestry's appeal ... all the issues related to multi-threading were taken over by the framework, and you could code your pages and components as simple POJOs, without worrying about the threading issues caused by running inside a servlet container. Unfortunately pages are big: it's not just one object but instead the root of a large tree of objects: components and templates, bindings for component parameters, component resources, and all the extra infrastructure (lists and maps and such) to tie it together. Some of the largest Tapestry projects have hit memory problems when they combined deeply componentized pages with large numbers of parallel threads. Tapestry 5.2 rewrites the rules here; only a single page tree is now needed for each page; the page and component classes have an extra transformation step that moves per-request data out of the objects themselves and into a per-thread Map object. Now, any number of requests can operate at the same time, without requiring additional page instances. Even better, the old page pooling mechanism included some locking and blocking that also gets jettisoned in the new approach. It's just a big win all around. Live Service Reloading People love the ability to change page and component classes in a Tapestry application and see the changes immediately; prior to 5.2 the same people would be disappointed that they couldn't change their services and see changes just as immediately. Tapestry 5.2 eliminates that restriction in most cases. This is super handy for services such as DAOs (data access objects) where it is now possible to tweak a Hibernate query and see the results as immediately as changing some content in a template. This is another Tapestry feature that you'll find you can't live without once you use it the first time! ClassTransformation API Improvements At the heart of Tapestry is the Class Transformation API; the extensible pipeline that is the basis for how Tapestry transforms simple POJOs into working components. Prior to 5.2, if you wanted to do any interesting transformations, you had to master the Javassist psuedo-Java language. Tapestry 5.2 reworks the API; it is now possible to do all kinds of interesting transformations in strict Java code; Javassist has been walled off, with an eventual goal to eliminate it entirely. Query Parameter Support Tapestry traditionally has stored information in the HTTP request path. For example, a URL might be /viewaccount/12345; the viewaccount part of the URL is the name of a page, and the 12345 part is the ID of an Account object. Tapestry calls the latter part the page activation context (which can contain one or more values). That works well when the a page has a fixed set of values for the page activation context, but not so well when the values may vary. For instance, you may be doing a search and want to store optional query parameters to identify the query term or the page number. Tapestry 5.2 adds the @ActivationRequestParameter annotation that automates the process of gathering such data, encoding into URLs as query parameters, and making it available in subsequent requests. Testing A lot of work has gone into Tapestry's testing support, especially the base classes that support integration testing using Selenium. The new base classes make it easy to write test cases that work independently, or as part of a larger test, automatically starting and stopping Selenium and Jetty as appropriate. Further, Tapestry expands on Selenium's failure behavior, so that failures result in a capture of the page contents as both HTML and a PNG image file. It is simply much faster and much easier to write real, useful tests for Tapestry. JSR-303 Support Tapestry now supports the Bean Validation JSR, converting the standard validation annotations into client-side and server-side validations. Documentation Tapestry's documentation has always been a challenge; for Tapestry 5.2 we've been doing a massive rework; doing a better job of getting your started using Tapestry; it's still a work in progress, but since it's based
