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 139765 - Server and port settings in project properties not always noticed
Summary: Server and port settings in project properties not always noticed
Status: NEW
Alias: None
Product: ruby
Classification: Unclassified
Component: Rails (show other bugs)
Version: 6.x
Hardware: All All
: P4 blocker (vote)
Assignee: issues@ruby
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-07-11 20:53 UTC by Chris Kutler
Modified: 2011-01-28 20:12 UTC (History)
0 users

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 Chris Kutler 2008-07-11 20:53:30 UTC
This is an intermittent problem.

Here are steps to reproduce, but it doesn't always reproduce

Create the Depot sample app. Do a rake > rails update. Migrate the database.

Right-click the project node and choose Properties.

Make the server WEBrick and the port 3000.

Run the project 

Go back to the properties and change the server to GlassFish and leave the port 3000 (I know this isn't correct but do
it anyway).

Run the project. It runs in the WEBrick server.

Now change the server to 8080. It still runs in the WEBrick server. If you stop the WEBrick server it will then try to
run it in GlassFish.

I noticed this problem when I changed the server but forgot to change the port number. After fixing the port number to
match the server, the IDE was still using the old port number. 

The work around is to stop the servers before rerunning (I think).
Comment 1 Erno Mononen 2008-09-10 13:36:05 UTC
Yes, the workaround is to stop the server before rerunning. If a server instance is running for a project, the run 
action will use that automatically. Looks like it should check whether the server configuration has changed and if it 
has, stop the current server process and start a new one. I think is not a particularly common scenario though, and the 
workaround is straightforward, so I'm downgrading this to P4.