[GLASSFISH-21515] Possible null pointer dereference Created: 12/Feb/16  Updated: 23/Jan/17  Resolved: 23/Jan/17

Status: Resolved
Project: glassfish
Component/s: verifier
Affects Version/s: 4.1.1
Fix Version/s: 5.0

Type: Bug Priority: Major
Reporter: AppChecker Assignee: pranjal.sahay
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 30 seconds
Time Spent: Not Specified
Original Estimate: 30 seconds


 Description   

Strangely that variable specMappingInfo was used before it was checked:

  if (specMappingInfo.length()!=0 && specMappingInfo!=null)

it seems it should be

  if (specMappingInfo!=null && specMappingInfo.length()!=0)

File: appserver/verifier/verifier-impl/src/main/java/com/sun/enterprise/tools/verifier/Result.java
Line: 119

This possible defect found by static analyzer AppChecker



 Comments   
Comment by pranjal.sahay [ 23/Jan/17 ]

Fixed by r64407





[GLASSFISH-21579] asadmin list-file-groups exits successfully although user doesn't exist Created: 02/Nov/16  Updated: 23/Jan/17  Resolved: 23/Jan/17

Status: Resolved
Project: glassfish
Component/s: security
Affects Version/s: 4.1, 4.1.1
Fix Version/s: 5.0

Type: Bug Priority: Major
Reporter: yama0428 Assignee: pranjal.sahay
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

asadmin list-file-groups exits successfully although user doesn't exist.

C:\glassfish-4.1.1\glassfish4\glassfish\bin>asadmin list-file-users
Command list-file-users executed successfully.

C:\glassfish-4.1.1\glassfish4\glassfish\bin>asadmin list-file-groups --name foo
list-file-groups Successful
Command list-file-groups executed successfully.

I think it is kind if list-file-groups command informs users of designated username doesn't exist.

This is my patch for this.

com.sun.enterprise.security.cli.ListFileGroup.java
    public void execute(AdminCommandContext context) {

        final ActionReport report = context.getActionReport();

        try {
            // Get all users of this file realm. If a username has
            // been passed in through the --name CLI option use that
            FileRealm fr = getFileRealm(securityService, fileAuthRealm, report);

            if (fr == null) {
                // the getFileRealm method would have filled
                // in the right cause of this situation
                return;
            }
            
            Enumeration groups = null;
            if (fileUserName != null) {
+               fr.getUser(fileUserName);
                groups = fr.getGroupNames(fileUserName);
            } else {
                groups = fr.getGroupNames();
            }

By this patch, asadmin list-file-groups fails like this.

>asadmin list-file-groups --name foo
remote failure: Specified file user foo not found  No such user [foo].
No such user [foo].
Command list-file-groups failed.


 Comments   
Comment by pranjal.sahay [ 23/Jan/17 ]

Fixed by r64408





[GLASSFISH-21584] A new property cannot be added in "Cluster System Properties" page. Created: 09/Nov/16  Updated: 23/Jan/17  Resolved: 23/Jan/17

Status: Resolved
Project: glassfish
Component/s: admin_gui
Affects Version/s: 4.1.1, 5.0
Fix Version/s: 5.0

Type: Bug Priority: Major
Reporter: tak09 Assignee: pranjal.sahay
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

A new property cannot be added in "Cluster System Properties" page.

Steps to reproduce:
1. Open Admin Console
2. Create a new cluster, e.g. cluster1
3. Click on "cluster1" (to go to "General Information" page) then click on the "Properties" tab (to get to the "Cluster System Properties" page).
4. Click on "Add Property" and enter "myprop" for the Instance Variable Name and "123" for the Override Value, then hit the "Save" button.

=> Page displays message "New values successfully saved." however the table now DOES NOT contain the newly added property.

If the domain.xml is checked, the newly added property has NOT been added to the file.
Below shows where it SHOULD HAVE been added to the file:

<domain>
<clusters>

<cluster ... name="cluster1" ... >

<system-property name="myprop" value="123"></system-property>

We further observe that adding a property with the same name as an existing one or adding a property with no name specified, does not result in any error when the "Save" button is hit (in addition to the fact that the newly added properties are discarded).

Cause:
System properties may be specified for "server" and for cluster instances, using a very similar page.
To see this page for server, click on "server" in the navigation tree, to go to its "General Information" page, then click on the "Properties" tab ("System Properties" page).
To see this page for cluster instances, create a cluster instance, click on the link for it, to go to its "General Information" page, then click on the "Properties" tab ("Instance System Properties" page).
These pages properly support adding new properties, and properly validate the properties (checks for duplicate properties and those with no name specified etc.)

The JSF files which specify the "Save" button actions for Cluster System Properties and Server/Instance System Properties are (respectively):

main\appserver\admingui\cluster\src\main\resources\cluster\clusterSystemPropertiesButtons.jsf

main\appserver\admingui\common\src\main\resources\configuration\systemPropertiesButtons.jsf

If we compare these files, it is apparent that the "clusterSystemPropertiesButtons.jsf" has the following problems:

  • the wrong table column name is being used for the property value (using "row.value" instead of "row.overrideValue")
  • the wrong parameter name for the property map is being used in the gf.restRequest() invocation ("data" instead of "attrs")

Fix:
The following change fixes this bug. "main\appserver\admingui\cluster\src\main\resources\cluster\clusterSystemPropertiesButtons.jsf"

Index: clusterSystemPropertiesButtons.jsf
===================================================================
--- clusterSystemPropertiesButtons.jsf	(revision 64342)
+++ clusterSystemPropertiesButtons.jsf	(working copy)
@@ -44,9 +44,9 @@
         gf.isClusterName(clusterName="#{pageSession.clusterName}" );
         createMap(result="#{requestScope.data}");
         foreach (var="row" list="#{pageSession.tableList}") {
-            mapPut(map="#{requestScope.data}", key="#{row.name}", value="#{row.value}");
+            mapPut(map="#{requestScope.data}", key="#{row.name}", value="#{row.overrideValue}");
         }
-        gf.restRequest(endpoint="#{pageSession.selfUrl}", method="POST", data="#{requestScope.data}", contentType="application/x-www-form-urlencoded", result="#{requestScope.restResponse}");
+        gf.restRequest(endpoint="#{pageSession.selfUrl}", method="POST", attrs="#{requestScope.data}", contentType="application/x-www-form-urlencoded", result="#{requestScope.restResponse}");
         prepareSuccessfulMsg();
         gf.redirect(page="#{pageSession.selfPage}&alertType=${alertType}&alertSummary=${alertSummary}&alertDetail=${alertDetail}");
         />


 Comments   
Comment by pranjal.sahay [ 23/Jan/17 ]

Fixed by r64409





[GLASSFISH-21464] Unable to create JMS Connection Factories/Destinations via web admin UI Created: 09/Nov/15  Updated: 19/Jan/17  Resolved: 19/Jan/17

Status: Closed
Project: glassfish
Component/s: admin_gui
Affects Version/s: 4.1.1
Fix Version/s: 4.1.1

Type: Bug Priority: Major
Reporter: rcuprak Assignee: sumasri
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

MacOS X



 Description   

Attempting to create new JMS Connection Factories or Destination Resources via the admin UI results in a RuntimeException and a blank screen.
Severe: java.lang.RuntimeException: java.lang.reflect.InvocationTargetException while attempting to process a 'beforeCreate' event for 'event145'.
at com.sun.jsftemplating.layout.descriptors.LayoutElementBase.dispatchHandlers(LayoutElementBase.java:422)
at com.sun.jsftemplating.layout.descriptors.LayoutElementBase.dispatchHandlers(LayoutElementBase.java:394)
at com.sun.jsftemplating.layout.descriptors.LayoutComponent.beforeCreate(LayoutComponent.java:348)
at com.sun.jsftemplating.layout.descriptors.LayoutComponent.getChild(LayoutComponent.java:288)
at com.sun.jsftemplating.layout.LayoutViewHandler.buildUIComponentTree(LayoutViewHandler.java:556)
at com.sun.jsftemplating.layout.LayoutViewHandler.buildUIComponentTree(LayoutViewHandler.java:551)
at com.sun.jsftemplating.layout.LayoutViewHandler.buildUIComponentTree(LayoutViewHandler.java:507)
at com.sun.jsftemplating.layout.LayoutViewHandler.buildUIComponentTree(LayoutViewHandler.java:507)
at com.sun.jsftemplating.layout.LayoutViewHandler.createView(LayoutViewHandler.java:255)
at com.sun.faces.lifecycle.RestoreViewPhase.execute(RestoreViewPhase.java:256)
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)
at com.sun.faces.lifecycle.RestoreViewPhase.doPhase(RestoreViewPhase.java:123)
at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:198)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:658)
at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1682)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:344)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
at com.sun.webui.jsf.util.UploadFilter.doFilter(UploadFilter.java:233)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:316)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:160)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:734)
at org.apache.catalina.core.StandardPipeline.doChainInvoke(StandardPipeline.java:678)
at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:97)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:174)
at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:416)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:283)
at com.sun.enterprise.v3.services.impl.ContainerMapper$HttpHandlerCallable.call(ContainerMapper.java:459)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:167)
at org.glassfish.grizzly.http.server.HttpHandler.runService(HttpHandler.java:206)
at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:180)
at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:235)
at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:283)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:200)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:132)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:111)
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:536)
at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:112)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:117)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:56)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:137)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:591)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:571)
at java.lang.Thread.run(Thread.java:745)
Caused by: java.lang.reflect.InvocationTargetException
at sun.reflect.GeneratedMethodAccessor161.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at com.sun.jsftemplating.layout.descriptors.handler.Handler.invoke(Handler.java:442)
at com.sun.jsftemplating.layout.descriptors.LayoutElementBase.dispatchHandlers(LayoutElementBase.java:420)
... 46 more
Caused by: java.lang.NullPointerException
at com.sun.jsftemplating.handlers.UtilHandlers.mapPut(UtilHandlers.java:314)
... 51 more



 Comments   
Comment by payara_steve [ 14/Nov/15 ]

I suspect this is a duplicate of https://java.net/jira/browse/GLASSFISH-21314

Comment by wallacepontes [ 02/Dec/15 ]

The command line equivalent of my ant target would be
asadmin create-jms-resource --restype javax.jms.Topic --property
Name=PhysicalTopic jms/Topic
This command is supposed to create a destination resource that shows up in an
Edit JMS Destination Resource window with the JNDI name jms/Topic, the physical
destination name PhysicalTopic, and the resource type javax.jms.Topic.
...
To create a connection factory resource you use a command like
asadmin create-jms-resource --restype javax.jms.ConnectionFactory
jms/ConnectionFactory
...
See more at: https://java.net/jira/si/jira.issueviews:issue-html/GLASSFISH-8874/GLASSFISH-8874.html

Comment by sumasri [ 19/Jan/17 ]

This is duplicate of GLASSFISH-21472.





[GLASSFISH-21573] Server log messages are unexpectedly trimmed if the message starts with or ends with spaces. Created: 31/Oct/16  Updated: 19/Jan/17  Resolved: 19/Jan/17

Status: Closed
Project: glassfish
Component/s: logging
Affects Version/s: 4.1, 4.1.1, 5.0
Fix Version/s: None

Type: Bug Priority: Major
Reporter: yama0428 Assignee: Kokil_Jain
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Server log messages are unexpectedly trimmed if the message starts with or ends with spaces.

ex)

System.out.println("               Hello, World!               ");

server.log

[2016-10-31T12:53:28.009+0900] [glassfish 4.1] [INFO] [] [] [tid: _ThreadID=36 _ThreadName=Thread-8] [timeMillis: 1477886008009] [levelValue: 800] [[
  Hello, World!]]

This is the patch for this problem.

LoggingOutputStream.java flush()
-        logMessage = logMessage.trim();
-        if (logMessage.length() == 0 || logMessage.equals(lineSeparator)) {
+        if (logMessage.trim().length() == 0 || logMessage.trim().equals(lineSeparator)) {
            // avoid empty records
            return;
        }


 Comments   
Comment by Kokil_Jain [ 19/Jan/17 ]

Fixed by r64406





[GLASSFISH-21585] The list of JVM options is lost empty when an invalid option is added. Created: 10/Nov/16  Updated: 19/Jan/17  Resolved: 19/Jan/17

Status: Closed
Project: glassfish
Component/s: admin, rest-interface
Affects Version/s: 4.1.1, 5.0
Fix Version/s: None

Type: Bug Priority: Major
Reporter: tak09 Assignee: Kokil_Jain
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

When an invalid JVM option is added in "JVM Options" page, all JVM Options are removed.
The impact of this bug is high as it is impossible to restore all the settings.

Follow the steps below to reproduce this bug.

Steps to reproduce:
1. Open "Configurations>server-config>JVM Settings" from the Navigation tree.
2. Open "JVM Options" tab.
3. Add a new JVM option which does not start with -(dash). For example abc=def.
4. Click "Save" button. Then, error message is displayed at the top of page.
5. Go to another page and re-open this "JVM Options" page to reload the data.
6. All JVM options are deleted.

Cause:
I found the problem is in CollectionLeafResource.java. In "create" method of CollectionLeafResource.java, the JVM options are updated with the following procedure.
1. Check if the JVM options have been changed.
2. If yes, delete all the JVM options.
3. Create all the JVM options including added/changed option.
If step 3 is failed with error for some reasons, then all JVM options are deleted as a result. There is no recovery of the JVM options after 3 is executed.

Suggested Fix:
Add Step 4 to the above and recover the existing JVM options. The new procedure is as follows:
1. Check if the JVM options have been changed.
2. If yes, backup all the JVM options. Then, delete all the JVM options.
3. Create all the JVM options.
4. If step 3 is failed with error, restore all the JVM options.

The following is the patch for Glassfish 4.1.1

nucleus/admin/rest/rest-service/src/main/java/org/glassfish/admin/rest/resources/CollectionLeafResource.java


Index: CollectionLeafResource.java
===================================================================
--- CollectionLeafResource.java	(revision 64342)
+++ CollectionLeafResource.java	(working copy)
@@ -140,9 +140,12 @@
 
         String postCommand = getPostCommand();
         Map<String, String> payload = null;
+        Map<String, String> existing = null;
 
         if (isJvmOptions(postCommand)) {
             deleteExistingOptions();
+            // All JVM options are deleted. Store existing JVM options in existing. 
+            existing = deleteExistingOptions();
             payload = processData(data);
         } else {
             payload = data;
@@ -149,8 +152,16 @@
         }
 
 
-        return runCommand(postCommand, payload, "rest.resource.create.message",
+        // Create all JVM options.
+        Response response = runCommand(postCommand, payload, "rest.resource.create.message",
             "\"{0}\" created successfully.", "rest.resource.post.forbidden","POST on \"{0}\" is forbidden.");
+        if (response.getStatus() != 200) {
+            // If creating JVM options is error, restore JVM options with exsiting.  
+            payload = processData(existing);
+            runCommand(postCommand, payload, "rest.resource.create.message",
+                "\"{0}\" created successfully.", "rest.resource.post.forbidden","POST on \"{0}\" is forbidden.");
+        }
+        return response;
     }
 
     @PUT //create
@@ -362,7 +373,7 @@
         return (command != null) && (command.contains("jvm-options"));
     }
 
-    protected void deleteExistingOptions() {
+    protected Map<String, String> deleteExistingOptions() {
         Map<String, String> existing = new HashMap<String, String>();
         existing.put("target", target);
         for (String option : getEntity()) {
@@ -379,6 +390,7 @@
                 "\"{0}\" deleted successfully.",
                 "rest.resource.delete.forbidden",
                 "DELETE on \"{0}\" is forbidden.");
+        return existing;
     }
 
 }
 


 Comments   
Comment by Kokil_Jain [ 19/Jan/17 ]

Fixed by r64414





[GLASSFISH-21656] list-jms-resources fails if operand is clustered instance Created: 05/Jan/17  Updated: 19/Jan/17  Resolved: 18/Jan/17

Status: Closed
Project: glassfish
Component/s: jms
Affects Version/s: 3.1.2.2, 4.1, 4.1.1, 5.0
Fix Version/s: None

Type: Bug Priority: Major
Reporter: yama0428 Assignee: mskdeepak
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

asadmin list-jms-resources fails if operand is clustered instance.
On the other hand, other list commands can be executed even if operand is clustered instance.

C:\glassfish-4.1.1\glassfish4\glassfish\bin>asadmin list-jms-resources instance
remote failure: The list-jms-resources command is not allowed on target instance because it is part of cluster cluster
Command list-jms-resources failed.

C:\glassfish-4.1.1\glassfish4\glassfish\bin>asadmin list-jdbc-resources instance
jdbc/__default
Command list-jdbc-resources executed successfully.

C:\glassfish-4.1.1\glassfish4\glassfish\bin>asadmin list-connector-resources instance
jms/__defaultConnectionFactory
Command list-connector-resources executed successfully.

This is the patch for this problem.

ListJMSresources.java
@PerLookup
@CommandLock(CommandLock.LockType.NONE)
@I18n("list.jms.resources")
@ExecuteOn({RuntimeType.DAS})
@TargetType({CommandTarget.DAS,CommandTarget.STANDALONE_INSTANCE,CommandTarget.CLUSTER,CommandTarget.DOMAIN,CommandTarget.CLUSTERED_INSTANCE})
@RestEndpoints({
    @RestEndpoint(configBean=Resources.class,
        opType=RestEndpoint.OpType.GET, 
        path="list-jms-resources", 
        description="list-jms-resources")
})
public class ListJMSResources implements AdminCommand {


 Comments   
Comment by mskdeepak [ 19/Jan/17 ]

Fixed in r64405





[GLASSFISH-21539] JAX-WS HandlerChain issue Created: 23/Apr/16  Updated: 18/Jan/17  Resolved: 18/Jan/17

Status: Resolved
Project: glassfish
Component/s: deployment
Affects Version/s: 4.1
Fix Version/s: None

Type: Bug Priority: Major
Reporter: farag_cs2005 Assignee: Vinay Vishal
Resolution: Cannot Reproduce Votes: 0
Labels: waiting_on_filer
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

CentOS 6.5 + NetBeans 8.1


Attachments: File glassfish-21539.war    

 Description   

I got the below exception when deploying web service endpoint with handlers

  • Exception log
    Severe: Component referenced from annotation symbol cannot be found
    symbol: javax.jws.HandlerChain
    location: class master.wsservices.CargoGeneralServices
    Severe: Annotations processing failed for file:/home/cargo-tracker/target/cargo-tracker/
  • JAX-WS
    @WebService
    @HandlerChain(file = "handler-chain.xml")
    public class WSGeneralService {
    /**
  • Web service operation
    */
    @WebMethod(operationName = "hello")
    public CargoDTO hello(@WebParam(name = "name") String name) { return "Hello, " + name; }

    }

  • Handler chain file
    <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
    <javaee:handler-chains
    xmlns:javaee="http://java.sun.com/xml/ns/javaee"
    xmlns:xsd="http://www.w3.org/2001/XMLSchema">
    <javaee:handler-chain>
    <javaee:handler>
    <javaee:handler-class>JWSSOAPInterceptor</javaee:handler-class>
    </javaee:handler>
    </javaee:handler-chain>
    </javaee:handler-chains>
  • Handler class

public class JWSSOAPInterceptor implements SOAPHandler<SOAPMessageContext>{

@Override
public Set<QName> getHeaders()

{ return null; }

@Override
public boolean handleMessage(SOAPMessageContext context) {
Boolean outboundProperty = (Boolean)
context.get (MessageContext.MESSAGE_OUTBOUND_PROPERTY);

if (outboundProperty.booleanValue())

{ System.out.println("\nOutbound message:"); }

else

{ System.out.println("\nInbound message:"); }

System.out.println("======== Response: "+context.getMessage().toString());

return true;
}

@Override
public boolean handleFault(SOAPMessageContext context)

{ return true; }

@Override
public void close(MessageContext context) {

}

}



 Comments   
Comment by lprimak [ 28/May/16 ]

This is now fixed in Payara

Comment by lprimak [ 28/Dec/16 ]

Fixed by https://github.com/payara/Payara/pull/812

Comment by Vinay Vishal [ 29/Dec/16 ]

The issue couldn't be reproduced with specified version. Sample application attached. Is there any specific scenario in which this exception is encountered? If available, please share the sample application in order to reproduce this issue.





[GLASSFISH-21626] The Number of Connections is incorrect (negative value) when leak timeout occurs in JDBC monitoring Created: 22/Nov/16  Updated: 18/Jan/17  Resolved: 18/Jan/17

Status: Closed
Project: glassfish
Component/s: monitoring
Affects Version/s: 5.0
Fix Version/s: 5.0

Type: Bug Priority: Major
Reporter: tak09 Assignee: srinik76
Resolution: Cannot Reproduce Votes: 0
Labels: waiting_on_filer
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Glassfish 5.0-b01



 Description   

Issue:

The Number of Connections is incorrect in JDBC monitoring when "Statement Leak Reclaim" is enabled and timeout occurs.

Check the following metrics in the monitoring:

  • numconnfree (The number becomes "Expected + 1". However, this should not occur. When the connection leak timeout occurs, the connection is discarded. It is not returned to the pool.)
  • numconnreleased (The number becomes "Expected + 1". However, this should not occur. When the connection leak timeout occurs, the connection is discarded. It is not returned to the pool.)
  • numconnused (The number becomes "Expected - 1". However, this should not occur. This value becomes negative but it shouldn't become negative.)

This bug is reproduced in the following condition:
1. Enable "Statement Leak Reclaim"
2. Get a JDBC Connection from an application
3. "Leak Timeout" occurs in the Connection of 2.
4. The applicaiton calls close() to close the Connection of 2.

Steps to Reproduce Issue:
1. Create a table on JavaDB
Create a table as the example use JavaDB.
a. Start JavaDB
asadmin start-database
b. Create a table
.\glassfish4\javadb\bin\ij
ij> connect 'jdbc:derby://localhost:1527/sun-appserv-samples;create=true';
ij> create table mytable(mycol1 varchar(20), mycol2 varchar(20));
ij> insert into mytable values('data1', 'data1');
ij> insert into mytable values('data2', 'data2');
ij> commit;
ij> select * from mytable;
ij> exit;

2. Ensure JDBC Resource and JDBC Connection exist.
The test program uses "DerbyPool" and "jdbc/__default" which are already created by the default installation of Glassfish.

3. Enable "Statement Leak Reclaim" and change "Statement Leak Timeout"
In the GUI, navigate to "Resources>JDBC>JDBC Connection Pool>DerbyPool".
In "Advanced" tab, enable "Statement Leak Reclaim" and change "Statement Leak Timeout" to "5" Seconds.

4. Turn on Monitoring for JDBC
Set HIGH for JDBC monitoring
asadmin set server.monitoring-service.module-monitoring-levels.jdbc-connection-pool=HIGH

5. Deploy Web application

6. Open Web application.
http://localhost:8080/WebApplication2/Hello (It takes about 10 sec, as there is sleep 10sec in the Web application. When the application is completed, the contents of "select * from mytable" is displayed.)

7. Check the statistics using REST interface while waiting 10 sec.
http://localhost:4848/monitoring/domain1/server/resources/DerbyPool
Check the following metrics:

  • numconnfree
  • numconnreleased
  • numconnused

8. Check the above statistics using REST again after loading the Web application is finished. (After 10 sec sleep)

Check the followings:

  • numconnfree (The number becomes "Expected + 1")
  • numconnreleased (The number becomes "Expected + 1")
  • numconnused (The number becomes "Expected - 1")


 Comments   
Comment by tak09 [ 22/Nov/16 ]

The test web application can be downloaded here.
https://www.dropbox.com/s/94rqd7ntds5filg/WebApplication2.war?dl=0

Comment by srinik76 [ 17/Jan/17 ]

Tested the above steps with latest revision 64402. After accessing the application checked the following

http://localhost:4848/monitoring/domain1/server/resources/DerbyPool

The number of connections used does not become negative. It remains zero with high watermark as 1. Not reproducible with latest build

Comment by srinik76 [ 17/Jan/17 ]

Cannot reproduce with latest build

Comment by srinik76 [ 18/Jan/17 ]

Reopening to add a label : waiting_on_filer





[GLASSFISH-21636] proxy-auth-cert web devtest fails in Hudsons Created: 09/Dec/16  Updated: 18/Jan/17  Resolved: 18/Jan/17

Status: Resolved
Project: glassfish
Component/s: web_container
Affects Version/s: 5.0
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Shing Wai Chan Assignee: xin.li
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

The test fails in continuous and nightly Hudsons.

Continuous build:
http://gf-hudson.us.oracle.com/hudson/view/GlassFish/view/Trunk%20Continuous/job/gf-trunk-web-devtests-continuous/lastSuccessfulBuild/artifact/appserv-tests/test_results.html

Nightly build:
http://gf-hudson.us.oracle.com/hudson/view/GlassFish/view/Trunk%20Continuous/job/gf-lw-web-devtests/406/artifact/appserv-tests/test_results.html

deploy-war-commonpe:
[exec] asadmin --host localhost.localdomain --port 45707 --user admin --passwordfile /scratch/BUILD_AREA/workspace/gf-lw-web-devtests/appserv-tests/config/adminpassword.txt --interactive=false --echo=true --terse=true deploy --contextroot /web-proxy-auth-cert --force=false --precompilejsp=true --verify=false --generatermistubs=false --availabilityenabled=false --asyncreplication=true --target server --keepreposdir=false --keepfailedstubs=false --isredeploy=false --logreportederrors=true --_classicstyle=false --upload=true /scratch/BUILD_AREA/workspace/gf-lw-web-devtests/appserv-tests/build/module/archive/web-proxy-auth-cert-web.war
[exec] Application deployed with name web-proxy-auth-cert-web.

deploy-war-commonee:

run:
[java] proxy-auth-cert test failed
[java] java.lang.Exception: Wrong response. Expected: true, received:
[java] at WebTest.invoke(Unknown Source)
[java] at WebTest.doTest(Unknown Source)
[java] at WebTest.main(Unknown Source)
[java] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[java] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
[java] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[java] at java.lang.reflect.Method.invoke(Method.java:498)
[java] at org.apache.tools.ant.taskdefs.ExecuteJava.run(ExecuteJava.java:217)
[java] at org.apache.tools.ant.taskdefs.ExecuteJava.execute(ExecuteJava.java:152)
[java] at org.apache.tools.ant.taskdefs.Java.run(Java.java:771)
[java] at org.apache.tools.ant.taskdefs.Java.executeJava(Java.java:221)
[java] at org.apache.tools.ant.taskdefs.Java.executeJava(Java.java:135)
[java] at org.apache.tools.ant.taskdefs.Java.execute(Java.java:108)
[java] at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291)
[java] at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
[java] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[java] at java.lang.reflect.Method.invoke(Method.java:498)
[java] at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
[java] at org.apache.tools.ant.Task.perform(Task.java:348)
[java] at org.apache.tools.ant.Target.execute(Target.java:390)
[java] at org.apache.tools.ant.Target.performTasks(Target.java:411)
[java] at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1399)
[java] at org.apache.tools.ant.helper.SingleCheckExecutor.executeTargets(SingleCheckExecutor.java:38)
[java] at org.apache.tools.ant.Project.executeTargets(Project.java:1251)
[java] at org.apache.tools.ant.taskdefs.Ant.execute(Ant.java:442)
[java] at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291)
[java] at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
[java] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[java] at java.lang.reflect.Method.invoke(Method.java:498)
[java] at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
[java] at org.apache.tools.ant.Task.perform(Task.java:348)
[java] at org.apache.tools.ant.Target.execute(Target.java:390)
[java] at org.apache.tools.ant.Target.performTasks(Target.java:411)
[java] at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1399)
[java] at org.apache.tools.ant.Project.executeTarget(Project.java:1368)
[java] at org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:41)
[java] at org.apache.tools.ant.Project.executeTargets(Project.java:1251)
[java] at org.apache.tools.ant.Main.runBuild(Main.java:809)
[java] at org.apache.tools.ant.Main.startAnt(Main.java:217)
[java] at org.apache.tools.ant.launch.Launcher.run(Launcher.java:280)
[java] at org.apache.tools.ant.launch.Launcher.main(Launcher.java:109)
[java] Generating report at /scratch/BUILD_AREA/workspace/gf-lw-web-devtests/appserv-tests/test_results.xml
[java]
[java]
[java] -----------------------------------------
[java] - proxy-auth-cert: FAIL -
[java] -----------------------------------------
[java] - Total PASS : 0 -
[java] - Total FAIL : 1 -
[java] - Total DID NOT RUN : 0 -
[java] -----------------------------------------



 Comments   
Comment by Shing Wai Chan [ 21/Dec/16 ]

I also see the failure in my local workspace.

Comment by Shing Wai Chan [ 10/Jan/17 ]

I see the following in sever.log:
Error parsing client cert chain into array of java.security.cert.X509Certificate instances
java.security.cert.CertificateException: Could not parse certificate: java.io.IOException: java.lang.IllegalArgumentException: Last unit does not have enough valid bits
at sun.security.provider.X509Factory.engineGenerateCertificate(X509Factory.java:110)
at java.security.cert.CertificateFactory.generateCertificate(CertificateFactory.java:339)
at com.sun.enterprise.web.ProxyHandlerImpl.getSSLClientCertificateChain(ProxyHandlerImpl.java:89)
at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:326)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:238)
at com.sun.enterprise.v3.services.impl.ContainerMapper$HttpHandlerCallable.call(ContainerMapper.java:459)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:167)
at org.glassfish.grizzly.http.server.HttpHandler.runService(HttpHandler.java:206)
at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:180)
at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:235)
at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:283)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:200)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:132)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:111)
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:536)
at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:112)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:117)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:56)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:137)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:591)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:571)
at java.lang.Thread.run(Thread.java:745)
Caused by: java.io.IOException: java.lang.IllegalArgumentException: Last unit does not have enough valid bits
at sun.security.util.Pem.decode(Pem.java:49)
at sun.security.provider.X509Factory.readOneBlock(X509Factory.java:638)
at sun.security.provider.X509Factory.engineGenerateCertificate(X509Factory.java:96)
... 23 more
Caused by: java.lang.IllegalArgumentException: Last unit does not have enough valid bits
at java.util.Base64$Decoder.decode0(Base64.java:734)
at java.util.Base64$Decoder.decode(Base64.java:526)
at sun.security.util.Pem.decode(Pem.java:47)
... 25 more

Comment by xin.li [ 10/Jan/17 ]

We created standalone test to parse CLIENT_CERT. Then we found it can pass in JDK7 but fail in JDK8.
There is a difference between JDK7 and JDK8.
In JDK7, X509Factory use BASE64Decoder and BASE64Encoder under sun.misc to encode and decode string.
In JDK8, it use java.util.Base64 to do it.
It seems like java.util.Base64 check more strictly than BASE64Decoder/BASE64Encoder.
I will look into JDK source to find root cause

Comment by xin.li [ 18/Jan/17 ]

Committed revision 64399





[GLASSFISH-5373] LDAP locked account caching issue Created: 24/Jul/08  Updated: 17/Jan/17  Resolved: 13/Apr/11

Status: Resolved
Project: glassfish
Component/s: security
Affects Version/s: 9.1peur1
Fix Version/s: 3.1

Type: Bug Priority: Minor
Reporter: pmccabe Assignee: kumarjayanti
Resolution: Fixed Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 5,373

 Description   

We have a web application set up to authenticate via the container to an LDAP
realm. Our ldap server is set to lock to account after 3 failed attempts. This
process is working correctly.

However, upon entering the correct password after locking the account, a user is
permitted access to the application.

Now, I restart the app server, and I try again with the correct password, I get
the expected behavior of being denied access.

So it seems that something is being cached when it shouldn't be.



 Comments   
Comment by kumarjayanti [ 19/Sep/08 ]

Is this still an issue, can you tell us if this is happening always, with any
LDAP Server ?. Can i reproduce this if i use OpenDS.

Thanks

Comment by pmccabe [ 19/Sep/08 ]

Yes this is still an issue for us. I have typed up a more detailed explanation
for our team which I will copy here for you. I have not tried this with
different LDAP servers.

Description of bug.

When using form login, if a user account is locked on the directory server
because of too many failed attempts, the
user is still allowed access to a protected resource when they enter the correct
password.
Performing these same steps with using basic login will not continue to
request the password.

App Server Version: Sun Java System Application Server 9.1 Update2
Directory server: Sun Java System Directory Server 5.2 Patch 4 B2005.230.0041

Steps to reproduce:
Configure the directory server to lock an account after a specified number of
failed login attempts.

In the application server:
Create a new LDAP security realm.
Set the Assign Group attribute to: TestGroup
Set this realm as the default security realm

Create a new war project in Netbeans( or whatever you want)
Create an index.jsp page, this will be the protected resource
Create A Login.jsp page with a form like :

<form action="j_security_check" method="post">
username: <input name="j_username"><br />
pass: <input name="j_password"><br />
<input type="submit">
</form>

Configure security in web.xml like follows
<security-constraint>
<display-name>Everybody</display-name>
<web-resource-collection>
<web-resource-name>JSP</web-resource-name>
<description>JSP files</description>
<url-pattern>*.jsp</url-pattern>
<http-method>GET</http-method>
<http-method>PUT</http-method>
</web-resource-collection>
<auth-constraint>
<description/>
<role-name>TestRole</role-name>
</auth-constraint>
</security-constraint>

<login-config>
<auth-method>FORM</auth-method>
<form-login-config>
<form-login-page>/Login.jsp</form-login-page>
<form-error-page>/Login.jsp?failed=true</form-error-page>
</form-login-config>
</login-config>

<security-role>
<description/>
<role-name>TestRole</role-name>
</security-role>

Configure the role mapping in sun-web.xml like follows

<security-role-mapping>
<role-name>TestRole</role-name>
<group-name>TestGroup</group-name>
</security-role-mapping>

Next try to log in with an incorrect password untill the account is locked. You
can verify that it is locked by inspecting the accountunlocktime property.
Now try to log in with the correct password.

The app server will still let you access the protected resource.

Repeat all of the above steps with basic login, and you will not be allowed access.

Comment by kumarjayanti [ 19/Sep/08 ]

When the user account is locked does the LDAPServer allow a login when connected
directly (from outside GlassFish ?).

Thanks.

Comment by pmccabe [ 19/Sep/08 ]

I don't know at this time. I currently don't have direct access to the
directory server. Give me some time, and i will see if I can get something set
up with our tech department.

Comment by pmccabe [ 19/Sep/08 ]

based on the fact that it does not allow login when using basic authentication
in the web application would lead me to believe that i would not be able to
login to the directory server directly

Comment by pmccabe [ 15/Oct/08 ]

I now have some time to dig into this issue more.

First of all, I am trying to check out the glassfish source code so that I can
dig into it a little myself, however, I keep getting a timeout when trying to
log in with netbeans or the command line.

Do I need to do anything special to get access to this repository É

Second...
What I have done now is after locking my account, I used the command line and
did an ldapbind with the correct username and password.

Here is the result
ldapbind -h <host> -p <port> -D "<userid>" -w <correct-password>
ldap_bind: Constraint violation
ldap_bind: additional info: Exceed password retry limit. Contact system administ
rator to reset.

After doing this, I can still log into my application.

Now, i wait 5-10 minutes, and I can NOT log in anymore.

Comment by kumarjayanti [ 15/Oct/08 ]

Hi ,
> I keep getting a timeout when trying to log in with netbeans or the command line.

Are you behind a Firewall ?. Disable your windows client firewall if any. Check
your proxy settings. Generally use system proxy works in my case.

Thanks for investigating more on this.

Comment by pmccabe [ 15/Oct/08 ]

I have just tried this with a fresh install of OpenDS, and I am getting the same
results when using form based login.

I have confirmed the account being locked by the following on the command line

C:\OpenDS\bat>ldapbind -h localhost -p 389 -D "uid=user.1,ou=people,dc=example,
c=com" -w password
ldap_bind: Invalid credentials

However, I can still log into my application using "password"
=========================================================
Again, using basic authentication, it works slightly differently than my
previous tests with Sun Directory Server.

Instead of continuing to prompt for a password, using OpenDS causes the HTTP 401
error page to be displayed after locking an account, which is not an issue.

I believe this difference with basic authentication is based on the different
response from OpenDS and Sun Directory server when the password is locked
OpenDS simply says INvalid Credentials, whereas Sun DS throws a constraing
violation.
========================================================================

So is this enough information for you to be able to confirm this as a bug and
have somebody look into it more thouroughly ?

It seems to me that this is quite a security risk.
=========================================================

Also, FYI, I am still trying to download the source code through CVS, my company
is using a proxy which I can only seem to configure on the browser level, so I
will try from home tonight.

Comment by pmccabe [ 15/Oct/08 ]

I have managed to get a hold of the glassfish source code.

Would you have any idea of which module I should be looking at for this ?

Comment by pmccabe [ 17/Oct/08 ]

I am now able to reproduce this bug using Basic authentication as well as Form
based authentication using Both Sun Directory Server 5.1 and OpenDS 1.0.

I am also able to log in from ANOTHER COMPUTER when an account is locked

The key to reproducing this bug is that you must log in successfully first, then
lock your account and log in again.

I looked into the code, and found this in
com.sun.enterprise.security.auth.realm.ldap.LdapRealm

private boolean bindAsUser(String bindDN, String password)
{
boolean bindSuccessful=false;

Properties p = getLdapBindProps();
p.put(Context.SECURITY_PRINCIPAL, bindDN);
p.put(Context.SECURITY_CREDENTIALS, password);
DirContext ctx = null;
try {
ctx = new InitialDirContext(p);
bindSuccessful = true;

......

This code looks to be sound. However, when an account is locked on OpenDs for
example, attempting a bind operation from the command line returns an Invalid
Credentials Error.

However, this code runs, and is able to succesfully bind the username and
password which can be verified by looking at the logs if you set everything to
Fine on the app server.

So I tried to reproduce this with my own code. I inspected the environment
paramaters used to create the initial context, and created a program myself
which created an initial context with the same environment paramaters as follows.

{java.naming.factory.initial=com.sun.jndi.ldap.LdapCtxFactory, java.naming.provider.url=ldap://localhost:389, java.naming.security.principal=uid=user.1,ou=People,dc=example,dc=com, com.sun.jndi.ldap.connect.pool=true, java.naming.factory.state=com.sun.jndi.ldap.obj.LdapGroupFactory, java.naming.security.credentials=password, java.naming.factory.object=com.sun.jndi.ldap.obj.LdapGroupFactory}

I tried this from a stand alone application, as well as from within a servlet,

Every time it throws the correct exception that the bind operation faild, all
the while the code in Glassfish is able to successfully bind the user.

So my question is this, how is this even possible? I am not able to find
anything anywhere about an initial context being cached somehow.

But is seems that this is the case based on the fact that I can ONLY reproduce
this error AFTER successfully logging in.

Can somebody who has more knowledge of this comment on the issue?

Pat

Comment by kumarjayanti [ 23/Oct/08 ]

Will check with some of our folks and get back.

Comment by kumarjayanti [ 23/Oct/08 ]

Thanks for your investigations, but i am curious :

"I tried this from a stand alone application, as well as from within a servlet,"

Where was the servlet running. If it was on GlassFish then you should have again
run into the same issue (because GlassFish would set some javax.naming.*
properties which would affect the way the initalDirContext is created), but you
seem to indicate that even for a servlet this was not an issue.

Comment by pmccabe [ 23/Oct/08 ]

The servlet was running within the same deployed war as everything else.
Doesn't really make sense to me either.

Comment by sanandal [ 11/Jan/09 ]

"Reclassifying as P4 because this issue is not deemed "must fix" for this v2.1
release whose primary release driver is SailFin.
This issue will be scrubbed after this release and will be given the right
priority for the next release."

Comment by kumarjayanti [ 13/Apr/11 ]

Please test with V3.1

Comment by marcozanghi [ 17/Jan/17 ]

what is the fix? I have the same issue with glassfish 4.0





[GLASSFISH-21529] after running asadmin enable-secure-admin , encounter problem stop/start glassfish Created: 23/Mar/16  Updated: 16/Jan/17  Resolved: 16/Jan/17

Status: Closed
Project: glassfish
Component/s: grizzly-kernel
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: wfsaxton Assignee: Ryan Lubke
Resolution: Cannot Reproduce Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

running Glassfish-4.0-b59 on window XP platform with jdk1.7.0_07


Issue Links:
Cloners
clones GLASSFISH-19207 after running asadmin enable-secure-a... Closed

 Description   

This started on glassfish-4.0-b59 and b58, did not have this issue on glassfish-4.0-b57.

after running asadmin enable-secure-admin, and re-cycling glassfish
you cannot stop/start glassfish anymore.

error from the command line is this:
Z:\glassfish3\glassfish\bin>asadmin stop-domain
NCLS-ADMIN-0010
CLI306: Warning - The server located at Z:\glassfish3\glassfish\domains\domain
is not running.
Command stop-domain executed successfully.

When the process is checked glassfish is running.
Also, this was confirmed multiple times on b58 and 59 with same results.

The server.log is attached.



 Comments   
Comment by wfsaxton [ 23/Mar/16 ]

I wasn't able to re-open this previous issue, but I'm encountering this same exact issue on the latest version of glassfish (4.1.1) on Linux

host:/glassfish/glassfish4/bin$ ./asadmin start-domain
Waiting for domain1 to start .......
Successfully started the domain : domain1
domain Location:/glassfish/glassfish4/glassfish/domains/domain1
Log File: /glassfish/glassfish4/glassfish/domains/domain1/logs/server.log
Admin Port: 4848
Command start-domain executed successfully.
host:/glassfish/glassfish4/bin$ ./asadmin change-admin-password
Enter admin user name [default: admin]>
Enter the admin password>
Enter the new admin password> (adminadmin)
Enter the new admin password again> (adminadmin)
Command change-admin-password executed successfully.
host:/glassfish/glassfish4/bin$ ./asadmin stop-domain
Waiting for the domain to stop .
Command stop-domain executed successfully.
host:/glassfish/glassfish4/bin$ ./asadmin start-domain
Waiting for domain1 to start ....
Successfully started the domain : domain1
domain Location: /glassfish/glassfish4/glassfish/domains/domain1
Log File: /glassfish/glassfish4/glassfish/domains/domain1/logs/server.log
Admin Port: 4848
Command start-domain executed successfully.
host:/glassfish/glassfish4/bin$ ./asadmin enable-secure-admin
You must restart all running servers for the change in secure admin to take effect.
Command enable-secure-admin executed successfully.
host:/glassfish/glassfish4/bin$ ./asadmin stop-domain
Waiting for the domain to stop .
Command stop-domain executed successfully.
host:/glassfish/glassfish4/bin$ ./asadmin start-domain
Waiting for domain1 to start ....
Successfully started the domain : domain1
domain Location: /glassfish/glassfish4/glassfish/domains/domain1
Log File:/glassfish/glassfish4/glassfish/domains/domain1/logs/server.log
Admin Port: 4848
Command start-domain executed successfully.
host:/glassfish/glassfish4/bin$ ./asadmin stop-domain
CLI306: Warning - The server located at /glassfish/glassfish4/glassfish/domains/domain1 is not running.
Command stop-domain executed successfully.

Comment by OlegShtch [ 13/Dec/16 ]

I get same error with glassfish 4.1.1 and java 1.8.112.

Comment by wfsaxton [ 13/Dec/16 ]

I figured out the issue. My JAVA_HOME was not set properly.

Oleg, try that and see if it fixes your issue. If so, we can close this out.

Comment by Yamini K B [ 16/Jan/17 ]

enable-secure-admin is working as expected on 4.1.1 as well as trunk build. Please re-open if the problem is still seen.





Generated at Mon Jan 23 08:55:37 UTC 2017 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.