Issue Details (XML | Word | Printable)

Key: GLASSFISH-18228
Type: Bug Bug
Status: Resolved Resolved
Resolution: Fixed
Priority: Major Major
Assignee: Sanjeeb Sahoo
Reporter: aaronjwhiteside
Votes: 0
Watchers: 0
Operations

If you were logged in you would be able to see more operations.
glassfish

The OSGi Admin Console seems to randomly swap between port 8080 and 4848

Created: 19/Jan/12 10:50 PM   Updated: 19/Mar/12 10:26 PM   Resolved: 24/Jan/12 06:16 PM
Component/s: OSGi
Affects Version/s: None
Fix Version/s: 3.1.2_b19, 4.0_b21

Time Tracking:
Not Specified

Status Whiteboard:

Workaround:
In order to cause webconsole to bind to HTTP Service listen on 8080 (default http port), create a file called
glassfish/domain1/autodeploy/bundles/org.apache.felix.webconsole.internal.servlet.OsgiManager.cfg
with following content:
http.service.filter=VirtualServer=server

Tags: 3_1_2_approved
Participants: aaronjwhiteside and Sanjeeb Sahoo


 Description  « Hide

The OSGi Admin Console seems to randomly swap between port 8080 and 4848

When running on 8080 it is accessible from the Server -> OSGi Console link under http://localhost:4848/

However when it magically/randomly flips to running on 4848 the Server -> OSGi Console link returns a 404 error.

I haven't done enough investigation to determine what is causing the port flipping. But it seems extremely strange that it happens at all.

Off the top of my head (without any investigation), if two instances of HttpService are registered the ordering would be random and sometimes it gets the correct one and others it gets the wrong one... shrug



Sanjeeb Sahoo added a comment - 21/Jan/12 08:33 AM

Yes, I have seen this issue and the submitter has analysed it correctly, thanks. This is a regression. See GLASSFISH-12359 where we had earlier fixed the issue, but it has resurfaced as we have stoppsed picking cfg files from modules/autostart/.


Sanjeeb Sahoo added a comment - 21/Jan/12 08:42 AM

See workaround.


Sanjeeb Sahoo added a comment - 24/Jan/12 06:36 AM - edited

trunk: svn rev #52257

A appserver/osgi-platforms/felix-webconsole-extension/src/main/java/org/glassfish/osgi/felixwebconsoleextension/FelixWebConsoleExtensionActivator.java
A appserver/osgi-platforms/felix-webconsole-extension/src/main/java/org/glassfish/osgi/felixwebconsoleextension/GlassFishBrandingPlugin.java
D appserver/osgi-platforms/felix-webconsole-extension/src/main/resources/META-INF/webconsole.properties
M appserver/osgi-platforms/felix-webconsole-extension/osgi.bundle
M appserver/osgi-platforms/felix-webconsole-extension/pom.xml
D nucleus/osgi-platforms/felix/src/main/resources/glassfish/modules/autostart/org.apache.felix.webconsole.internal.servlet.OsgiManager.cfg

trunk: svn rev #52272

M appserver/packager/felix/src/main/resources/pkg_proto.py


Sanjeeb Sahoo added a comment - 24/Jan/12 06:43 AM
  • What is the impact on the customer of the bug?

Yes, this is a regression. It has been filed by a user and seen by others as well.

  • What is the cost/risk of fixing the bug?

No risk, as the fix is in an addon component.

  • Is there an impact on documentation or message strings?

No.

  • Which tests should QA (re)run to verify the fix did not destabilize GlassFish?

NA

  • Which is the targeted build of 3.1.2 for this fix?
    b19

Sanjeeb Sahoo added a comment - 24/Jan/12 06:16 PM

3.1.2 branch:
Sending osgi-platforms/felix/src/main/resources/glassfish/modules/autostart
Deleting osgi-platforms/felix/src/main/resources/glassfish/modules/autostart/org.apache.felix.webconsole.internal.servlet.OsgiManager.cfg
Sending osgi-platforms/felix-webconsole-extension
Sending osgi-platforms/felix-webconsole-extension/osgi.bundle
Sending osgi-platforms/felix-webconsole-extension/pom.xml
Adding osgi-platforms/felix-webconsole-extension/src/main/java
Adding osgi-platforms/felix-webconsole-extension/src/main/java/org
Adding osgi-platforms/felix-webconsole-extension/src/main/java/org/glassfish
Adding osgi-platforms/felix-webconsole-extension/src/main/java/org/glassfish/osgi
Adding osgi-platforms/felix-webconsole-extension/src/main/java/org/glassfish/osgi/felixwebconsoleextension
Adding osgi-platforms/felix-webconsole-extension/src/main/java/org/glassfish/osgi/felixwebconsoleextension/FelixWebConsoleExtensionActivator.java
Adding osgi-platforms/felix-webconsole-extension/src/main/java/org/glassfish/osgi/felixwebconsoleextension/GlassFishBrandingPlugin.java
Deleting osgi-platforms/felix-webconsole-extension/src/main/resources/META-INF/webconsole.properties
Sending packager/felix/src/main/resources/pkg_proto.py
Transmitting file data ...
Committed revision 52276.


aaronjwhiteside added a comment - 14/Mar/12 08:17 PM

This isn't actually fixed in 3.1.2 - it is still happening...


Sanjeeb Sahoo added a comment - 15/Mar/12 08:39 AM

Are you sure it didn't work for you? I specifically bind the web console to http service corresponding to port 8080, so I can't understand why it didn't work for you. I tried reproducing and could not. I doubt you are not using correct version of glassfish-osgi-gui.zip. Download version 3.1.2 of this zip and use.


aaronjwhiteside added a comment - 15/Mar/12 04:49 PM - edited

Shouldn't it be bound to the admin listener and not the normal server/application http listener?

We typically restrict access to the admin ports, even though the osgi console is password protected I'd rather not have it be served up at all to clients.

Btw the glassfish-osgi-gui.zip artifact hasn't been pushed out to the maven repositories yet. I know I can use the auto update tool, but that's not how we deploy into production (we pre-package everything into a tar.gz using the maven assembly plugin). So if you could ensure that everything is published correctly I would be grateful.

http://mvnrepository.com/artifact/org.glassfish.packager/glassfish-osgi-gui

I assume the -bx versions are not the official stable/final releases?


Sanjeeb Sahoo added a comment - 15/Mar/12 06:09 PM

You are looking at the wrong artifact. Our build team have renamed the groupId for some good reason. The artifact is actually available at:

http://search.maven.org/#artifactdetails|org.glassfish.main.packager|glassfish-osgi-gui|3.1.2|distribution-base-zip

Whether the console should be available at 8080 or 4848 is a different issue. We have currently made it available at 8080. If you want to change it to 4848, please try adding autodeploy/bundles/org.apache.felix.webconsole.internal.servlet.OsgiManager.cfg with following content:
http.service.filter=VirtualServer=__asadmin


aaronjwhiteside added a comment - 15/Mar/12 06:19 PM

Oh thanks for the info about the groupId rename, much appreciated.

Will the link in the admin console to the osgi console still work if I adding the custom OsgiManager.cfg file?


Sanjeeb Sahoo added a comment - 15/Mar/12 06:33 PM

yes, the cfg file should still work.


aaronjwhiteside added a comment - 16/Mar/12 05:50 PM

I tried putting the org.apache.felix.webconsole.internal.servlet.OsgiManager.cfg file under modules/autostart but it doesn't seem to work there. I don't want to put it under <domain>/autodeploy/bundles as it is a system level configuration detail and not related to the application.


Sanjeeb Sahoo added a comment - 16/Mar/12 06:03 PM

No, you can't put it under modules/autostart. You have to place it under a directory that's monitored by fileinstall and autodeploy/bundles/ is that directory.


aaronjwhiteside added a comment - 16/Mar/12 06:06 PM

OK, do you want me to open another bug to have the OSGi console run on the admin listener (4848) instead of the http-listener (8080)? Or can you reuse this issue?


Sanjeeb Sahoo added a comment - 16/Mar/12 06:13 PM

Pl. open a new enhancement request if you are not able to configure it using cfg file as suggested earlier.

I don't understand your point of using modules/autostart for cfg file. You are not supposed to modify anything inside installation directory. domain_dir is a user controlled area and hence you should use that to do any domain level configuration such as this.


aaronjwhiteside added a comment - 16/Mar/12 08:13 PM

I'll open a new issue, the point was I shouldn't have to be telling the OSGi console to run on the admin port. It should be doing that by default. Running an admin console even if it is OSGi's admin console on the normal application port (8080) is not a good idea, IMHO.


Sanjeeb Sahoo added a comment - 17/Mar/12 03:57 AM

I certainly don't understand why admin port is different from 8080 for an appserver. What advantage it has for an app server which is always behind firewall? Do you understand?


aaronjwhiteside added a comment - 19/Mar/12 10:26 PM

Usually only the admin port is locked behind a firewall... and 8080 is mapped to 80 on the outside world. My point is it requires extra effort to block /osgi/* at the load balancer while allowing everything else through.

If the default were to keep all the administration related functionality restricted to the admin port (4848) then we wouldn't need any extra configuration to block access to /osgi/*.