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