This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 216574 - Glassfish domain dir must be writable
Summary: Glassfish domain dir must be writable
Status: RESOLVED WORKSFORME
Alias: None
Product: serverplugins
Classification: Unclassified
Component: GlassFish (show other bugs)
Version: 7.2
Hardware: PC Linux
: P3 normal (vote)
Assignee: TomasKraus
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-08-09 08:03 UTC by ljelonek
Modified: 2013-08-05 17:26 UTC (History)
2 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description ljelonek 2012-08-09 08:03:09 UTC
I experienced a strange behaviour in my netbeans installation: On each start of the IDE a new glassfish domain was created. The problem was that I installed netbeans ide as root and used it as another user. My normal user should not have any write permissions to the netbeans and glassfish installation as I am working on a multi user system sharing a single installation of both.

I located a possible location that might be responsible for this behaviour:

Module glassfish.comon: 
CommonServerSupport.java: 

259 if (candidate.exists() && !Utils.canWrite(candidate)) { 
...

where candidate seems to be the domain directory. The code afterwards does not check if a domain already exists and thus creates a new one on each startup.

For my personal installation on a single user linux system I got it fixed by giving write permissions to the domains folder, but on our multi user system this is definitely nothing that should be done.
Comment 1 TomasKraus 2012-09-07 13:59:51 UTC
Local domain directory must be writeable. GlassFish process is run with NetBeans user UID and it needs write access to several places in domain directory structure (logs, domain.xml, deployed applications, etc.).

Configuring domain directory without write access makes no sense. In such a case 
configure GlassFish server as remote and you do not have to provide domain directory.
Especially when you need to work with with multi user system shared by more users and having GlassFish domain under some special 'glassfish' user the only way to go is to register remote domain.
Comment 2 Vince Kraemer 2012-09-07 17:06:05 UTC
there is code that should be creating a user writable personal domain (in their home directory) and registering that when the user starts an instance of NB with GF that was installed by root.

It looks like that code has a bug and should probably be fixed.

Please investigate this and find a fix... Telling the user, "Don't do that" is probably not the right choice.
Comment 3 TomasKraus 2012-09-10 09:54:41 UTC
Well, this piece of code does not exist in 7.3. We did a lot of changes around server startup and creating a new domain would never happen there.

But if this is happening there must be local read-only domain registered with GlassFish and that's wrong anyway. This should be resolved in server registration wizard, not during server startup.

If user has problem like this, he should follow this way when configuring server:
1) Server Location: Point installation location to his GlassFish installation directory, click Next
2) Domain Location: Select 'Register Local Domain' and put a new directory where new domain will be created, e.g. /home/someUser/glassfish/domain and it will create new domain in user's home directory using asadmin create-domain. Last existing directory (e.g. /home/someUser) must exist and be writeable by user. Rest of the path (e.g. glassfish/domain) will be created.

I was just explaining why it's not possible to use read-only domain with GlassFish and creating new domain during startup would just confuse users even more.
Comment 4 Vince Kraemer 2012-09-10 14:10:09 UTC
In the past, the user has not needed to perform additional steps after installing NB and starting it to start developing and deploying their Java EE apps.  It seems like you are saying that folks using NB on a shared Linux system or install NB in c:\Program Files on a modern Windows system will have to perform extra steps to start doing development with 7.3.

That seems like a regression to me.  I think other users will be surprised by this change also...
Comment 5 TomasKraus 2012-09-10 14:55:12 UTC
I remember this code. It was trying to create domain on the fly during startup. and I understand your point of view.

But it was doing something at the background - e.g. creating directory structure with private domain - without user's explicit request. This is wrong anyway, software should not behave like this.

Doing something in user's directory must be based on his request. In our case this request is coming from server registration wizard where user decides whether or not he wants to create his private domain. If he decides to use default one and it's read only or non existent, all we can do is to complain with some error messages. We shall not start creating files without his explicit request.
Comment 6 TomasKraus 2012-09-10 15:23:35 UTC
Vince, if you really want to keep previous behaviour, it should inform user about an attempt do do something on the disk.
There are 2 things on my mind:

1) Allowing GlassFish config changes (those from wizard) also in Services:servers:GF instance -> Properties. Actually almost nothing can be changed there once GF is registered.

This is quite complicated and it's too late to dig up properties GUI in 7.3. but I can do it in 7.4 and I believe users would be happy with such a change.

2) Showing popup during server startup when domain directory is read only and allowing user to choose where to create a new domain for him.

This won't be too much complicated and think I can put this into 7.3.
Comment 7 Vince Kraemer 2012-09-10 16:50:45 UTC
(In reply to comment #6)
> Vince, if you really want to keep previous behaviour, it should inform user
> about an attempt do do something on the disk.
> There are 2 things on my mind:
> 
> 1) Allowing GlassFish config changes (those from wizard) also in
> Services:servers:GF instance -> Properties. Actually almost nothing can be
> changed there once GF is registered.
> 
> This is quite complicated and it's too late to dig up properties GUI in 7.3.
> but I can do it in 7.4 and I believe users would be happy with such a change.
> 
> 2) Showing popup during server startup when domain directory is read only and
> allowing user to choose where to create a new domain for him.
> 
> This won't be too much complicated and think I can put this into 7.3.

Users need to be able to do the following things without additional steps...

1. install NB with GF as root.
2. start NB as their 'normal' user id.
3. create a project that targets the domain that was registered automatically.
4. run that project.

We can open a dialog that says, "hey... we are going to create a domain for your development"

That dialog would probably have to appear between step 2 and step 3.

The installation's default domain (which is owned by root) should never be visible to the user from inside the IDE...
Comment 8 Jiri Skrivanek 2012-09-11 10:18:59 UTC
I tried it on Linux and new domain was created just once. It is reused after every restart, i.e. new domain is not created. Just there are two domains which is not correct but I can't confirm behaviour described in original description by ljelonek. I think we can keep current behaviour when domain is created in userdir because NetBeans writes to the userdir anyway (without prompting user).

My steps:

sudo work/netbeans-trunk-nightly-201209110001-javaee-linux.sh --javahome /home/tester/work/jdk1.7.0_04
- run NetBeans using Applications|Programming|NetBeans
- expand Services|GlassFish node
- it created new domain and now I have

/home/tester/.netbeans/dev/config/GF3
/home/tester/.netbeans/dev/config/GF3_1

- after IDE restart it uses always GF3_1 domain

Product Version: NetBeans IDE Dev (Build 201209110001)
Java: 1.7.0_04; Java HotSpot(TM) Client VM 23.0-b21
System: Linux version 2.6.38-8-generic running on i386; UTF-8; en_US (nb)
Comment 9 TomasKraus 2012-09-11 16:11:52 UTC
I'll verify this behaviour. GF3_1 domain is not needed.

Now back to Vince's proposal. We should handle both situation - GF coming with installation and from registration wizard. In both cases GF may be installed under another UID.

I'll follow your last comment. But I have to check what's really happening in NetBeans now first. 

Also in case we have read-only domain with GF coming from wizard I would like to improve wizard checks to not offer read-only domain at all and force user to register his own immediately. If this fails for some reason, your proposal is still good backup solution.
Comment 10 Vince Kraemer 2012-09-11 16:16:33 UTC
last I knew, the registration wizard was checking for read-only ness and would not allow the user to register a domain that was not user writable.
Comment 11 TomasKraus 2013-04-03 13:06:59 UTC
Yes, registration wizard asks user to create his own domain in home directory.
Server is then started using this newly created domain. This is correct behaviour.
I just have to find out how to simulate second option - server coming with NetBeans and registered during installation.
Comment 12 TomasKraus 2013-08-05 17:26:02 UTC
Testing after Bug# 233789 fix with dev build 201308042300.
NetBeans installed as root to get read only GF domain.
Opening properties and see
Domains folder: /home/kratz/.netbeans/dev/config/GF_4.0
Started GF server and everything works fine.

Do not see any GF_4.0_1
Opening new web project, clicking Run. Everything works fine.

I'm closing this bug as works for me and adding note to test it with Bug# 233789 fix.