试图通过GlassFish在Netbeans上运行Vaadin Web应用程序项目，但是服务器显然没有自动启动

Question

So as the title of this question indicates, I'm working with a Vaadin project on Netbeans. Upon running the GlassFish server in ISOLATION, there is no issue at all; the output log for both the Java Database DB Process and GlassFish Server show no errors. As further evidence, I can successfully go to the localhost server that was started, seen in this screenshot:

As seen in the URL, the port I selected for this server was 8080 (the admin port is 4848, and I can successfully go there, too). However, when I run my Vaadin project, which I was under the assumption would automatically start the server and then display the results of running the project there (as per https://vaadin.com/docs/v8/framework/getting-started/getting-started-netbeans.html ), I can't even connect to localhost:8080 anymore. For reference, I do have the server selected in the project options (Right click on my project -> properties -> run -> Server [dropdown]).

I originally thought that it was just some sort of issue with code inside my project (and that might be part of it), but what dissuades me from that assumption are the following:

1) The project builds successfully, with no failure statements whatsoever

2) The icon for the server does not display the green play sign next to it (I'm using GlassFish Server, not the Mark 2 one, but neither show the sign anyways), which it does when i run it in isolation:

3) There is a significant difference between when I just run the project vs. when I start the server manually and THEN run the project. For reference, here is the result of me attempting to connect to the server after only running the project:

Here is the result of accessing the server after first manually starting up the server and then running the project; note that the name of the project is nchandlerv2, but regardless of what I put after localhost:8080/ (for example in the below picture, I used nchandl, which I thought would have completely failed):

However, what's particularly confusing to me is that in this case, I can still go to localhost:8080 just fine (as long as nothing is appended after it). So I guess my questions boil down to the following:

1) Why does the server not automatically start when I run the project (or at least, why does it seem that way)? I've provided the code for the init method of my project at the bottom, but I thought that was really all that was needed for the project to be runnable (my MainUI class extends UI (which itself is from Vaadin) and then overwrites the init method) 2) Why does the server encounter an HTTP error when I first manually start the server and then run the project?

Here's the code:

import com.vaadin.annotations.Push;
import com.vaadin.annotations.Theme;
import com.vaadin.annotations.VaadinServletConfiguration;
import com.vaadin.server.Page;
import com.vaadin.server.VaadinRequest;
import com.vaadin.server.VaadinServlet;
import com.vaadin.ui.themes.ValoTheme;
import com.cisco.stbarth.netconf.anc.NetconfSSHClient;
import com.vaadin.ui.UI;

import java.util.Collection;
import java.util.LinkedHashMap;
import java.util.ArrayList;
import javax.servlet.annotation.WebServlet;


@Theme("adtportal")
@Push
public class MainUI extends UI{
    String hostName;
    String ssh_ip;
    String username;
    String password;
    String pathToYangRepoHTTP;
    //String pathToYangRepoSCP;  <<TO BE USED POTENTIALLY LATER>>
    //The below returns in the format: [(SC1, ([YP1_1, YC1_1, XML1_1], 
[YP1_2, YC1_2, XML1_2] ...)), (SC2, ...) .... ] 
    LinkedHashMap<String, ArrayList<String[]>> showCommandsToPathYangXML = 
new LinkedHashMap<>();

    NetconfSSHClient client;
    YangParser parser;
    Collection <String> capabilities;
    //Curretnly, whichView's values correspond to the following transitions:
    //0: go to RetrieverView
    //1: go to ShowCommandView
    //2: go to TabView (one tab per show command), each tab of which contains subtabs for YANG paths
    int whichView;




    @Override
    protected void init(VaadinRequest vaadinRequest) {
        Page.getCurrent().setTitle("New NETCONF Tool");
        addStyleName(ValoTheme.UI_WITH_MENU);
        showNextView();
    }

    //oldShowValues is only really applicable when going from TabView back to ShowCommandView
    public void showNextView(String ... oldShowValues) {
        switch (whichView) {
            case 0:
                setContent(new RetrieverView(this));
                //addStyleName("loginview");
                break;
            case 1:
                //setSizeFull();
                getPage().setTitle("Netconf session with: " + hostName);
                setContent(new ShowCommandView(this));
                // Might be transferring from 2 to 1, not just from 0 to 1
                //removeStyleName(getStyleName());
                //addStyleName("showcommandview");
                break;
            case 2:
                setContent(new TabView(this));
                //removeStyleName("showcommandview");
                //addStyleName("tabview");
                break;
            default:
                System.out.println("To be further developed.");
                break;
        }
    }

    @WebServlet(urlPatterns = {"/hello"}, name = "MyUIServlet", 
asyncSupported = true)
    @VaadinServletConfiguration(ui = MainUI.class, productionMode = true)
    public static class MyUIServlet extends VaadinServlet {
    }

}

Edit: Apparently this was in the Glassfish server output (and only appeared once I attempted to access anywhere in localhost:8080 (such as /nchandler) - ie, it was not there when I ran the server in isolation):

Severe: SEC5054: Certificate has expired: [
[
  Version: V3
  Subject: CN=GTE CyberTrust Root 5, OU="GTE CyberTrust Solutions, Inc.", O=GTE Corporation, C=US
  Signature Algorithm: SHA1withRSA, OID = 1.2.840.113549.1.1.5
  Key:  Sun RSA public key, 2048 bits
  modulus: 23741889829347261660812437366387754385443431973861114865490414153884050331745811968523116847625570146592736935209718565296053386842135985534863157983128812774162998053673746470782252407673402238146869994438729551246768368782318393878374421033907597162218758024581735139682087126982809511479059100617027892880227587855877479432885604404402435662802390484099065871430585284534529627347717530352189612077130606642676951640071336717026459037542552927905851171460589361570392199748753414855675665635003335769915908187224347232807336022456537328962095005323382940080676931822787496212635993279098588863972868266229522169377
  public exponent: 65537
  Validity: [From: Fri Aug 14 07:50:00 PDT 1998,
               To: Wed Aug 14 16:59:00 PDT 2013]
  Issuer: CN=GTE CyberTrust Root 5, OU="GTE CyberTrust Solutions, Inc.", O=GTE Corporation, C=US
  SerialNumber: [    01b6]
Certificate Extensions: 4
[1]: ObjectId: 2.5.29.19 Criticality=true
BasicConstraints:[
  CA:true
  PathLen:5
]
[2]: ObjectId: 2.5.29.32 Criticality=false
CertificatePolicies [
  [CertificatePolicyId: [1.2.840.113763.1.2.1.3]
[]  ]
]
[3]: ObjectId: 2.5.29.15 Criticality=true
KeyUsage [
  Key_CertSign
  Crl_Sign
]
[4]: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: 76 0A 49 21 38 4C 9F DE   F8 C4 49 C7 71 71 91 9D  v.I!8L....I.qq..
]
]
]

Answer 1

OK, so apparently, the issue was with my system's environment variables; sometime in the past, I had done some messing around with my path variable, and I found out that I had forgot to add C:\\Windows\\System32 back to my system's path.

After the "BUILD SUCCESSFUL" message in the output, there was actually another message: "cmd is not recognized as an internal or external command". Searching up the solution online and fixing the environment variable now allows the server to be run when the I run the project.