[GLASSFISH-13663] Resource Adapter Config: change delete to load defaults Created: 28/Sep/10  Updated: 17/Oct/12

Status: Open
Project: glassfish
Component/s: admin_gui
Affects Version/s: 3.1
Fix Version/s: future release

Type: Improvement Priority: Major
Reporter: lidiam Assignee: sumasri
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 13,663
Status Whiteboard:

3_1-exclude

Tags: ee7ri_cleanup_deferred

 Description   

build: glassfish-3.1-b22-09_27_2010.zip

It would be nice to have "Load defaults" for a Resource Adapter Config. It
seems that currently to achieve this, user needs to delete a specific config and
then create "a new one" again, specifying the same adapter - it will have all
the defaults in case of the built in jmsra. Thus it would make sense to change
"Delete" button to "Load defaults" button on the edit page. It seems that the
resource config should only be truly deleted, if the adapter is being removed.



 Comments   
Comment by Anissa Lam [ 28/Sep/10 ]

Thanks for the suggestion.

The resource adapter config screen is based on input from the backend team. I
would like Jagadish to comment on this, give suggestion on what should be done.
We may or may not get to this for 3.1

Comment by lidiam [ 28/Sep/10 ]

Please see issue https://glassfish.dev.java.net/issues/show_bug.cgi?id=13659 as
well, as it also needs input from backend team, I think.

Comment by Jagadish [ 28/Sep/10 ]

Yes, this can be an enhancement.
Instead of removing "delete", we can keep it as such and introduce "load
defaults" in the edit page of the resource-adapter-config.

Comment by sumasri [ 07/Oct/10 ]

Added the target milestone.

Comment by sumasri [ 12/Dec/10 ]

As this is an enhancement, transferring it to MS8.

Comment by Anissa Lam [ 12/Dec/10 ]

Only critical bug fix will be allowed for MS8. You have till MS7 code freeze to fix this. If you won't get to that, then mark this for 3.2.

Comment by sumasri [ 13/Dec/10 ]

If we insert load defaults button in resource adapter config edit page, it can happen in any of the below cases.
case 1: If we click on the button, It erases all the existing properties and add jmsra(default) properties. If it happens this way, all existing props will be lost.
case 2: If we click on the button, If one of the default property is removed, What should we do in this case?
case 3: If we click on the button, Only replace the default values if it exists. or add the property if it is not already there.

Discussed with the backend team to work on this. It will take some more time decide on this. As it is an enhancement, transferring it to 3.2.

Comment by Tom Mueller [ 17/Oct/12 ]

Marking the fix version field as "future-release". This is based on an evaluation by John, Michael, and Tom WRT to the PRD for the Java EE 7 RI/SDK. This issues was deemed to not be a P1 for that release. If this is in error or there are other reasons why this RFE should be targeted for the Java EE 7 RI/SDK release, then change the fix version field back to an appropriate build.





[GLASSFISH-21587] Detailed error message is not displayed on many screens - only "An error has occurred" is displayed Created: 11/Nov/16  Updated: 11/Jan/17

Status: Open
Project: glassfish
Component/s: admin, admin_gui, hk2
Affects Version/s: 4.1, 4.1.1, 5.0
Fix Version/s: None

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


 Description   

As part of field validation for Admin Console screens, typically on a "Save" operation, a detailed error message may be displayed on the screen if an invalid field value has been specified.
For example, this may occur if the field value is out-of-range, conflicts with something else or has invalid contents etc.
I am specifically referring to the case when the value is not validated by Javascript on the page, but rather found to be invalid by a Glassfish internal RESTful web-service used for processing the field data.

What is noticeable in Glassfish 4.1 and above, is that for screen field values that fail validation by Glassfish internal web-services, rather than on-page validation by Javascript, in many cases the detailed error message is MISSING. Only "! An error has occurred" is displayed (which is insufficient in order to understand what error actually occurred). The detailed error message, which normally is displayed under this, is not displayed. Note that this problem didn't exist in GlassfishV3 (at worst, the detailed error message was "Check server log for more information").

Simple example cases of this "missing detailed error message" issue occur with integer-based fields, for example:

(i) "Deployment Order" for "Edit Connector Resource" screen (use value: 9999999999)
(ii) "Buffer Size" on the "Edit Transport" screen (use value: 8192999999)

You could argue that these screens should be fixed to consistently validate field data on-page using Javascript only, in these particular cases (and they probably should), however there are some things that can ONLY be validated by sending them back to Glassfish. In this case, when validation fails, a detailed error message is MEANT to be returned and displayed on the screen.

The missing detailed error message results from a combination of bugs in Glassfish's REST error-handling code, in the "org.glassfish.admin.rest.resources.TemplateRestResource" class:

1) This class was modified in Glassfish4 to throw WebApplicationExceptions instead of returning Responses. However, in the "doCreateOrUpdate" method, there already is an outer catch block that will catch these exceptions and wrap them in ANOTHER WebApplicationException (with code INTERNAL_SERVER_ERROR and blank error message), and this effectively hides the inner error message, when the outer WebApplicationException is caught and processed at a higher level.
2) The "handleError" method builds a Response with a plain-text message, which is contrary to the response header content type (json), and the resulting response cannot be parsed (conversion of json to plain text fails).

I have constructed the following 4.1.1 patch to correct these two issues (same patch code will work with Glassfish5):


-- TemplateRestResource.java	(revision 64111)
+++ TemplateRestResource.java	(working copy)
@@ -234,16 +234,18 @@
                 return new RestActionReporter();
             }
             //just update it.
             data = ResourceUtil.translateCamelCasedNamesToXMLNames(data);
             RestActionReporter ar = Util.applyChanges(data, uriInfo, getSubject());
             if (ar.getActionExitCode() != ActionReport.ExitCode.SUCCESS) {
-                throwError(Status.BAD_REQUEST, "Could not apply changes" + ar.getMessage()); // i18n
+                throwError(Status.BAD_REQUEST, "Could not apply changes: " + ar.getMessage()); // i18n
             }
 
             return ar;
+        } catch (WebApplicationException wae) {
+            throw wae;
         } catch (Exception ex) {
             throw new WebApplicationException(ex, Response.Status.INTERNAL_SERVER_ERROR);
         }
     }
 
     protected ExitCode doDelete(HashMap<String, String> data) {
@@ -634,9 +636,16 @@
         throw new WebApplicationException(handleError(error, message));
     }
 
     protected Response handleError(final Status error, final String message) throws WebApplicationException {
         //TODO better error handling.
 //                return Response.status(400).entity(ResourceUtil.getActionReportResult(ar, "Could not apply changes" + ar.getMessage(), requestHeaders, uriInfo)).build();
-        return Response.status(error).entity(message).build();
+        //return Response.status(error).entity(message).build();
+        // BUG-FIX
+        // The original line of code (commented-out below) builds a Response with a plain-text message, which is contrary to the response header content type (json).
+        // The resulting response cannot be parsed (conversion of json to plain text fails).
+        // This response parsing error never happened in the original GF code because the thrown WebApplicationException was
+        // erroneously wrapped with another WebApplicationException which had an INTERNAL_SERVER_ERROR status code and a blamk message.
+        // return Response.status(error).entity(message).build();
+        return Response.status(error).entity(ResourceUtil.getActionReportResult(ActionReport.ExitCode.FAILURE, message, requestHeaders, uriInfo)).build();
     }
 }

With this patch applied, an additional detailed message is displayed, like the following, for example case (i) mentioned above:

Could not apply changes: Could not change the attributes: javax.validation.ConstraintViolationException: Constraints for this ConnectorResource configuration have been violated: on property [ org.jvnet.hk2.config.WriteableView$4$2@726e42e9 ] violation reason [ is not of data type:java.lang.Integer ]

There still is a minor problem though. In the above error message you will notice that the property name is "org.jvnet.hk2.config.WriteableView$4$2@726e42e9", rather than the actual property name.
This appears to be because of a problem in one of the HK2 configuration classes (org.jvnet.hk2.config.WriteableView) in “hk2-config.jar”. The code in question is shown below, with the problem line highlighted using ★★.

private void handleValidationException(Set constraintViolations) throws ConstraintViolationException {

        if (constraintViolations != null && !constraintViolations.isEmpty()) {
            Iterator<ConstraintViolation<ConfigBeanProxy>> it = constraintViolations.iterator();

            StringBuilder sb = new StringBuilder();
            sb.append(MessageFormat.format(i18n.getString("bean.validation.failure"), this.<ConfigBeanProxy>getProxyType().getSimpleName()));
            String violationMsg = i18n.getString("bean.validation.constraintViolation");
            while (it.hasNext()) {
                ConstraintViolation cv = it.next();
                sb.append(" ");
                sb.append(MessageFormat.format(violationMsg, cv.getMessage(), cv.getPropertyPath()));  //★★
                if (it.hasNext()) {
                    sb.append(i18n.getString("bean.validation.separator"));
                }
            }
            bean.getLock().unlock();
            throw new ConstraintViolationException(sb.toString(), constraintViolations);
        }
}

★★The call to “cv.getPropertyPath()” above is returning a "javax.validation.Path" instance, so the code is relying on the toString() method of the implementation class to supply the property name string, but no such toString() method has been defined. Therefore the call to “cv.getPropertyPath()” above should instead be “cv.getPropertyPath().iterator().next().getName()”.
Or, alternatively, the code above could be left unchanged, and instead a “toString()” method could be added to the Path implementation, also defined in the WriteableView class, as shown below:


                    return new javax.validation.Path() {
                        @Override
                        public Iterator<Node> iterator() {
                            return nodes.iterator();
                        }
                        @Override
                        public String toString() {  //★★
                            return nodes.iterator().next().getName();
                        }
                    };

With the above fix applied, the displayed error message then correctly includes the actual property name, as shown below:

Could not apply changes: Could not change the attributes: javax.validation.ConstraintViolationException: Constraints for this ConnectorResource configuration have been violated: on property [ deployment-order ] violation reason [ is not of data type:java.lang.Integer ]






[GLASSFISH-21593] Problem viewing batch job execution information after running many jobs Created: 18/Nov/16  Updated: 11/Jan/17

Status: Open
Project: glassfish
Component/s: admin, admin_gui, batch
Affects Version/s: 4.1, 4.1.1, 5.0
Fix Version/s: None

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


 Description   

If a large number of batch jobs are run, then the Admin Console's "Batch Job Executions" screen can take a long time to display the batch job executions, This is because Glassfish effectively loads the WHOLE table of information, rather than loading it in chunks, as required. During this load time the screen freezes and is unresponsive. The time to wait for results to be displayed gets longer and longer as more and more batch jobs are run over time and the database grows in size. If there are 1000s of batch job execution results, then it can take minutes before displaying the results on the screen and becoming responsive again (depending upon the database used and computer's memory and processor specification etc.). As an example, in my case it took about 10 minutes for 2000+ batch job executions.

There is also the possibility of an out-of-memory condition for a sufficiently large number of batch job executions.

The "list-batch-jobs" and "list-batch-job-executions" asadmin sub-commands suffer the same problems.






[GLASSFISH-21417] Weld Exception is thrown during RENDER phase of JSF lifecycle in Glassfish 4.1. Created: 21/Aug/15  Updated: 08/Feb/17

Status: Open
Project: glassfish
Component/s: cdi, jsf
Affects Version/s: 4.1
Fix Version/s: None

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

Ubuntu Linux 15.04/14.04
Java 8



 Description   

Weld Exception is thrown during RENDER phase of JSF lifecycle in Glassfish 4.1.

It used to be thrown during EXECUTE phase in Glassfish 3.1.2.

Here the two stacktraces from Glassfish 4.1:

Severe: Error Rendering View[/index.xhtml]
org.jboss.weld.context.NonexistentConversationException: WELD-000321: No conversation found to restore for id 10
at org.jboss.weld.context.AbstractConversationContext.initialize(AbstractConversationContext.java:259)
at org.jboss.weld.context.http.LazyHttpConversationContextImpl.initialize(LazyHttpConversationContextImpl.java:68)
at org.jboss.weld.context.http.LazyHttpConversationContextImpl.checkContextInitialized(LazyHttpConversationContextImpl.java:93)
at org.jboss.weld.context.AbstractContext.get(AbstractContext.java:74)
at org.jboss.weld.context.PassivatingContextWrapper$AbstractPassivatingContextWrapper.get(PassivatingContextWrapper.java:76)
at org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:740)
at org.jboss.weld.el.AbstractWeldELResolver.lookup(AbstractWeldELResolver.java:107)
at org.jboss.weld.el.AbstractWeldELResolver.getValue(AbstractWeldELResolver.java:90)
at javax.el.CompositeELResolver.getValue(CompositeELResolver.java:188)
at com.sun.faces.el.DemuxCompositeELResolver._getValue(DemuxCompositeELResolver.java:180)
at com.sun.faces.el.DemuxCompositeELResolver.getValue(DemuxCompositeELResolver.java:208)
at com.sun.el.parser.AstIdentifier.getValue(AstIdentifier.java:116)
at com.sun.el.parser.AstValue.getBase(AstValue.java:151)
at com.sun.el.parser.AstValue.getValue(AstValue.java:200)
at com.sun.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:226)
at org.jboss.weld.el.WeldValueExpression.getValue(WeldValueExpression.java:50)
at com.sun.faces.facelets.el.TagValueExpression.getValue(TagValueExpression.java:112)
at javax.faces.component.ComponentStateHelper.eval(ComponentStateHelper.java:194)
at javax.faces.component.ComponentStateHelper.eval(ComponentStateHelper.java:182)
at javax.faces.component.UIOutput.getValue(UIOutput.java:174)
at com.sun.faces.renderkit.html_basic.HtmlBasicInputRenderer.getValue(HtmlBasicInputRenderer.java:205)
at com.sun.faces.renderkit.html_basic.HtmlBasicRenderer.getCurrentValue(HtmlBasicRenderer.java:355)
at com.sun.faces.renderkit.html_basic.HtmlBasicRenderer.encodeEnd(HtmlBasicRenderer.java:164)
at javax.faces.component.UIComponentBase.encodeEnd(UIComponentBase.java:923)
at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1906)
at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1902)
at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1902)
at com.sun.faces.application.view.FaceletViewHandlingStrategy.renderView(FaceletViewHandlingStrategy.java:459)
at com.sun.faces.application.view.MultiViewHandler.renderView(MultiViewHandler.java:136)
at javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:337)
at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:125)
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)
at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:219)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:665)
at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1682)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:318)
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.invoke(StandardPipeline.java:673)
at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:99)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:174)
at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:415)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:282)
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:201)
at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:175)
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:284)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:201)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:133)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:112)
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:561)
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:565)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:545)
at java.lang.Thread.run(Thread.java:745)

Here the stacktrace from Glassfish 3.1.2.2

SEVERE: WELD-000321 No conversation found to restore for id 10
org.jboss.weld.context.NonexistentConversationException: WELD-000321 No conversation found to restore for id 10
at org.jboss.weld.context.AbstractConversationContext.activate(AbstractConversationContext.java:221)
at org.jboss.weld.jsf.WeldPhaseListener.activateConversations(WeldPhaseListener.java:108)
at org.jboss.weld.jsf.WeldPhaseListener.beforePhase(WeldPhaseListener.java:85)
at com.sun.faces.lifecycle.Phase.handleBeforePhase(Phase.java:228)
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:99)
at com.sun.faces.lifecycle.RestoreViewPhase.doPhase(RestoreViewPhase.java:116)
at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:603)
at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1550)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:281)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:655)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:595)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:161)
at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:331)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:231)
at com.sun.enterprise.v3.services.impl.ContainerMapper$AdapterCallable.call(ContainerMapper.java:317)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:195)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:860)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:757)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1056)
at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:229)
at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90)
at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79)
at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54)
at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59)
at com.sun.grizzly.ContextTask.run(ContextTask.java:71)
at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532)
at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513)
at java.lang.Thread.run(Thread.java:745)

The problem is that JSF is not able to follow the exception handler's navigation handler redirect in RENDER phase.

Find additional information here:

https://java.net/jira/browse/JAVASERVERFACES-3870



 Comments   
Comment by timr99 [ 21/Aug/15 ]

How can I attach a reproducer?

Comment by jjsnyder83 [ 25/Aug/15 ]

This appears to be a jsf bug not a cdi bug. Reassigning it to Ed.





launch link in web app ignore virtual server (GLASSFISH-2918)

[GLASSFISH-19495] Parent issue is not resolved in GF-3.1.2.2 Created: 06/Jan/13  Updated: 08/Feb/17

Status: Open
Project: glassfish
Component/s: admin_gui
Affects Version/s: 3.1.2.2
Fix Version/s: 9.1pe

Type: Sub-task Priority: Major
Reporter: mahairod Assignee: sumasri
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

GF developer profile


Issue Links:
Cloners
is cloned by GLASSFISH-21413 CLONE - Parent issue is not resolved ... Open
Tags: admin-gui, regression, virtual_server

 Description   

Parent issue is not resolved in GF-3.1.2.2. While using multiple virtual servers and deploying just tto particular ones it's not availbale to launch application normally through admin gui






[GLASSFISH-21545] Websocket Container init error Created: 01/Jun/16  Updated: 13/Feb/17

Status: Open
Project: glassfish
Component/s: None
Affects Version/s: 4.1.1
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Huangyun Assignee: sumasri
Resolution: Unresolved Votes: 0
Labels: waiting_on_filer
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

JDK 1.8 Glassfish 4.1.1 Spring 4.2.6



 Description   

Maven:
<properties>
<spring.version>4.2.6.RELEASE</spring.version>
</properties>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-context</artifactId>
<version>$

{spring.version}</version>
<scope>compile</scope>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-webmvc</artifactId>
<version>${spring.version}

</version>
<scope>compile</scope>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-websocket</artifactId>
<version>$

{spring.version}</version>
<scope>compile</scope>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-messaging</artifactId>
<version>${spring.version}

</version>
<scope>compile</scope>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-tx</artifactId>
<version>$

{spring.version}

</version>
<scope>compile</scope>
</dependency>

<websocket:message-broker>
<websocket:stomp-endpoint path="/monitor">
<websocket:sockjs websocket-enabled="true"/>
</websocket:stomp-endpoint>
<websocket:simple-broker prefix="/topic, /queue"/>
</websocket:message-broker>

then, start glassfish 4.1.1, the console radom show:

Servlet.service() for servlet dispatcher threw exception
java.lang.IllegalArgumentException: No 'javax.websocket.server.ServerContainer' ServletContext attribute. Are you running in a Servlet container that supports JSR-356?



 Comments   
Comment by sumasri [ 02/Feb/17 ]

Please provide the detailed steps to reproduce the issue in Glassfish.





[GLASSFISH-21462] adminGUI does not load the classpath from manifest.mf to the precompilejsp in Application Deploy module Created: 05/Nov/15  Updated: 14/Feb/17

Status: Open
Project: glassfish
Component/s: admin_gui, classloader, deployment, ejb_container
Affects Version/s: 4.1.1
Fix Version/s: None

Type: Bug Priority: Major
Reporter: ccagf Assignee: sumasri
Resolution: Unresolved Votes: 0
Labels: jspc, precompilejsp, waiting_on_filer
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: PWC6112, admin-gui, admingui, deploy, java.lang.ClassNotFoundException:, jspc, precompilejsp

 Description   

in adminGUI ==> Applications ==> Deploy Applications or Modules ==> Precompile JSPs:

if You choose the Option - Precomplier works with JARs included in the LIB
But Fails when 3rd Party Jars are refeneced in the manifest.mf file - as the Glassfish Precomplier is not reading the class path from manifest.mf.

In Glassfish Version 2.1.1 It Works - Stopped working since Glassfish v3.
Does Not work on Glassfish 4.1.1

Sugested BUG Fix - adminGUI (when precompilejsp is checked) also needs to Read the Manifest.MF's Class-Path and pass it on to the jspc compiler.

Error: PWC6112
java.lang.ClassNotFoundException:

Just FYI - When I pass the class-path part of jspc and copmile it works - so the bug surely is on the adminGUI console



 Comments   
Comment by sumasri [ 14/Feb/17 ]

I created a web application and referred third party jar in manifest.mf file and created war file for deploying.
Deployed that app and is working as expected. I do not see any issue as specified in the issue.
If you still see the issue, please provide me the app and exact steps to reproduce the issue.





[GLASSFISH-21259] admin-thread-pool is created after logging in the admin console Created: 26/Nov/14  Updated: 14/Feb/17

Status: Open
Project: glassfish
Component/s: admin_gui
Affects Version/s: 3.1.2.2, 4.1
Fix Version/s: None

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


 Description   

domain.xml of server-config has the definition of admin-thread-pool.

        <network-listeners>
          <network-listener port="8080" protocol="http-listener-1" transport="tcp" name="http-listener-1" thread-pool="http-thread-pool"></network-listener>
          <network-listener port="8181" protocol="http-listener-2" transport="tcp" name="http-listener-2" thread-pool="http-thread-pool"></network-listener>
          <network-listener port="4848" protocol="admin-listener" transport="tcp" name="admin-listener" thread-pool="admin-thread-pool"></network-listener>
        </network-listeners>
        <transports>
          <transport name="tcp"></transport>
        </transports>
      </network-config>
      <thread-pools>
          <thread-pool name="admin-thread-pool" max-thread-pool-size="50" max-queue-size="256"></thread-pool>
          <thread-pool name="http-thread-pool" max-queue-size="4096"></thread-pool>
          <thread-pool name="thread-pool-1" max-thread-pool-size="200"/>
      </thread-pools>

On the other hand, default-config doesn't have admin-thread-pool,
and http-thread-pool is referenced by admin-listener.

             <network-listeners>
                 <network-listener address="0.0.0.0" port="${HTTP_LISTENER_PORT}" protocol="http-listener-1" transport="tcp" name="http-listener-1" thread-pool="http-thread-pool" />
                 <network-listener address="0.0.0.0" port="${HTTP_SSL_LISTENER_PORT}" protocol="http-listener-2" transport="tcp" name="http-listener-2" thread-pool="http-thread-pool" />
                 <network-listener port="${ASADMIN_LISTENER_PORT}" protocol="admin-listener" transport="tcp" name="admin-listener" thread-pool="http-thread-pool" />
             </network-listeners>
             <transports>
                 <transport name="tcp" />
             </transports>
         </network-config>
         <thread-pools>
             <thread-pool name="http-thread-pool" />
             <thread-pool max-thread-pool-size="200" idle-thread-timeout-in-seconds="120" name="thread-pool-1" />
         </thread-pools>

Therefore, created clusters don't have admin-thread-pool.

However, after logging in the admin console, admin-thread-pool is created to default-config and clusters.
Generated admin-thread-pool is not referenced by admin-listener, and admin-thread-pool seems to be a ejb-thread-pool.

        <network-listeners>
          <network-listener port="${HTTP_LISTENER_PORT}" protocol="http-listener-1" transport="tcp" name="http-listener-1" thread-pool="http-thread-pool"></network-listener>
          <network-listener port="${HTTP_SSL_LISTENER_PORT}" protocol="http-listener-2" transport="tcp" name="http-listener-2" thread-pool="http-thread-pool"></network-listener>
          <network-listener port="${ASADMIN_LISTENER_PORT}" protocol="pu-protocol" transport="tcp" name="admin-listener" thread-pool="http-thread-pool"></network-listener>
        </network-listeners>
        <transports>
          <transport name="tcp"></transport>
        </transports>
      </network-config>
      <thread-pools>
        <thread-pool name="http-thread-pool"></thread-pool>
        <thread-pool name="thread-pool-1" max-thread-pool-size="200"></thread-pool>
        <thread-pool name="admin-thread-pool" max-thread-pool-size="50" max-queue-size="256"></thread-pool>
      </thread-pools>

Why?






[GLASSFISH-21239] Monitoring is not displayed in the console if the administrator password is not blank Created: 22/Oct/14  Updated: 09/Mar/17

Status: In Progress
Project: glassfish
Component/s: rest-interface
Affects Version/s: 4.1
Fix Version/s: None

Type: Bug Priority: Major
Reporter: smillidge-c2b2 Assignee: sumasri
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Linux


Status Whiteboard:

Thanks for reporting and even suggesting a solution.
Although the symptoms show up in the console, your suggestion points to the REST api. I will assign this to Mitesh as he worked on this and has more understanding about this area.


 Description   

To reproduce the error

Install a fresh domain
Start the domain
Access the console
Set the administrator password to something non-blank
Create a new standalone instance
Set the monitoring configuration to HIGH for all modules
Start the new instance
Access the monitoring screen -> Server tab
No monitoring is displayed
Change the administrator password to blank
restart the instance
access monitoring
monitoring information is displayed



 Comments   
Comment by smillidge-c2b2 [ 23/Oct/14 ]

I believe this commit fixes the problem

https://github.com/payara/Payara/commit/1686bfbf2df6b7d1f5c8879fc3a437dba43a4045

diff --git a/nucleus/admin/rest/rest-service/src/main/java/org/glassfish/admin/rest/utils/ProxyImpl.java b/nucleus/admin/rest/rest
index 7a20f73..c4c3ebb 100644
— a/nucleus/admin/rest/rest-service/src/main/java/org/glassfish/admin/rest/utils/ProxyImpl.java
+++ b/nucleus/admin/rest/rest-service/src/main/java/org/glassfish/admin/rest/utils/ProxyImpl.java
@@ -67,7 +67,6 @@ import com.sun.enterprise.config.serverbeans.Domain;
import com.sun.enterprise.config.serverbeans.SecureAdmin;
import com.sun.enterprise.config.serverbeans.Server;
import com.sun.enterprise.security.ssl.SSLUtils;
-import javax.ws.rs.client.Invocation.Builder;

/**

  • @author Mitesh Meswani
    @@ -86,11 +85,7 @@ public abstract class ProxyImpl implements Proxy {
    URI forwardURI = forwardUriBuilder.scheme("https").host(forwardInstance.getAdminHost()).port(forwardInstance.getA
    client = addAuthenticationInfo(client, forwardInstance, habitat);
    WebTarget resourceBuilder = client.target(forwardURI);
  • SecureAdmin secureAdmin = habitat.getService(SecureAdmin.class);
  • Builder builder = resourceBuilder.request(MediaType.APPLICATION_JSON).header(SecureAdmin.Util.ADMIN_INDICATOR_HEA
    -
  • Response response = builder.get(Response.class); //TODO if the target server is down, we get ClientResponseExcept
    + Response response = resourceBuilder.request(MediaType.APPLICATION_JSON).get(Response.class); //TODO if the target
    Response.Status status = Response.Status.fromStatusCode(response.getStatus());
    if (status.getFamily() == javax.ws.rs.core.Response.Status.Family.SUCCESSFUL) {
    String jsonDoc = response.readEntity(String.class);




[GLASSFISH-21150] FishCAT please bring back the JNDI viewer Created: 30/Jul/14  Updated: 09/Mar/17

Status: Open
Project: glassfish
Component/s: admin_gui
Affects Version/s: 4.1
Fix Version/s: None

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


 Description   

please bring back the ability to view the JNDI tree via the web gui.

https://java.net/jira/browse/GLASSFISH-5842






[GLASSFISH-21190] Properties substitution issue Created: 10/Sep/14  Updated: 09/Mar/17

Status: Open
Project: glassfish
Component/s: admin_gui
Affects Version/s: 4.1
Fix Version/s: None

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

Glassfish 4.1 on Windows 7 64bit



 Description   

Hi there,
I found an issue with properties substitution in Glassfish 4.1 on a Windows 7 64bit environment.

I build an application in which I used glassfish-resources.xml file to define a jdbc-resource and a jdbc-connection-pool: for database parameters I used three property aliases. They are listet below:

$

{postgres_user}
${postgres_port}
${postgres_host}

At the same time I did set the corresponing system properties with the correct values.

After application deploying (deployed by NetBeans 8.0.1) by glassfifh interface, I tried to ping jdbc connection pool (from application resources) and I got this error:

Ping Connection Pool failed for { PoolInfo : (name=java:app/RedevoDBPool), (applicationName=RedevoServer-ejb) }. Connection could not be allocated because: FATAL: password authentication failed for user "${postgres_user}

" Please check the server.log for more details.

So, I went to "Additiona Properties" of jdbc connection pool and I clicked on Save button. After that, I tried again to ping connection pool and the operation ended without any error.

So we can assume that it is an issue in substitution of System Property values after their "deploying" by glassfish-resources.xml file.

I am available for any other explanation.

Very kind regards.

Mephysto






[GLASSFISH-21434] NullPointerException at com.sun.faces.taglib.html_basic.CommandTagParserImpl.parseStartElement Created: 29/Sep/15  Updated: 23/Mar/17

Status: Open
Project: glassfish
Component/s: jsf
Affects Version/s: 3.1.1
Fix Version/s: None

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

Issuezilla Id: 21,434

 Description   

In my application,when multiple JSPs are accessed,once in a while I will get the following error message.
And when a only JSP is accessed,the error will never happen.
<pre>
--------------------------------
[#|2015-09-29T11:08:28.801+0900|WARNING|glassfish3.1.1|javax.enterprise.system.container.web.com.sun.enterprise.web._vs.server|_ThreadID=119;_ThreadName=Thread-28;|StandardWrapperValve[Faces Servlet]: PWC1406: Servlet.service() for servlet Faces Servlet threw exception
java.lang.NullPointerException
at com.sun.faces.taglib.html_basic.CommandTagParserImpl.parseStartElement(CommandTagParserImpl.java:116)
at com.sun.faces.taglib.html_basic.HtmlBasicValidator$HtmlBasicValidatorHandler.startElement(HtmlBasicValidator.java:140)
at org.apache.xerces.parsers.AbstractSAXParser.startElement(AbstractSAXParser.java:496)
at org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanStartElement(XMLNSDocumentScannerImpl.java:283)
at org.apache.xerces.impl.XMLNSDocumentScannerImpl$NSContentDispatcher.scanRootElementHook(XMLNSDocumentScannerImpl.java:733)
at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(XMLDocumentFragmentScannerImpl.java:1754)
at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:324)
at org.apache.xerces.parsers.XML11Configuration.parse(XML11Configuration.java:845)
at org.apache.xerces.parsers.XML11Configuration.parse(XML11Configuration.java:768)
at org.apache.xerces.parsers.XMLParser.parse(XMLParser.java:108)
at org.apache.xerces.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1196)
at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(SAXParserImpl.java:555)
at org.apache.xerces.jaxp.SAXParserImpl.parse(SAXParserImpl.java:289)
at javax.xml.parsers.SAXParser.parse(SAXParser.java:198)
at com.sun.faces.taglib.FacesValidator.validate(FacesValidator.java:273)
at org.apache.jasper.compiler.TagLibraryInfoImpl.validate(TagLibraryInfoImpl.java:949)
at org.apache.jasper.compiler.Validator.validateXmlView(Validator.java:1921)
at org.apache.jasper.compiler.Validator.validate(Validator.java:1888)
at org.apache.jasper.compiler.Compiler.generateJava(Compiler.java:223)
at org.apache.jasper.compiler.Compiler.compile(Compiler.java:451)
at org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:625)
at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:374)
at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:492)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:378)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:847)
--------------------------------
</pre>

The following is the coding of the com.sun.faces.taglib.html_basic.CommandTagParserImpl.parseStartElement.
<pre>
--------------------------------
public void parseStartElement() {
String ns = validatorInfo.getNameSpace();
String ln = validatorInfo.getLocalName();

if (ns.equals(RIConstants.HTML_NAMESPACE)) {
LINE116 if (ln.equals("commandButton"))

{ handleCommandButton(); }

}
}
--------------------------------
</pre>
LINE116 is the place where the NullPointerException happened.
After analyzed glassfish code,The reason why nameSpace can't been gotten is that
the following release() is not synchronized, before the end of the validate(), the "validatorInfo" is created again.

org.apache.jasper.compiler.TagLibraryInfoImpl
<pre>
----------------
public ValidationMessage[] validate(PageData thePage) {
TagLibraryValidator tlv = getTagLibraryValidator();
if (tlv == null) return null;

String uri = getURI();
if (uri.startsWith("/"))

{ uri = URN_JSPTLD + uri; }

ValidationMessage[] messages = tlv.validate(getPrefixString(), uri, thePage);
tlv.release();

return messages;
}
----------------
</pre>

It seems that the phenomenon is a glassfish internal bug.



 Comments   
Comment by Cai_Ming [ 07/Oct/15 ]

Hi,
It's been almost 3 weeks since I sent my report.
How do you think about this problem?

Although the LINE913 of validate(com.sun.faces.taglib.FacesValidator#validate) is synchronized,
the LINE914 of release is not synchronized.
so technically "validatorInfo" can be easily reset in between validate() and release().

To resolve this problem,We try to make the following changes in the code of org.apache.jasper.compiler.TagLibraryInfoImpl.
solution1:
----------------
public ValidationMessage[] validate(PageData thePage) {
TagLibraryValidator tlv = getTagLibraryValidator();
if (tlv == null) return null;

String uri = getURI();
if (uri.startsWith("/"))

{ uri = URN_JSPTLD + uri; }

// ValidationMessage[] messages = tlv.validate(getPrefixString(), uri,
thePage);
// tlv.release();
ValidationMessage[] messages =null;
synchronized (tlv)

{ messages = tlv.validate(getPrefixString(), uri, thePage); tlv.release(); }

return messages;
}
----------------

solution2:
Because the LINE913 validate already contained the process of release,
there is no necessary to release again.
So,even if directly delete the LINE914 tlv.release() it will be OK.
----------------
public ValidationMessage[] validate(PageData thePage) {
TagLibraryValidator tlv = getTagLibraryValidator();
if (tlv == null) return null;

String uri = getURI();
if (uri.startsWith("/"))

{ uri = URN_JSPTLD + uri; }

LINE913 ValidationMessage[] messages = tlv.validate(getPrefixString(), uri,
thePage);
LINE914 // tlv.release();

return messages;
}
----------------

Looking forward to your reply!

Comment by sumasri [ 23/Mar/17 ]

Please provide us the application and detailed instructions to reproduce this.





[GLASSFISH-21534] Jersey Client POSTs between GF apps (microservice) timeout Created: 13/Apr/16  Updated: 23/Mar/17

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

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

GlassFish Server Open Source Edition 4.1.1 (build 1)
Windows Server 2008R2


Tags: Jersey

 Description   

I'm attempting a REST request from one GF deployed app to another (on same server), but the request is times out. I've tried to increased the timeout value, but that doesn't work.

Here is some sample code:

ClientConfig clientConfig = null;
Client client = null;
WebTarget webTarget = null;
FormDataMultiPart formDataMultiPart = null;
Invocation.Builder invocationBuilder = null;
Response response = null;

clientConfig = new ClientConfig();
clientConfig.register(MultiPartFeature.class);
clientConfig.register(ListReader.class);

String url = "http://localhost:8080/someapp"
String urlPath = "/rest/path";

Map<String, String> params = new HashMap<>();
params.put("option", "value");

Map<String, String> formFields = new HashMap<>();
formFields.put("field1", "value");

List<BodyPart> fileParts = null;

// See http://www.adam-bien.com/roller/abien/entry/setting_timeout_for_the_jax
clientConfig.property("jersey.config.client.connectTimeout", 7000);
clientConfig.property("jersey.config.client.readTimeout", 7000);
client = ClientBuilder.newClient(clientConfig);
webTarget = client.target(url).path(urlPath);

if (params != null && !params.isEmpty()) {
for (String key : params.keySet())

{ webTarget = webTarget.queryParam(key, params.get(key)); }

}

formDataMultiPart = new FormDataMultiPart();
formDataMultiPart.setMediaType(MediaType.MULTIPART_FORM_DATA_TYPE);
if (fileParts != null && !fileParts.isEmpty()) {
for (BodyPart bodyPart : fileParts)

{ formDataMultiPart.bodyPart(bodyPart); }

}

if (formFields != null && !formFields.isEmpty()) {
for (Map.Entry<String, String> formField : formFields.entrySet())

{ formDataMultiPart.field(formField.getKey(), formField.getValue()); }

}

invocationBuilder = webTarget.request(MediaType.APPLICATION_JSON);
response = invocationBuilder.post(Entity.entity(formDataMultiPart, formDataMultiPart.getMediaType()));



 Comments   
Comment by sumasri [ 23/Mar/17 ]

Please provide us the 2 applications and detailed instructions to reproduce the issue.





[GLASSFISH-21709] New Network config protocol throws run time exception in GUI. Created: 27/Mar/17  Updated: 24/Apr/17

Status: In Progress
Project: glassfish
Component/s: admin_gui
Affects Version/s: 5.0
Fix Version/s: None

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


 Description   

In GUI, click on default-config->network config->protocols->New Button. It is throwing run time exception .
In server log, exception seen is

[2017-03-27T16:41:45.855+0530] [glassfish 5.0] [SEVERE] [] [javax.enterprise.resource.webcontainer.jsf.context] [tid: _ThreadID=55 _ThreadName=admin-listener(5)] [timeMillis: 1490613105855] [levelValue: 1000] [[
java.lang.RuntimeException: java.lang.reflect.InvocationTargetException while attempting to process a 'beforeCreate' event for 'event262'.
at com.sun.jsftemplating.layout.descriptors.LayoutElementBase.dispatchHandlers(LayoutElementBase.java:425)
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:557)
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:261)
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:100)
at com.sun.faces.lifecycle.RestoreViewPhase.doPhase(RestoreViewPhase.java:133)
at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:201)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:670)
at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1580)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:338)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208)
at com.sun.webui.jsf.util.UploadFilter.doFilter(UploadFilter.java:233)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:250)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:256)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:160)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:652)
at org.apache.catalina.core.StandardPipeline.doChainInvoke(StandardPipeline.java:596)
at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:97)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:155)
at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:371)
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:284)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:201)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:133)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:112)
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:539)
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:593)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:573)
at java.lang.Thread.run(Thread.java:745)
Caused by: java.lang.reflect.InvocationTargetException
at sun.reflect.GeneratedMethodAccessor175.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
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






[GLASSFISH-13935] Connector: disable Processing... button Created: 12/Oct/10  Updated: 09/Mar/12

Status: Reopened
Project: glassfish
Component/s: admin_gui
Affects Version/s: 3.1
Fix Version/s: future release

Type: Bug Priority: Minor
Reporter: lidiam Assignee: sumasri
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: JPEG File processing-v2.JPG     JPEG File processing-v3.JPG     JPEG File resource-runtime-exception.JPG     Text File server.log    
Issuezilla Id: 13,935

 Description   

build: glassfish-3.1-b24-10_10_2010.zip

Currently when I click on delete for resources (connector or jdbc) a
"Processing..." button is displayed and it is active, meaning I can click it
again and get the same prompt displayed again. This button should be disabled,
as it is in v2, for all such actions. However, I did not observe any negative
side effects of this button being active (no exceptions in server.log, deletion
completes fine), thus potentially this issue could have a lower priority.



 Comments   
Comment by lidiam [ 12/Oct/10 ]

Created an attachment (id=5129)
screenshot - v2

Comment by lidiam [ 12/Oct/10 ]

Created an attachment (id=5130)
screenshot - v3

Comment by sumasri [ 13/Oct/10 ]

Added a target milestone.

Comment by sumasri [ 22/Oct/10 ]

->MS7

Comment by sumasri [ 11/Nov/10 ]

Once it starts the delete operation, if we click on the "delete" button also, it
will be no op as it has already started the process.

So, Changing it to lower priority.

Comment by sumasri [ 02/Dec/10 ]

Jason has made some changes related to this. This issue is also resolved with that change.
When user clicks on delete for resources (connector or jdbc) a "Processing..." button is displayed and user is not able to click on the button now. Hence, closing the issue as resolved.

Comment by lidiam [ 25/Feb/11 ]

Tested in promoted build b43 and the issue still exists, though the button is displayed for a short time, since deletion of the resource is quick. The bad thing is that now the click on "Processing" button results in runtime exception printed on the screen. Steps to reproduce:

1. Create a Connector Resource filling as many fields, creating properties as desired.
2. On the Connector Resources screen select the newly created resource and click Delete. Hit OK on prompt and right away click on "Processing" that appears in place of "Delete" button. Hit OK on prompt again. - At first the page will display with the table but after a while the following is printed in the right hand frame:

class java.lang.RuntimeException

This may be a bit more of an issue on slower systems, when deletion takes longer.

By the way, when creating a resource, there is also a "Processing..." button, but it is grayed out and inactive, as it should be.

Comment by lidiam [ 25/Feb/11 ]

Attached screenshot and server.log.

Comment by sumasri [ 09/Mar/12 ]

Updating the fix version to future release.





[GLASSFISH-18119] Tree highliting never removed from Domain after accessing Domain Logs Created: 04/Jan/12  Updated: 20/Dec/16

Status: Open
Project: glassfish
Component/s: admin_gui
Affects Version/s: 3.1.2_dev
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: lidiam Assignee: sumasri
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

ogs-3.1.2-b16.zip, DAS on solaris


Attachments: JPEG File highlight.JPG    
Tags: 312_gui_new, 312_qa

 Description   

Steps to reproduce:

1. Go to Admin Console and click on Domain
2. Click on any other node - tree highlight moves to the new node.
3. Click again on Domain and then on Domain Logs tab, and WAIT till page finishes loading completely (no hour glass at all).
4. Now click on any other tree node - the highlight is now in two places: on the newly selected node and still on Domain (will attach screenshot).

This can be "reset" by clicking on Domain node again, e.g. click on Domain node and then other node - now highlight from Domain is removed.



 Comments   
Comment by Anissa Lam [ 04/Jan/12 ]

request help from Suma.

Comment by sumasri [ 05/Jan/12 ]

Not able to reproduce the issue with 3.1.2 workspace.
Lidia, I would like you to test it with the fresh installation and please let us know the result.

Comment by lidiam [ 05/Jan/12 ]

I have just reinstalled b16 on solaris (ogs zip) and see the same issue.

Comment by Anissa Lam [ 10/Jan/12 ]

This is browser specific and timing related also.

I see the issue consistently on
Chrome 14.0.835.202 on Mac.
Safari 5 on Mac

intermittently on
Chrome 16 on Window XP
Safari 4 on Window XP

However, the following works fine, cannot reproduce the problem.
Firefox 7 on my Mac
Mozilla Firefox 7 on Solaris
IE 8 on Windows XP
Firefox 6 on Windows XP

So, it seems this happens only on Chrome and Safari more often.

Lidia what browser are you using ?

Given the fact that

  • this isn't causing any functionality issue,
  • can easily be fixed, just go to Common Task page, or click Home Button, or refresh browser,
  • no data lost
  • only appear in some browser

Plus the fact that

  • HCF is tonight and this involves the ajax tree code which is of high risk when changed,

I am lowering this to a P4.
We may look into this if there is followup v3 release after 3.1.2.

Comment by lidiam [ 10/Jan/12 ]

I'm testing on Chrome on Windows XP. It happens every time I go to Domain Logs.





[GLASSFISH-15698] Need clear Error message while creating JDBC connection pool in Admin Console. Created: 26/Jan/11  Updated: 19/Dec/16

Status: Open
Project: glassfish
Component/s: admin_gui
Affects Version/s: 3.1_dev
Fix Version/s: not determined

Type: Bug Priority: Minor
Reporter: shaline Assignee: sumasri
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

OS: Solaris Sparc 10
browser : firefox 3.6



 Description   

GF build used : nightly dated b39-01-25-11
When we create a JDBC connection Pool, if we do not specify any value in the Additional properties for the particular DB vendor, and click the finish button. The pool gets created, but when we select the created pool, and click the "Advanced" tab an error or an exception is thrown, which is not very clear to User what went wrong. Error message needs to be clear.
Steps:
Create Derby Pool, by selecting javax.sql.Datasource, and Derby DB.
Select default and click finish button. ( DO Not specify anything in the additional properties window).
Select the created pool, and click the "Advanced" tab. See the below Error , which is not very clear.
,

An error has occurred

_get-validation-table-names failed : javax.resource.spi.SecurityException: No PasswordCredential found

For Oracle DB, with the same above steps, the below Exception shows up,, since we did not add any additional properties.

An error has occurred
_get-validation-table-names failed : javax.resource.spi.ResourceAllocationException: Connection could not be allocated because: Invalid Oracle URL specified: OracleDataSource.makeURL



 Comments   
Comment by Jagadish [ 26/Jan/11 ]

GUI need not call this method _get-validation-table-names always. It has to be called only when validation is turned on and validation method is table. In this case, its being called even when validation is turned OFF.

Refer both the exceptions :
1) No password credential found
2) Invalid Oracle URL specified

They state that "username, password" are not specified and URL is incorrect. These exceptions are from the driver vendor.

Probably, GUI need to avoid showing this issue when validation is not turned ON.

Comment by Jagadish [ 26/Jan/11 ]

Instead of showing the message as :
_get-validation-table-names failed : javax.resource.spi.SecurityException: No PasswordCredential found

It can be shown as :
Unable to get the list of table-names for selecting the table for table-based validation, following error occurred :
javax.resource.spi.SecurityException: No PasswordCredential found

Comment by sumasri [ 06/Jul/11 ]

Fixed this as part of the issue #16397. Please verify with the latest workspace and update the issue.

Comment by Tom Mueller [ 06/Mar/12 ]

Bulk update to change fix version to "not determined" for all issues still open but with a fix version for a released version.





[GLASSFISH-17786] Add Instance Dropdown in the Application and Resources page to jump to view monitoring data Created: 21/Nov/11  Updated: 21/Nov/11

Status: Open
Project: glassfish
Component/s: admin_gui
Affects Version/s: 3.1.1
Fix Version/s: future release

Type: Improvement Priority: Minor
Reporter: Anissa Lam Assignee: sumasri
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

This is the 2nd part of RFE to make monitoring data more accessible.
Refer to GLASSFISH-17506.

Application and Resource page should provide a Dropdown that brings user directly to the selected instance, with the application or resource pre-selected. We either have it for all or don't do it.






[GLASSFISH-17910] Facilitate mutliple targets in add resources page Created: 06/Dec/11  Updated: 15/Jan/13

Status: Open
Project: glassfish
Component/s: admin_gui
Affects Version/s: None
Fix Version/s: future release

Type: Improvement Priority: Minor
Reporter: sumasri Assignee: sumasri
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

In add resources page, user can select only one target.
Provide a way to select multiple targets.



 Comments   
Comment by Anissa Lam [ 19/Oct/12 ]

target for EE7 MS4 feature freeze date.

Comment by Anissa Lam [ 15/Jan/13 ]

Target for after 4.0.





[GLASSFISH-16739] Error occurs when saving the description of HTTP Servcie in Admin console Created: 26/May/11  Updated: 20/Dec/16  Due: 26/May/11

Status: Open
Project: glassfish
Component/s: admin_gui
Affects Version/s: 3.1.1_dev
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: li.wu Assignee: sumasri
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

OS: Solaris 11 Express Sparc
Server locale: ko_KR.UTF-8
Bundle: java_ee_sdk-6u3-web-b06-jdk7-solaris-sparc-ml.sh
Browser: Firefox 3.6


Attachments: JPEG File http_service_property.jpg     JPEG File http_service_property_saved.jpg    

 Description   

1. Install bundle of "java_ee_sdk-6u3-web-b06-jdk7-solaris-sparc-ml.sh ";
2. Login Admin console and click Configurations-> default config -> HTTP Service in the left tree;
3. In the table of "Additional Properties",click Add Property;
4. Enter "test" for Name,"1234" for Value,and "!@#$%^&" for Description, and then clik Save;
5. New values successfully saved, but there are more properties displayed which Name and Value show "#$%^&*". Pls check the pictures attached;
6. There is no exception in log file for this issue. Same issue can be reproduced in HTTP Service of "server config".



 Comments   
Comment by Anissa Lam [ 26/May/11 ]

i believe this is a general problem in the desc. field of all properties.

Comment by sumasri [ 26/May/11 ]

Not able to reproduce the issue. The description for a property is getting saved properly.

Please provide me the exact steps/configuration to reproduce the issue.

Configuration in my box:
Glassfish build : glassfish-3.1-web-b43-unix-ml.sh
OS : Ubuntu10.04
JDK :Java6update23
Language :ko_KR

Where can we find glassfish build(java_ee_sdk-6u3-web-b06-jdk7-solaris-sparc-ml.sh)?

Comment by li.wu [ 27/May/11 ]

1. Get the bundle from http://javaweb.us.oracle.com/java/re/javaeesdk/6u3/promoted/b06
2. Install it on Solaris 11 Express Sparc (java version is 1.6.0_13),and server locale is ko_KR.UTF-8;
3. Login Admin console and click Configurations-> default config -> HTTP Service in the left tree;
4. In the bottom of this frame,click Add Property;
5. Enter "test" for Name, "1234" for Value, and "!@#$%^&" for Description, and then clik Save.





ResourceAllocationException occurred in "Edit JDBC Connection Pool Advanced Attributes" page. (GLASSFISH-16397)

[GLASSFISH-16893] Provide a dev test for JDBC Connection pool advanced page -> connection validation section Created: 22/Jun/11  Updated: 22/Jun/11

Status: Open
Project: glassfish
Component/s: admin_gui
Affects Version/s: None
Fix Version/s: None

Type: Sub-task Priority: Minor
Reporter: sumasri Assignee: sumasri
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

To provide a dev test for JDBC Connection pool advanced page -> conenction validation section, it should start the database before running the test.






[GLASSFISH-21408] long logger class names do not appear on admin site after being added Created: 06/Aug/15  Updated: 22/Mar/17

Status: Open
Project: glassfish
Component/s: admin_gui
Affects Version/s: 4.1, 4.1.1, 5.0
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: pbelbin Assignee: sumasri
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

all



 Description   

after adding a longish class name to the log configuration page, and hitting 'save' (and receiving a 'success' response), the class name and level is not visible on the web page.

examination of the logging.properties file reveals that the setting was saved.

it just isn't visible on the admin gui.



 Comments   
Comment by fredaabedi [ 13/Oct/15 ]

Hello, are you planning to fix this issue?

Thank you,
Fred

Comment by sumasri [ 22/Mar/17 ]

I tried this and I could see the logger name on Module log level page.
I tried the logger name as "org.glassfish.aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaabbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbvccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccdddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffggggggggggggggggggggggggggggggggggggggggggggggggggghhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii". I hope this is big enough to test this issue.

I used below steps to test this issue.
Go to server-config->Logger settings->Log levels tab.
Click on Add Logger and enter the above logger name and set the level as INFO.
After saving the values, I could see the entry in the table.

If you still see the issue, Please provide me the detailed instructions to reproduce the issue.





Generated at Fri Apr 28 01:33:07 UTC 2017 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.