Hi Cats,
> Something like this, however, seems to be _way_ easier to implement in > an IDE than in an application server potentially housing a whole load of > custom applications. In an IDE, telling that "something went wrong" is > pretty easy (an exception is being thrown and not handled). What happens > in an application server, given an exception is being thrown? Who's to > blame if the application involves a couple of more or less loosely > coupled modules interacting with each other?
I agree with your point that it would be easier to handle testing using IDE. But there are many points when it makes sense to do it online.Please see the following reasons:
1) Environment where is located IDE and production/standalone server very often quite different and we need to test all possible environments. Personally I had a couple issues related strictly to Free BSD environment when in the same time my IDE is located on Windows.
2) >application server potentially housing a whole load of custom applications.
That is one more reason to have possibility to test application separately from the IDE.Frameworks, libraries, all this stuff could be very different between IDE and server.
3) >What happens in an application server, given an exception is being thrown?
We will rise this kind of questions before Glassfish team if we will be able to go after online testing environment.In my opinion Glassfish server should be able to have some kind of self-diagnostic and self-healing mechanism. Microsoft said something in this regard about Windows 7. But I'm not sure if this kind of thing works for them :)Imagine a situation where we will need to build some kind of online society. In this case, application server must have some kind of better mechanism to fight exceptions comparing to log files ;)It could be similar approach to how internet browsers are handling problems with bad plugins.
4) >Who's to blame if the application involves a couple of more or less loosely > coupled modules interacting with each other?
I always thought that it will provide additional benefit if testing plan includes this kind of situation. Also this approach would help to catch bugs inside custom applications not just Glassfish's issues.When our environment will start catch other developers bugs we will make them to accept our "award" schema :)
5) "it seems that web-based IDEs might soon become mainstream."It's a quote from internet. I have the same opinion. You know to have online society you will need three things:online productiononline currencyonline market
IDE is very important part of production isn't it? So from this perspective eventually some kind of useful mechanism for catching bugs online will be implemented anyway.
6) According to the report that Kristian mentioned before Netbeans IDE's share on the market is only 1.9 percent.That means many developers will not have access to some of good testing tools that Netbeans provide. It's additional point to go after online testing environment.
http://www.eclipse.org/org/community_survey/Eclipse_Survey_2010_Report.pdf
7) We could also try to integrate HTML 5 notification mechanism.
http://www.html5rocks.com/tutorials/notifications/quick/
> This is a good idea in my opinion, if they do have an option to make > them publicly available, that is. This will provide us with the > necessary "breadth" to make sure many variants of Java EE applications > run on top of the platform.
Thank you! We have one more common point to go. "necessary "breadth"" sentence sound promising!
> ACK on that, as well, at least maybe being a "web form" integrated with > the admin panel to easier allow for filing a new issue. Maybe a > "testing" profile for the admin panel with enhanced test-related options?
Sound reasonable. Should me think about it more deeply to increase chance of acceptance by Glassfish team or just throw them idea in the form you put here?Judy, probably could provide a hint to what level we should go on with this suggestion.As variant we could provide picture to present how we see the "testing" profile should look and act.
> > Another example would be create possibility for people to upload their> > log for analyze by FichCat team.> > Obviously we will need to have logs database to handle them in scalable> > manner.> > This won't work, in my opinion, not just partly because of the first > reason. Looking just at our own application infrastructure, if running > the environment in LogLevel.FINEST mode, it'll end up providing a good > gigabyte of logging per day at the very least. Doing log file analysis > in this dimensions without knowing anything about the applications > involved seems impossible to me.
But several times somebody from Glassfish and Netbeans asked me for log files.So looks like they need them. Maybe Judy again could clear up things here. Are you really sure that wouldn't work?For me it's working more or less. Of course my production environment probably much less than yours.According to the report you have provided about 12 percents developers are not affiliated with any organization.Maybe they have pretty small production environment and as consequent small log files.
> Adding to that, to reproduce the errors > eventually it will need a reproducible environment, including databases, > file systems, and all sort of infrastructure to somehow affect the way > the application behaves. What if an exception is being thrown trying to > send an e-mail via JavaMail because the SMTP host doesn't allow for > connections from the testbed server?
Like in case with log files Glassfish asked to send them my applications for analyze.I sent them it and got response that in someway they helped to resolve something.I also was wondering to how without database and other resources that you pretty much mentioned here they could use them.You have point saying that we need to have infrastructure that will be able to produce reproducible environment :)How to do it is another question. By the way do we still have to restart the server when JDBC resources changed?
> And, finally, of course, I think > there's a boundary we should make between "server infrastructure > testing" and "application migration support". The latter thing is a > hard, tedious work from my experience, something which might pretty well > be done by experienced consultants on-site if the documentation at hand > doesn't help. For "server infrastructure testing", I think the work > FishCAT people can do is spending time and effort on trying to break > down errors, to tell whether or not an error is caused by (a) the server > itself, (b) a misbehaviour of the server along with some third-party > code or (c) an application-specific error and subsequently to make sure > (a) and (b) errors are reported and dealt with in a sane way... :)
I see your point. Again I believe that our framework could help in area of "application migration". The testing framework should allow to register and keep in database applications and libraries.Than we will have easy way to migrate applications to the new version of the server and start do some hunting.
>(b) errors are reported and dealt with in a sane way... :)If somebody will start cheating we will award him with "negative" money.I would call the "negative" money as black dukes.More black dukes you have on your account the more barriers you will have to earn decent dukes :)For example if developer got 100 black dukes in his account then his right to filling bugs will be revoked.Because we have instrument to fight the cheating it should be possible for us to put at least some ways of earning dukes to auto mode.Imagine a situation when some person filled out 10 issues and all of them don't make any sense. He will got 10*5=50 dukes in auto mode. Eventually some testing manager will found out about his "creative" work and will close the related issues as poorly handled.For every bad issue the person will get 10 black dukes but still will be able to keep his 50 "white" dukes. We should be fair here, after all cheating is also require some efforts :) The system will work such way that in the end no much fun for him will be left.Personally I will feel sorry for him :) And we should allow everybody to have a second chance to earn dukes. In case to do it our black dukes will have expiration date. One year as time period sound reasonable in this context.
Have a good evening everyone,Vladimir
> Date: Tue, 29 Jun 2010 16:34:17 +0200
> From: rink_at_planconnect.de
> To: quality_at_glassfish.dev.java.net
> Subject: Re: more effective fishing
>
> Folks;
>
> Am 29.06.2010 16:14, schrieb Vladimir Perlov:
> > application that could be in use by thousands of people.
> > The application will have some kind of notification mechanism that will
> > be activated if something wrong will appears.
> > Such way we will get statistics and much data about context of the
> > situation.
>
> Something like this, however, seems to be _way_ easier to implement in
> an IDE than in an application server potentially housing a whole load of
> custom applications. In an IDE, telling that "something went wrong" is
> pretty easy (an exception is being thrown and not handled). What happens
> in an application server, given an exception is being thrown? Who's to
> blame if the application involves a couple of more or less loosely
> coupled modules interacting with each other?
>
>
> > Members of Fishcat will have a right to push application of their choice
> > for public to use and test.
>
> This is a good idea in my opinion, if they do have an option to make
> them publicly available, that is. This will provide us with the
> necessary "breadth" to make sure many variants of Java EE applications
> run on top of the platform.
>
>
> > Beside this it makes sense to integrate mechanism of submitting issues
> > directly from Glassfish's admin panel.
>
> ACK on that, as well, at least maybe being a "web form" integrated with
> the admin panel to easier allow for filing a new issue. Maybe a
> "testing" profile for the admin panel with enhanced test-related options?
>
>
> > Another example would be create possibility for people to upload their
> > log for analyze by FichCat team.
> > Obviously we will need to have logs database to handle them in scalable
> > manner.
>
> This won't work, in my opinion, not just partly because of the first
> reason. Looking just at our own application infrastructure, if running
> the environment in LogLevel.FINEST mode, it'll end up providing a good
> gigabyte of logging per day at the very least. Doing log file analysis
> in this dimensions without knowing anything about the applications
> involved seems impossible to me. Adding to that, to reproduce the errors
> eventually it will need a reproducible environment, including databases,
> file systems, and all sort of infrastructure to somehow affect the way
> the application behaves. What if an exception is being thrown trying to
> send an e-mail via JavaMail because the SMTP host doesn't allow for
> connections from the testbed server? And, finally, of course, I think
> there's a boundary we should make between "server infrastructure
> testing" and "application migration support". The latter thing is a
> hard, tedious work from my experience, something which might pretty well
> be done by experienced consultants on-site if the documentation at hand
> doesn't help. For "server infrastructure testing", I think the work
> FishCAT people can do is spending time and effort on trying to break
> down errors, to tell whether or not an error is caused by (a) the server
> itself, (b) a misbehaviour of the server along with some third-party
> code or (c) an application-specific error and subsequently to make sure
> (a) and (b) errors are reported and dealt with in a sane way... :)
>
> Cheers,
> K.
>
>
>
>
> --
> Dipl.-Ing.(BA) Kristian Rink * Software- und Systemingenieur
> planConnect GmbH * Könneritzstr. 33 * 01067 Dresden
> fon: 0351 215 203 71 * cell: 0176 2447 2771 * mail: rink_at_planconnect.de
> Amtsgericht Dresden HRB: 20 015 * St.-Nr. FA DD I 201 / 116 / 05360
> Geschäftsführer: Stefan Voß, Karl Stierstorfer
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: quality-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: quality-help_at_glassfish.dev.java.net
>
_________________________________________________________________
Hotmail has tools for the New Busy. Search, chat and e-mail from your inbox.
http://www.windowslive.com/campaign/thenewbusy?ocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_1