[GLASSFISH-16622] Root applications (context root "/") listen on all virtual servers until server is restarted. Created: 12/May/11  Updated: 14/Oct/11  Resolved: 14/Oct/11

Status: Resolved
Project: glassfish
Component/s: web_container
Affects Version/s: 3.1_b43
Fix Version/s: 4.0_b06

Type: Bug Priority: Major
Reporter: ckuehl Assignee: Amy Roh
Resolution: Cannot Reproduce Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Debian inside VServer


Attachments: XML File domain.xml     Text File server.log    
Tags: 3_1-next, context_root, deployment, virtual_server

 Description   

When I deploy a web application with the context root of "/" via the web administrative panel to a virtual server listening on domain "example.com", the application will act as if deployed to every virtual server, including the admin panel. Restarting the server (via asadmin) fixes the problem (after a restart, it only listens on example.com). This happens on initial deployment of an application and upon redeployment of an application.

When redeploying an application, I am selecting the file and clicking OK. I am not changing any options from their default options. After redeploying, the admin panel will cease the function and will instead show errors (such as resource not found) and act as if I am accessing that resource.



 Comments   
Comment by Hong Zhang [ 13/May/11 ]

I tried with both admin cli and console (specifying the virtual server as part of the deployment), and the domain.xml application-ref enetry has the specified virtual server as expected.
Assign to web team to check if the application is also only loaded on the specified virtual server as expected and follow up with the user.

Comment by ckuehl [ 15/May/11 ]

Thanks for looking into this. I did some further testing and it appears to only happen when redeploying an existing application via the web panel, not during initial deployment as I initially reported.

Comment by Amy Roh [ 17/May/11 ]

Hi ckuehl,

To clarify, you're saying if you redeploy an existing application with the context root of "/" using the admin gui, the application will act as if it deployed to every virtual server including the admin webapp and the admin gui will cease to function until restart, correct?

Does this also happen when you redeploy using admin cli and not the admin gui?

Can you please include your domain.xml and server.log after you redeploy in order for us to understand your exact setup?

Thanks,
Amy

Comment by ckuehl [ 17/May/11 ]

Hi,

Yes, your summary is correct.

I have just tested and it also happens when redeploying via the CLI:

asadmin> redeploy --name GraalCenterAccounts /home/appman/GraalCenterAccounts.war
Enter admin user name> admin
Enter admin password for user "admin">
Application deployed with name GraalCenterAccounts.
Command redeploy executed successfully.

I will attach my domain.xml and server.log.

Thanks again for looking into this.

Comment by ckuehl [ 23/May/11 ]

I'd like to clarify again:

When redeploying, it does not act as if deployed to all virtual servers. Instead, all applications, including the administrative GUI, act as if undeployed. I see the "Your server is now running" page when trying to access other applications.

This is also happening occasionally when using the asadmin cli.

Comment by Amy Roh [ 26/May/11 ]

I tried your scenario on mac and everything works as expected. I'm trying to understand how and if our configurations are different.

I see "User [] from host localhost does not have administration access" in your server.log. How are you accessing the admin gui? Can you access it locally?

Comment by ckuehl [ 28/May/11 ]

I tried to setup reliable steps to replicate this bug but was unable to on a different system than the one it occurred on. I have updated to 3.2-b06 and the problem has resolved itself.

Thanks again for the help.

Comment by Amy Roh [ 31/May/11 ]

Issue resolved as the reporter stated. Couldn't reproduce.





[GLASSFISH-16578] "The log message is null." message logged when auto-deploying app Created: 06/May/11  Updated: 17/Oct/11  Resolved: 09/May/11

Status: Resolved
Project: glassfish
Component/s: web_container
Affects Version/s: 3.1.1, 4.0_b04
Fix Version/s: 3.1.2_b01, 4.0_b06

Type: Bug Priority: Major
Reporter: Dies Koper Assignee: Shing Wai Chan
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

WinXP, GFv3.2_b05


Attachments: File BASIC_TEST.war    

 Description   

I noticed the following error in server.log:

[#|2011-05-07T13:36:35.882+1000|SEVERE|glassfish3.2|javax.enterprise.system.container.web.com.sun.enterprise.glassfish.web|_ThreadID=26;_ThreadName=Thread-1;|The log message is null.|#]

[#|2011-05-07T13:36:35.929+1000|SEVERE|glassfish3.2|javax.enterprise.system.container.web.com.sun.enterprise.glassfish.web|_ThreadID=26;_ThreadName=Thread-1;|The log message is null.|#]

[#|2011-05-07T13:36:36.007+1000|SEVERE|glassfish3.2|javax.enterprise.system.container.web.com.sun.enterprise.glassfish.web|_ThreadID=26;_ThreadName=Thread-1;|The log message is null.|#]

What went wrong??

This is what I did:
1. Fresh install of GFv3.2_b05 on WinXP.
2. Started domain.
3. In the admin console, changed server's VM option:
-Djavax.net.ssl.keyStore=$

{com.sun.aas.instanceRoot}/config/keystore.jks to
-Djavax.net.ssl.keyStore=${com.sun.aas.instanceRoot}

/config/keystore_.jks (file doesn't exist)
4. Copied war file to auto-deploy dir.



 Comments   
Comment by Dies Koper [ 06/May/11 ]

Probably this is caused by a statement in the GF container as follows:

} catch (SomeException e) {
logger.log(Level.SEVERE, e.getMessage());

If e.getMessage() returns null (which is not uncommon for runtime exceptions either!), the logger complains.

To fix it:

logger.log(Level.SEVERE, "msg.key.in.prop.file", (e.getMessage() == null) ? "" : e.getMessage() );

with msg.key.in.prop.file defined in the right LogStrings.properties, starting with a message ID and including

{0}

somewhere for the (optional) exception message.

Comment by Shing Wai Chan [ 09/May/11 ]

The error message is triggered by incorrect root element of glassfish-web.xml.
The xml element should be [glassfish-web-app] rather than [sun-web-app].

I have updated the corresponding message.

Sending src/main/java/com/sun/enterprise/glassfish/web/WarHandler.java
Sending src/main/resources/com/sun/logging/enterprise/system/container/web/LogStrings.properties
Transmitting file data ..
Committed revision 46748.





[GLASSFISH-16539] Integrate Grizzly 2.1 Created: 03/May/11  Updated: 10/May/11  Resolved: 10/May/11

Status: Resolved
Project: glassfish
Component/s: None
Affects Version/s: 4.0_b04
Fix Version/s: 4.0_b06

Type: Task Priority: Major
Reporter: Ryan Lubke Assignee: Ryan Lubke
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Dependency
depends on GLASSFISH-16538 FighterFish depends on Grizzly 1.9. ... Resolved

 Description   

Task to associate the Grizzly 2.0 integration commit with an issue.



 Comments   
Comment by Ryan Lubke [ 03/May/11 ]

Currently blocked by GLASSFISH-16538.

Comment by Sanjeeb Sahoo [ 04/May/11 ]

Will Grizzly 2.1 be integrated into 3.1.1 or only 3.2?

Comment by Justin Lee [ 04/May/11 ]

Only 3.2





Generated at Fri May 29 22:53:05 UTC 2015 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.