Re: Updated code for live service reloading
I have update wooki yesterday, it looks good ! But i continue to try it out 2010/9/1 Howard Lewis Ship > Yesterday I checked in a revised version of the live service reloading > code. > > The new code is a bit smarter about extending the class-loader > umbrella to inner classes and base classes. This should make protected > method invocations work correctly (in most cases). > > There may be room for additional analysis. > > I'd appreciate it if people could try out the snapshot and see how > well it flies. I really don't want to make live service reloading > default to off. > > -- > 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-unsubscr...@tapestry.apache.org > For additional commands, e-mail: dev-h...@tapestry.apache.org > > -- Regards, Christophe Cordenier. Committer on Apache Tapestry 5 Co-creator of wooki @wookicentral.com
Re: Updated code for live service reloading
Hi,
maybe I misunderstand something but I do not believe that this is
"harmless".
This will corrupt all singleton pattern implementations which are based on a
static
getInstance() method and a static field.
Or wouldn't it?
You may argue that the singleton pattern is "evil" but nevertheless there
are a lot
of libraries out there implementing it.
Greetings
Olli
2010/9/3 Howard Lewis Ship
> On Thu, Sep 2, 2010 at 3:10 PM, Igor Drobiazko
> wrote:
> > How that? You would need to load that class together with the service
> from
> > same classloader. What if a ServiceMessages is accessed by several
> services?
>
> Each service will end up with its own copy of the class (including its
> static variables). That may not be desirable, or it may be an unwanted
> leaky abstraction, but harmless.
>
> >
> >
> > On Fri, Sep 3, 2010 at 12:01 AM, Howard Lewis Ship
> wrote:
> >
> >> I can actually fix that, by bringing ServiceMessages "under the
> umbrella".
> >>
> >> On Thu, Sep 2, 2010 at 2:55 PM, Igor Drobiazko <
> igor.drobia...@gmail.com>
> >> wrote:
> >> > If you have a class like the following one inside the services package
> >> and
> >> > access the foo() method inside a service, you'll experience
> >> > IllegalAccessException. You can fix the problem by changing the
> >> visibility
> >> > of the foo() method to public.
> >> >
> >> > public class ServiceMessages {
> >> >static String foo(){
> >> > return "foo";
> >> >}
> >> > }
> >> >
> >> > On Thu, Sep 2, 2010 at 11:24 PM, Howard Lewis Ship
> >> wrote:
> >> >
> >> >> Tell me more about static utility methods ... it may be possible to
> >> >> make those work as well.
> >> >>
> >> >> On Thu, Sep 2, 2010 at 12:30 PM, Igor Drobiazko
> >> >> wrote:
> >> >> > I tested my apps today with the recent snapshots. It looks good. No
> >> >> problems
> >> >> > with protected or package private methods in super classes. There
> are
> >> >> still
> >> >> > some problems with static utility methods but it is ok. I think we
> are
> >> >> ready
> >> >> > for a beta release now.
> >> >> >
> >> >> > On Wed, Sep 1, 2010 at 11:00 PM, Igor Drobiazko <
> >> >> igor.drobia...@gmail.com>wrote:
> >> >> >
> >> >> >> That's great. I'll try it out and report the results.
> >> >> >>
> >> >> >>
> >> >> >> On Wed, Sep 1, 2010 at 7:00 PM, Howard Lewis Ship <
> hls...@gmail.com
> >> >> >wrote:
> >> >> >>
> >> >> >>> Yesterday I checked in a revised version of the live service
> >> reloading
> >> >> >>> code.
> >> >> >>>
> >> >> >>> The new code is a bit smarter about extending the class-loader
> >> >> >>> umbrella to inner classes and base classes. This should make
> >> protected
> >> >> >>> method invocations work correctly (in most cases).
> >> >> >>>
> >> >> >>> There may be room for additional analysis.
> >> >> >>>
> >> >> >>> I'd appreciate it if people could try out the snapshot and see
> how
> >> >> >>> well it flies. I really don't want to make live service
> reloading
> >> >> >>> default to off.
> >> >> >>>
> >> >> >>> --
> >> >> >>> 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-unsubscr...@tapestry.apache.org
> >> >> >>> For additional commands, e-mail: dev-h...@tapestry.apache.org
> >> >> >>>
> >> >> >>>
> >> >> >>
> >> >> >>
> >> >> >> --
> >> >> >> Best regards,
> >> >> >>
> >> >> >> Igor Drobiazko
> >> >> >> http://tapestry5.de
> >> >> >>
> >> >> >
> >> >> >
> >> >> >
> >> >> > --
> >> >> > Best regards,
> >> >> >
> >> >> > Igor Drobiazko
> >> >> > http://tapestry5.de
> >> >> >
> >> >>
> >> >>
> >> >>
> >> >> --
> >> >> 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-unsubscr...@tapestry.apache.org
> >> >> For additional commands, e-mail: dev-h...@tapestry.apache.org
> >> >>
> >> >>
> >> >
> >> >
> >> > --
> >> > Best regards,
> >> >
> >> > Igor Drobiazko
> >> > http://tapestry5.de
> >> >
> >>
> >>
> >>
> >> --
> >> 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-unsubscr...@
Re: Performance Testing Lab
These are all good notes, and I was certainly thinking about Ben's tests when I wrote my initial email. The scope of this can expand dramatically. What I really want, for a first pass, is an answer to the question: Is Tapestry 5.2 faster than 5.1? Does it use less memory? On Thu, Sep 2, 2010 at 11:33 PM, Kalle Korhonen wrote: > Ben, what you are talking about seems to be geared more towards > testing readiness and scalability of a production application. For > benchmarking multiple versions of the framework, I'd assume data > access would never come to play as there should be no database > whatsoever. Maintaining a fully synthetic test should also be far > easier than maintaining a scalability test for a real world > application. Also, standardized, guaranteed QoS VMs are great for > scalability testing when you are mostly looking for "good enough" as > an answer but if you are really comparing versions of the framework > over time, the differences should be measured in milliseconds even > with thousands of repeated executions, so it's critical that extra > variables are reduced to minimum just the same way as if we > benchmarked specific features of JVM against different versions. On > the other hand, creating and benchmarking a close-to-real-world > blueprint application is always good marketing, which Tapestry > certainly needs. > > Howard expressed a desire for doing both type of testing, but I don't > think its a good idea to try and combine the different goals into the > same test suite. In a fully synthetic test, the absolute numbers don't > matter, only the differences do. And you certainly couldn't compare > results of a synthetic test implemented in one framework to test > results implemented in another framework, but only to different > versions of itself. Seems that the first thing to do is to decide what > exactly we want to measure. > > Kalle > > > On Thu, Sep 2, 2010 at 10:55 PM, Ben Gidley wrote: >> I did a comparative load test >> http://blog.gidley.co.uk/2009/05/tapestry-load-testing-round-up.html a while >> back and we do a lot of load testing for SeeSaw.com (mainly to compare >> versions). I did create a 'comparative' struts application for that >> evaluation (source code >> http://sites.google.com/a/gidley.co.uk/tapestryloadtest/Home/test-5) >> >> We use Grinder as our load test tool - as it handles clustered load >> generating agents well and the Jython scripting makes it easy to share steps >> between 'journeys' in the application. You probably don't need to worry >> about clustering - as it isn't a core tapestry 'feature' (rather an >> environmental one), but even without that feature grinder is easy to work >> and powerful. >> >> If your goal is to test tapestry the first issue you will hit is any Data >> Access - in our apps the data access piece is 90% of the page time. In >> SeeSaw we 'solve' this by heavily caching data so most pages only access >> data from a Cache. I would suggest to get a test that focused on tapestry >> you load you data from in memory caches. That way you won't be measuring how >> fast Hibernate or your DB(etc) performs. >> >> Another big issue we hit is breaking/maintaining our load test scripts - as >> they effectively reverse engineer some tapestry behaviours (especially AJAX >> ones) they can get broken quite easily. Our solution is to run them single >> threaded as part of our CI builds. This usually catches obvious changes. >> >> Another thing to watch out for is your app server. Jetty is an excellent >> high load container - but depending on how it is configured it can >> 'throttle' throughput (this is excellent thing in production). This can skew >> your test as you end up measuring the throttling and not the application. >> The trick is to set the thread pools in Jetty far higher than you would in >> production so you can be sure you are not maximising them. >> >> I would advise trying to use controlled hardware for your test - slight >> environmental differences can totally adjust the results. EC2 and its like >> are popular for this - do Apache have anything similar? I can get you time >> on (but not direct access to) the ioko cloud (which is a VMWare VSphere >> cluster), which does let you nearly guarantee QOS. >> >> It may be a good idea to build the test as something that can be easily >> deployed as a Virtual machine as it would let you easily deploy it anywhere. >> I have previously used Suse Studio (http://susestudio.com/) to build a very >> small VM with a maven script on it that updates/runs my app. The VM's built >> there will run pretty much anywhere. >> >> To find issues with a load test I recommend YourKit. It gives you a ton of >> monitoring and via its 'probes' you can see right inside tapestry. It is >> free for open source projects. I would also recommend enabling JMX in your >> application and periodically writing the stats somewhere. You can do this >> simply with VisualVM or you can get more advanced and store them in a
Re: Updated code for live service reloading
Life class reloading doesn't affect classes packed into jars. Thus no
problems with libraries.
On Fri, Sep 3, 2010 at 5:49 PM, Oliver Geisser wrote:
> Hi,
>
> maybe I misunderstand something but I do not believe that this is
> "harmless".
>
> This will corrupt all singleton pattern implementations which are based on
> a
> static
> getInstance() method and a static field.
>
> Or wouldn't it?
>
> You may argue that the singleton pattern is "evil" but nevertheless there
> are a lot
> of libraries out there implementing it.
>
>
> Greetings
> Olli
>
>
> 2010/9/3 Howard Lewis Ship
>
> > On Thu, Sep 2, 2010 at 3:10 PM, Igor Drobiazko >
> > wrote:
> > > How that? You would need to load that class together with the service
> > from
> > > same classloader. What if a ServiceMessages is accessed by several
> > services?
> >
> > Each service will end up with its own copy of the class (including its
> > static variables). That may not be desirable, or it may be an unwanted
> > leaky abstraction, but harmless.
> >
> > >
> > >
> > > On Fri, Sep 3, 2010 at 12:01 AM, Howard Lewis Ship
> > wrote:
> > >
> > >> I can actually fix that, by bringing ServiceMessages "under the
> > umbrella".
> > >>
> > >> On Thu, Sep 2, 2010 at 2:55 PM, Igor Drobiazko <
> > igor.drobia...@gmail.com>
> > >> wrote:
> > >> > If you have a class like the following one inside the services
> package
> > >> and
> > >> > access the foo() method inside a service, you'll experience
> > >> > IllegalAccessException. You can fix the problem by changing the
> > >> visibility
> > >> > of the foo() method to public.
> > >> >
> > >> > public class ServiceMessages {
> > >> >static String foo(){
> > >> > return "foo";
> > >> >}
> > >> > }
> > >> >
> > >> > On Thu, Sep 2, 2010 at 11:24 PM, Howard Lewis Ship <
> hls...@gmail.com>
> > >> wrote:
> > >> >
> > >> >> Tell me more about static utility methods ... it may be possible to
> > >> >> make those work as well.
> > >> >>
> > >> >> On Thu, Sep 2, 2010 at 12:30 PM, Igor Drobiazko
> > >> >> wrote:
> > >> >> > I tested my apps today with the recent snapshots. It looks good.
> No
> > >> >> problems
> > >> >> > with protected or package private methods in super classes. There
> > are
> > >> >> still
> > >> >> > some problems with static utility methods but it is ok. I think
> we
> > are
> > >> >> ready
> > >> >> > for a beta release now.
> > >> >> >
> > >> >> > On Wed, Sep 1, 2010 at 11:00 PM, Igor Drobiazko <
> > >> >> igor.drobia...@gmail.com>wrote:
> > >> >> >
> > >> >> >> That's great. I'll try it out and report the results.
> > >> >> >>
> > >> >> >>
> > >> >> >> On Wed, Sep 1, 2010 at 7:00 PM, Howard Lewis Ship <
> > hls...@gmail.com
> > >> >> >wrote:
> > >> >> >>
> > >> >> >>> Yesterday I checked in a revised version of the live service
> > >> reloading
> > >> >> >>> code.
> > >> >> >>>
> > >> >> >>> The new code is a bit smarter about extending the class-loader
> > >> >> >>> umbrella to inner classes and base classes. This should make
> > >> protected
> > >> >> >>> method invocations work correctly (in most cases).
> > >> >> >>>
> > >> >> >>> There may be room for additional analysis.
> > >> >> >>>
> > >> >> >>> I'd appreciate it if people could try out the snapshot and see
> > how
> > >> >> >>> well it flies. I really don't want to make live service
> > reloading
> > >> >> >>> default to off.
> > >> >> >>>
> > >> >> >>> --
> > >> >> >>> 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-unsubscr...@tapestry.apache.org
> > >> >> >>> For additional commands, e-mail: dev-h...@tapestry.apache.org
> > >> >> >>>
> > >> >> >>>
> > >> >> >>
> > >> >> >>
> > >> >> >> --
> > >> >> >> Best regards,
> > >> >> >>
> > >> >> >> Igor Drobiazko
> > >> >> >> http://tapestry5.de
> > >> >> >>
> > >> >> >
> > >> >> >
> > >> >> >
> > >> >> > --
> > >> >> > Best regards,
> > >> >> >
> > >> >> > Igor Drobiazko
> > >> >> > http://tapestry5.de
> > >> >> >
> > >> >>
> > >> >>
> > >> >>
> > >> >> --
> > >> >> 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-unsubscr...@tapestry.apache.org
> > >> >> For additional commands, e-mail: dev-h...@tapestry.apache.org
> > >> >>
> > >> >>
> > >> >
> > >> >
> > >> > --
Re: Updated code for live service reloading
It's a bit of a mess.
The umbrella extends to inner classes and base classes, even if the
base classes themselves are from a library.
I have proposed extending it further, to identify classes in which
non-public (protected or package private) members are accessed. This
too is do-able, but, yes, it can change the semantics of static
variables.
... which is why we use an IoC container, right?
Let's continue to see if what I've put together is good enough. The
perfect is the enemy of the good.
On Fri, Sep 3, 2010 at 10:26 AM, Igor Drobiazko
wrote:
> Life class reloading doesn't affect classes packed into jars. Thus no
> problems with libraries.
>
> On Fri, Sep 3, 2010 at 5:49 PM, Oliver Geisser
> wrote:
>
>> Hi,
>>
>> maybe I misunderstand something but I do not believe that this is
>> "harmless".
>>
>> This will corrupt all singleton pattern implementations which are based on
>> a
>> static
>> getInstance() method and a static field.
>>
>> Or wouldn't it?
>>
>> You may argue that the singleton pattern is "evil" but nevertheless there
>> are a lot
>> of libraries out there implementing it.
>>
>>
>> Greetings
>> Olli
>>
>>
>> 2010/9/3 Howard Lewis Ship
>>
>> > On Thu, Sep 2, 2010 at 3:10 PM, Igor Drobiazko > >
>> > wrote:
>> > > How that? You would need to load that class together with the service
>> > from
>> > > same classloader. What if a ServiceMessages is accessed by several
>> > services?
>> >
>> > Each service will end up with its own copy of the class (including its
>> > static variables). That may not be desirable, or it may be an unwanted
>> > leaky abstraction, but harmless.
>> >
>> > >
>> > >
>> > > On Fri, Sep 3, 2010 at 12:01 AM, Howard Lewis Ship
>> > wrote:
>> > >
>> > >> I can actually fix that, by bringing ServiceMessages "under the
>> > umbrella".
>> > >>
>> > >> On Thu, Sep 2, 2010 at 2:55 PM, Igor Drobiazko <
>> > igor.drobia...@gmail.com>
>> > >> wrote:
>> > >> > If you have a class like the following one inside the services
>> package
>> > >> and
>> > >> > access the foo() method inside a service, you'll experience
>> > >> > IllegalAccessException. You can fix the problem by changing the
>> > >> visibility
>> > >> > of the foo() method to public.
>> > >> >
>> > >> > public class ServiceMessages {
>> > >> > static String foo(){
>> > >> > return "foo";
>> > >> > }
>> > >> > }
>> > >> >
>> > >> > On Thu, Sep 2, 2010 at 11:24 PM, Howard Lewis Ship <
>> hls...@gmail.com>
>> > >> wrote:
>> > >> >
>> > >> >> Tell me more about static utility methods ... it may be possible to
>> > >> >> make those work as well.
>> > >> >>
>> > >> >> On Thu, Sep 2, 2010 at 12:30 PM, Igor Drobiazko
>> > >> >> wrote:
>> > >> >> > I tested my apps today with the recent snapshots. It looks good.
>> No
>> > >> >> problems
>> > >> >> > with protected or package private methods in super classes. There
>> > are
>> > >> >> still
>> > >> >> > some problems with static utility methods but it is ok. I think
>> we
>> > are
>> > >> >> ready
>> > >> >> > for a beta release now.
>> > >> >> >
>> > >> >> > On Wed, Sep 1, 2010 at 11:00 PM, Igor Drobiazko <
>> > >> >> igor.drobia...@gmail.com>wrote:
>> > >> >> >
>> > >> >> >> That's great. I'll try it out and report the results.
>> > >> >> >>
>> > >> >> >>
>> > >> >> >> On Wed, Sep 1, 2010 at 7:00 PM, Howard Lewis Ship <
>> > hls...@gmail.com
>> > >> >> >wrote:
>> > >> >> >>
>> > >> >> >>> Yesterday I checked in a revised version of the live service
>> > >> reloading
>> > >> >> >>> code.
>> > >> >> >>>
>> > >> >> >>> The new code is a bit smarter about extending the class-loader
>> > >> >> >>> umbrella to inner classes and base classes. This should make
>> > >> protected
>> > >> >> >>> method invocations work correctly (in most cases).
>> > >> >> >>>
>> > >> >> >>> There may be room for additional analysis.
>> > >> >> >>>
>> > >> >> >>> I'd appreciate it if people could try out the snapshot and see
>> > how
>> > >> >> >>> well it flies. I really don't want to make live service
>> > reloading
>> > >> >> >>> default to off.
>> > >> >> >>>
>> > >> >> >>> --
>> > >> >> >>> 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-unsubscr...@tapestry.apache.org
>> > >> >> >>> For additional commands, e-mail: dev-h...@tapestry.apache.org
>> > >> >> >>>
>> > >> >> >>>
>> > >> >> >>
>> > >> >> >>
>> > >> >> >> --
>> > >> >> >> Best regards,
>> > >> >> >>
>> > >> >> >> Igor Drobiazko
>> > >> >> >> http://tapestry5.de
>> > >> >> >>
>> > >> >> >
>> > >> >> >
>> > >> >> >
>> > >> >> > --
>> > >> >> > Best regards,
>> > >> >> >
>>
Re: [VOTE] Josh Canfield as Committer
François Facon: +1 (non-binding) 2010/9/2 Howard Lewis Ship > Josh Canfield has been very active in the Tapestry community for quite > some time; he was an early evangalist for Tapestry 5 and has deployed > multiple Tapestry 5 applications. He's also been very active in the > mailing list, and has provided some terrific patches, including one > that largely addresses the mismatch between generics and Tapestry's > property expression language. I've spoken with him, and he is eager to > join the team. > > Howard M. Lewis Ship: +1 (binding) > > > Vote to run for 7 days. Reminder: please include your name (as I did > above), it makes tabulating the results much easier! > > -- > 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-unsubscr...@tapestry.apache.org > For additional commands, e-mail: dev-h...@tapestry.apache.org > >
Re: [VOTE] Josh Canfield as Committer
Charitha Madusanka: +1 (non-binding) On Fri, Sep 3, 2010 at 3:04 AM, Howard Lewis Ship wrote: > Josh Canfield has been very active in the Tapestry community for quite > some time; he was an early evangalist for Tapestry 5 and has deployed > multiple Tapestry 5 applications. He's also been very active in the > mailing list, and has provided some terrific patches, including one > that largely addresses the mismatch between generics and Tapestry's > property expression language. I've spoken with him, and he is eager to > join the team. > > Howard M. Lewis Ship: +1 (binding) > > > Vote to run for 7 days. Reminder: please include your name (as I did > above), it makes tabulating the results much easier! > > -- > 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-unsubscr...@tapestry.apache.org > For additional commands, e-mail: dev-h...@tapestry.apache.org > >
