glassfish_at_javadesktop.org wrote:
> Hi Wolfram,
>
> thanks a lot for your reply! (from your name I assume you are German, like me...?)
Yes, I am. Though your name, Dave, doesn't sound very German ;-)
> However, it is indeed not a good practice, to issue a new port for a any new virutal host, this matter was addressed very early to the GlassFish developer team, and seems not to have been considered even in the latest releases of V3-Prelude.
This is a misunderstanding. There is absolutely no need for different
ports. It is just a possibility pointed out by Jan in his blog posting,
but no necessity.
I actually have four domains running on GlassFish using virtual hosts,
using different webapps for each domain and all virtual servers use the
same http-listener and thus the same port. That is actually what you
would achieve with the asadmin commands I have posted (have a look at
the second blog entry I had posted in my previous reply).
> The VirtualHost Support of GlassFish is obviously an administrator's burden no one can take. This is to the fact, that GlassFish is full of bugs.
I consider this to by straightforward. But if you have suggestions for a
more user-friendly way to achieve the desired result the community will
certainly listen. We are very keen on suggestions of any kind. You could
use this mailing list - or even better post requests of enhancement or
issue bug reports on the issue tracker.
> The V2.1 only appends the jsessionid to the url, if the particular app runs either in context root / or if the main applett carries the same name as the package itself (war-file-name).
>
> If you have to deny cookies for security reasons you'll go precisely through a surprise.
>
> As well it seems, that the GlassFish developer team turns a blind eye on the sparc platforms for some reason. It is usual, that you have a server running without a gui desktop in place. The -c option is completely missing to install the pack in console mode.
Can't say much about Sparc, but on x86-Linux it was no problem at all to
install GlassFish without an installed Xserver. I agree that this is a
_must be_ feature. So if this really doesn't work, please issue a bug
report.
> Following the advices of http://weblogs.java.net/blog/jfarcand/archive/2008/08/fronting_glassf.html to get the mod_jk connector up and running screws not only your glassfish, it screws yourself as well as you can't face the reason why.
Could you please elaborate on this. What actually screwed up in which way?
> If you use the update tool in V3, install the recommended updates/add-ons and restart the GF, you'll end up in re-installing your GF. This is to being not able to start your domain anymore.
v3 is a preview at this point in time - so some issues are to be
expected. Nevertheless there are varying degrees of stability - due to
different levels of testing before their respective release. Nightly is
the least stable, promoted builds are better tested and finally there is
the prelude release that is the most tested of the v3 line. Nightly and
promoted of course might contain features that are not yet part of the
prelude release.
> Nevertheless: GlassFish v3.0-SNAPSHOT (build b49) is open by default anonymously - no PW requiered.
>
Any default installation of any server - whether it uses a default
password or none at all - is insecure. It is a common requirement for
any server I have seen so far to change passwords after installation or
provide one during installation.
> If you set up the admin user / or assign a PW to the default anonymous user, you can not stop the domain from the command line.
>
> But you can perform this task by simply issuing: pkill java (!!!!!!)
>
> GlassFish v3.0-SNAPSHOT (build b49) does not write the docroot value to domain.xml, even if you define the parameter in that file, it won't be recogniced by the web frontend.
>
> On this side we started with V2.1 -> V2.1 HDAB -> V3 GlassFish v3.0-SNAPSHOT (build b49).
>
>>>From release to release the performance / throughput is reducing a lot. Everything gets much slower.
>
> Finally, a well documentation for Virtual Host Environments without the need of:
> - additional ports
> - additional instances
> - additional domains
What exactly is missing? Creating virtual servers as well as deploying
applications and configuring them to run on a virtual server is both
well documented in my opinion (e.g. in the online help for the admin
console or the pdf files you can download from SUN's site). Of course
nothing is perfect and we probably have missed a lot. Thus for GlassFish
to improve it would be nice if you could highlight what exactly disturbs
you the most.
> would be a nice to have.
>
> All these issues Macromedia could arrange years ago with Coldfusion MX Enterprise.
>
> And speaking frankly to you: I am currently very pissed as we have a lot of development work to do for clients requiring GlassFish. But the documentation is poor, and even if you follow up with them, you fail. You have to fight with bugs and confusing release names.
>
> The response time of that forum here is more than poor.
Hm. This week the JavaONE has probably caused all core developers of
GlassFish to be pretty busy. And others on this list (like me) help in
their spare time. I think the response time is pretty normal (if not
good) for an open source project. Of course there is always the
possibility of a support contract if you need faster responses.
> Btw: What is the difference between V3-Preview and V3-Prelude?
>
> And if Java App-Server require multiple instances/domains/ports to provide virtual host facilities, than how would we end up?
>
> Back to the roots of the internet? Every Domain gets it's own server system?
>
> This precisely ends up in having more server machines running in Europe than citizens!
>
> However, I'll take a look to Tomcat and JBoss if it much easier and more well documentaded than GlassFish.
Well I have worked with both for years and I consider them to be very
good products. I nevertheless personally happen to prefer GlassFish.
Contrary to you I consider GlassFish to be the best documented open
source server. It has a very nice administration interface and a
powerful command line tool. And supporting the newest Java EE-API is
just another plus of GlassFish. You might differ, of course ;-)
But I nevertheless hope that you help us improve GlassFish even further
by posting detailed bug reports and requests for enhancement where you
see possibilities for improvement and better usability. Any open source
projects depends on its users to state what they need and to point out
deficiencies. That's true for Tomcat and JBoss as well as for us.
Thanks,
Wolfram Rittmeyer
>
> Best Regards,
>
> Dave
>
> Managing Director
> [DE]SYSTEMS ENGINEERING Ltd.
> Sun Principal Partner
> www.dese.co.uk
> contact[\at/]dese.co.uk
> [Message sent by forum member 'seagate' (seagate)]