Skip to main content

Multiple web-apps, Domains

10 replies [Last post]
seagate
Offline
Joined: 2009-06-03
Points: 0

Hi,

I have 2 web-applications and 2 different domain names.

The web-apps are deployed to ${com.sun.aas.instanceRoot}/applications/j2ee-modules/

How can I ensure, that going to www.my-dom.com glassfish points automatically into the deployment directory?

if I enter ${com.sun.aas.instanceRoot}/applications/j2ee-modules/ this to the docroot, it won't be considered.

as well the context-path does not solve the problem.

The deployed web apps should start from the deployment directory. I don't want to go for a proxy solution, multiple instances and as well not for multiple domains.

is there any solution to tell in sun-web.xml, that the start directory of a domain is
${com.sun.aas.instanceRoot}/applications/j2ee-modules/

how can I achieve this?

Btw: I have apache and mod_jk running, and this works so far, that requests to the domain name on port 80 are internally forwarded to the glassfish server.

Thank you very much in advance, any help / suggestions are much appreciated.

Regards,
Dave.

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
seagate
Offline
Joined: 2009-06-03
Points: 0

Hi,

thanks for your answer.

I did not say, that GlassFish has a security vulnerability. I meant, that for security issues we do not want to have the application produced cookies and make session tracking with them.

This is to the browser has a security vulnerability (missing updates, what we can not check on the user's side) and someone steals the cookie and conducts a session highjacking.

The problem is:

A wep-app is deployed and associated to a particular virtual host, and in sun-web.xml are the following values:

GlassFish V2.1 tells you on startup, that urlRewriting is not yet implemented.

Even if enable Cookies is set to false, the URL won't be appended as long you really switch off using cookies in the browser. We would like to ensure, that the jsessionid is ALWAYS appended to the url.

It should be possible anyway, to start a deployed web-app from its deployment directory: $GF-ROOT/applications/j2ee-modules/myapp

if you enter this to the docroot, it is not considered in GF V2.1 and V3

The context root obviously points always to $GF-ROOT/docroot/$context-root, not to the directory where the app is deployed to.

Regards,
Dave

Jan Luehe

Dave,

On 06/ 4/09 09:39 PM, glassfish@javadesktop.org wrote:
> Hi,
>
> thanks for your answer.
>
> I did not say, that GlassFish has a security vulnerability. I meant, that for security issues we do not want to have the application produced cookies and make session tracking with them.
>
> This is to the browser has a security vulnerability (missing updates, what we can not check on the user's side) and someone steals the cookie and conducts a session highjacking.
>
> The problem is:
>
> A wep-app is deployed and associated to a particular virtual host, and in sun-web.xml are the following values:
>
>
>
>
> GlassFish V2.1 tells you on startup, that urlRewriting is not yet implemented.
>

This has been fixed in the meantime, see

https://glassfish.dev.java.net/issues/show_bug.cgi?id=4394
("server log message says enableURLRewriting is not supported")

for details.

> Even if enable Cookies is set to false, the URL won't be appended as long you really switch off using cookies in the browser. We would like to ensure, that the jsessionid is ALWAYS appended to the url.
>
> It should be possible anyway, to start a deployed web-app from its deployment directory: $GF-ROOT/applications/j2ee-modules/myapp
>
> if you enter this to the docroot, it is not considered in GF V2.1 and V3
>
> The context root obviously points always to $GF-ROOT/docroot/$context-root, not to the directory where the app is deployed to.
>

There is a difference between "docroot" and "context root":
"docroot" points to the physical location where your webapp and its
resources are located,
and is never reflected in its "context root", which is a component of
the URI used to access
its resources over HTTP.

Jan

> Regards,
> Dave
> [Message sent by forum member 'seagate' (seagate)]
>
> http://forums.java.net/jive/thread.jspa?messageID=349235
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
> For additional commands, e-mail: users-help@glassfish.dev.java.net
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net

Wolfram Rittmeyer

glassfish@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)]

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net

whartung
Offline
Joined: 2003-06-13
Points: 0

> 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.

You mean that Virtual Server Support in GlassFish is full of bugs? GF v2.1 or GF v3?

> 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.

What does this have to do with virtual servers? How is this a bug? How is this a security issue?

In my experience, Virtual Servers in GF v2 Just Works, and that's what Wolfram is talking about for your issue.

Virtual Servers are where you have a single GF instance serving up content as different Hosts. HTTP v1.1 includes a Host header field on every request, and GF (among other servers) uses that to route requests to the proper "virtual host". You don't need to set up any extra instances or ports or anything.

You create a new Virtual Server, and you tell it what domain, or list of domains, it will be responding too (e.g. example.com).

You then tell that Virutal Server which listener (or listeners) to use, and here you would likely use the default http-listener-1 (which listens to 0.0.0.0:8080 by default, or if you changed it, likely 0.0.0.0:80, which means "all IP addresses for this host on port 80").

Once you have the Virtual Server configured, you can then deploy your web apps.

When you deploy a web app, if you don't specify a Virtual Server, GF deploys it to "all of them". If you happen to deploy 2 Web Apps both configured for the Root context, you will get an error when you try to deploy the second one, since the root context is "already taken".

Thus, you need to target your WAR deployment to a specific Virtual Server.

And, that's it! GF handles the rest.

No new IPs, no new ports, nothin. Works a treat. It's simple and straightforward to configure.

Two issues that I've had in the past is that GF won't let you put a "non-exisitent" host in the list of host for the Virtual Server (i.e. if DNS doesn't know about that host, you'll get an error). Also, that list of hosts couldn't have any white space (i.e. "example1.com,example2.com" was OK, but "example1.com, example2.com" was not).

The first issue is an FYI, I won't call it a bug, just, perhaps, a feature I don't care for. The second is a "bug", and I recall logging it, and it may well be fixed by now. If not, it's not a big deal. Just FYI on that.

JSESSIONID shouldn't be a problem, but I don't know. If you can "share" a JSESSIONID across Virtual Servers, then I'd log that as a bug. I doubt that's happening (since JSESSIONID is tied to the actual web app which is a different layer of the server), but if it is, that would be interesting information. I haven't tested it so I can't say.

Jan Luehe

On 06/ 4/09 03:35 PM, glassfish@javadesktop.org wrote:
>
>> 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.
>>
>
> What does this have to do with virtual servers? How is this a bug? How is this a security issue?
>

I agree with Wolfram (thanks, Wolfram and Martin, for stepping in).

I'm actually having a hard time understanding what Dave meant.

Dave, can you give an example where a JSESSIONID was not appended
to a URL when you thought it should have been?

If you have a webapp ("mywebapp.war") deployed at "/mywebapp", and you're
accessing a resource in "mywebapp.war" that creates an HTTP session,
then the session's
JSESSIONID will be appended to only those URIs that also start with
"/mywebapp",
because sessions are scoped to webapps.

For example, if you are redirecting to a URI that starts with
"/myotherwebapp", then the
JSESSIONID will not be appended, because you'll be crossing webapp (and
therefore
session manager) boundaries.

Does this answer your question?

Jan

>
> http://forums.java.net/jive/thread.jspa?messageID=349214
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
> For additional commands, e-mail: users-help@glassfish.dev.java.net
>
>

[att1.html]

Wolfram Rittmeyer

Just to get your question right:
You have two apps, say webapp1 and webapp2. And you have two domains,
say domain1.com and domain2.com.

Thus any request to http://www.domain1.com should be served by webapp1
and to http://www.domain2.com should be served by webapp2 without the
need to specify any additional contextpath?

If this is what you want to achieve, you essentially have to do two things:

First create virtual servers for both of your domains. Either using the
admin console or asadmin:

asadmin create-virtual-server --hosts www.domain1.com,domain1.com
--httplisteners http-listener-1,http-listener-2 domain1

Then you have to deploy your apps and tell them to use these virtual
servers. Again you can do this using the admin console or asadmin:

asadmin deploy --name nosilverbullet --virtualservers domain1
--contextroot / yourWebapp1.war

For this to work, your virtual server should _not_ use any default web
modules.

More about this can be found at Jan's and my blogs:
http://blogs.sun.com/jluehe/entry/virtual_hosting_features_in_glassfish
http://weblogs.java.net/blog/writtmeyer/archive/2008/02/virtual_servers....

--
Wolfram Rittmeyer

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net

seagate
Offline
Joined: 2009-06-03
Points: 0

Hi Wolfram,

thanks a lot for your reply! (from your name I assume you are German, like me...?)

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.

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.

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.

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.

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.

Nevertheless: GlassFish v3.0-SNAPSHOT (build b49) is open by default anonymously - no PW requiered.

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

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.

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.

Best Regards,

Dave

Managing Director
[DE]SYSTEMS ENGINEERING Ltd.
Sun Principal Partner
www.dese.co.uk
contact[\at/]dese.co.uk

Martin, Ray

Do you have a list of "that GlassFish is full of bugs"?

-----Original Message-----
From: glassfish@javadesktop.org [mailto:glassfish@javadesktop.org]
Sent: Thursday, June 04, 2009 4:13 PM
To: users@glassfish.dev.java.net
Subject: Re: Multiple web-apps, Domains

Hi Wolfram,

thanks a lot for your reply! (from your name I assume you are German,
like me...?)

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.

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.

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.

Following the advices of
http://weblogs.java.net/blog/jfarcand/archive/2008/08/fronting_glassf.ht
ml 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.

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.

Nevertheless: GlassFish v3.0-SNAPSHOT (build b49) is open by default
anonymously - no PW requiered.

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

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.

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.

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)]

http://forums.java.net/jive/thread.jspa?messageID=349187

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net

seagate
Offline
Joined: 2009-06-03
Points: 0

Yes, I do. Please refer to the previous posting, what is not complete yet to avoid to have the issue blown out it its proportion.

From this point of view answering to questions is a good practice than raising more of them.

Thanks,
Dave.

Martin, Ray

I would appreciate a copy of the list of bugs. Thanx. Much obliged.

-----Original Message-----
From: glassfish@javadesktop.org [mailto:glassfish@javadesktop.org]
Sent: Thursday, June 04, 2009 4:35 PM
To: users@glassfish.dev.java.net
Subject: Re: RE: Re: Multiple web-apps, Domains

Yes, I do. Please refer to the previous posting, what is not complete
yet to avoid to have the issue blown out it its proportion.

>From this point of view answering to questions is a good practice than
raising more of them.

Thanks,
Dave.
[Message sent by forum member 'seagate' (seagate)]

http://forums.java.net/jive/thread.jspa?messageID=349193

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net