<< Back to previous view

[GLASSFISH-13134] Allow to override javax.* packages on the web application level Created: 26/Aug/10  Updated: 23/Aug/11

Status: Open
Project: glassfish
Component/s: web_container
Affects Version/s: v3.0.1
Fix Version/s: None

Type: Improvement Priority: Critical
Reporter: Jakub Podlesak Assignee: Shing Wai Chan
Resolution: Unresolved Votes: 3
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Linux


File Attachments: Text File overrideablePackages.patch    
Issuezilla Id: 13,134
Tags:
Participants: gfuser9999, Jakub Podlesak, Shing Wai Chan and survivant

 Description   

While there is a good reason to disallow applications to override e.g. the
standard Servlet API implementation in GlassFish, it could make perfect sense
for other Java EE APIs. For instance there is already a custom tag in
sun-web.xml to allow using custom JSF API classes bundled with a web application
to override the default version bundled with GlassFish. I would like to make
this possible also for JAX-RS API, and also at the application level.

Currently, one could use the following command:
asadmin create-jvm-options
-Dcom.sun.enterprise.overrideablejavaxpackages=javax.ws.rs,javax.ws.rs.core,javax.ws.rs.ext

together with <class-loader delegate="false"> in the sun-web.xml

This, however, works only at the application server level and does not allow
control at the application level as in the JSF case. The drawbacks are obvious:
if you do not control the whole container, you are out of luck. Also to change
this just for one application, you would need to restart the whole server
and interrupt also the other running applications.

I am going to attach a patch to allow to specify a list of overriden
Java packages in the GlassFish specific web application descriptor,
sun-web.xml or glassfish-web.xml, so that the application could
configure use of it's own bundled Java packages belonging to the protected
javax.* space.

Following is an excerpt of how the web application bundling it's own
JAX-RS implementation should look like after the patch is applied:

<class-loader delegate="false">
<property name="overrideablePackages"
value="javax.ws.rs,javax.ws.rs.core,javax.ws.rs.ext"/>
</class-loader>



 Comments   
Comment by Jakub Podlesak [ 26/Aug/10 08:58 AM ]

Created an attachment (id=4745)
patch

Comment by survivant [ 02/Feb/11 10:17 AM ]

please check the Issue http://java.net/jira/browse/GLASSFISH-15741

for a sample that doesn't work.

Comment by gfuser9999 [ 23/Aug/11 02:34 AM ]

user comment
------------
1) This issues is for http://java.net/jira/browse/GLASSFISH-15741
is not differently related to this issue.
The testcase in http://java.net/jira/browse/GLASSFISH-15741
is due to classloading but this fix enhancement
is neccesary to provide per-webapp isolation
of Jersey and others.

2) For example with adding "-Dcom.sun.enterprise.overrideablejavaxpackages=javax.ws.rs,javax.ws.rs.core,javax.ws.rs.ext" and where the sun-web.xml have
delegate="false", the above same app will fail after
a deploy <app>, undeploy <app>, deploy <app> cycle.
and you will hit http://java.net/jira/browse/JERSEY-660

3) The reason w/o the override seems to be that the JAXRS
Single RuntimeDelegate will point to the undeployed
WebappClassLoader. And By default GF31
WebappClassLoader will clear internal references.

If the above system property exists, then it should
be working fine. In fact as the system property
is global, it is not fine grain. It seems to me
that the request to have the overridePackages in
sun-web.xml would be Good as it is the same
trick as useBundledJsf or useMyFaces switch tries
to achieve.

So +1 for this.


Note:


WebappClassLoader seem to have a coding bug:
On GF311, Line 1886->1903, the "If statement" is
wrongly done – triggering wrong condition to
clear-reference. (It also does not check loadedByThisOrChild()).





[GLASSFISH-17416] Add configurable delay to servlet container shutdown process. Created: 12/Oct/11  Updated: 07/Mar/12

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

Type: New Feature Priority: Critical
Reporter: psprague Assignee: Shing Wai Chan
Resolution: Unresolved Votes: 2
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: craigwblake, psprague and Shing Wai Chan

 Description   

The version of tomcat GlassFish's servlet container is based on doesn't allow us to configure a delay before unloading the servlets. Since the threads are set as daemon threads the JVM simply stops them. This means when we try and do a graceful shutdown (asadmin stop-domain --force=false) in-flight requests are killed before they complete.

org.apache.catalina.core.StandardWrapper

public synchronized void unload() throws ServletException {

        // Nothing to do if we have never loaded the instance
        if (!singleThreadModel && (instance == null))
            return;
        unloading = true;

        // Loaf a while if the current instance is allocated
        // (possibly more than once if non-STM)
        if (countAllocated > 0) {
            int nRetries = 0;
            while ((nRetries < 21) && (countAllocated > 0)) {
                if ((nRetries % 10) == 0) {
                    if (log.isLoggable(Level.FINE)) {
                        log.fine(sm.getString("standardWrapper.waiting",
                                              countAllocated,
                                              instance.getClass().getName()));
                    }
                }
                try {
                    Thread.sleep(100);
                } catch (InterruptedException e) {
                    // Ignore
                }
                nRetries++;
            }
        }

    ...
}

In Tomcat 6 this method has been changed to support a configurable unload delay.

I would also like to point out that the documentation for asadmin stop-domain states that --force=false waits for threads to complete; while this appears to be true for the EJB container it is not true for the servlet container.

     --force

         Specifies whether the domain is forcibly stopped immedi-
         ately.

         Possible values are as follows:

         true
             The   domain   is   forcibly   stopped   immediately
             (default).

         false
             The subcommand waits  until  all  threads  that  are
             associated  with  the domain are exited before stop-
             ping the domain.

Thanks,
Paul



 Comments   
Comment by Shing Wai Chan [ 06/Jan/12 12:23 AM ]

Port Tomcat change: http://svn.apache.org/viewvc?view=revision&revision=345286

Sending web-core/src/main/java/org/apache/catalina/core/StandardContext.java
Sending web-core/src/main/java/org/apache/catalina/core/StandardWrapper.java
Transmitting file data ..
Committed revision 51916.

Comment by craigwblake [ 07/Mar/12 08:07 PM ]

Does the commit mean that this has been resolved? If so, what release can we expect this in?

Thanks!





[GLASSFISH-18222] [JRockit-intermittent] Observed 100% CPU usage & deploy taking > 5 minutes when running the Coherence HA tests Created: 19/Jan/12  Updated: 26/Mar/13

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

Type: Bug Priority: Critical
Reporter: varunrupela Assignee: Shing Wai Chan
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

File Attachments: Zip Archive coh-test-logs-1.zip     Zip Archive coh-test-logs-2.zip    
Issue Links:
Dependency
blocks GLASSFISH-18190 [JRockit] 100% CPU usage by 2 instanc... Closed
Tags: 312_qa 3_1_2-exclude 3_1_2-release-note-added 3_1_2-release-notes 3_1_2_review
Participants: Joe Di Pol, sherryshen, Shing Wai Chan, Tom Mueller and varunrupela

 Description   

GF Build: 18
Setup: 10 instance cluster (3 machines)
Platform: OEL6
JDK: JRockit
Has this test passed before: No. This is the first time that the combination OEL6 + JRockit + CoherenceTests is being tried out.

Parent Issue: 18160. Observed with build 17. 18222 is a result of further investigation.

Following observed when running Coherence tests (specifically while deploy of the coherence enabled application is on):

  • 100% CPU usage on some machines. "top" was run manually on all the machines involved in the setup if it was observed that one of the test's deploy method was taking unusually long.
  • This was not the case with all Coherence HA tests.
  • In some Coherence HA tests when the invocation of "asadmin deploy" was observed to be taking long (> 5 minutes), some instance logs were observed to contain thread dumps, while others have coherence related exceptions.
  • Tests that hit this issue ended up failing as instances did not seem to be available to service a http request for the application in question.
  • Different instances (1 or more) were observed to be utilizing 100% of the CPU during different tests.
  • In one of the tests a lot of GMS FAILURE_EVENTs have been observed while the deploy is on. Since 100% CPU usage has been observed during the deploy, it is quite likely that GMS alive messages (don't remember the exact terminology) were getting missed.

Logs from 2 different tests have been attached:
a) The first set is that of a test that showed a number of GMS FAILURE_EVENTs. This test happened to run before the test from which the second set of logs was collected.
b) The second set of logs shows thread dumps (see log of st-cluster/instance105) and exceptions (see log of st-cluster/instance106).
Note: The setup was able to continue the tests run after stalling for a bit. The second set of logs have been attached for a test after it had already stalled the tests run for about 2 hrs. A "kill -SIGABRT pid" was done on the instances that were taking 100% CPU (instanc101 & instance104 - second set of logs). Those kill steps seem to have generated thread dumps in the logs. Instances 101 and 104 got restarted after the kill -SIGABRT.

Client logs are in the ant.output file.

  • Deploy for the first set of logs begins at 3:58:33 AM
  • Deploy for the second set of logs begins at 4:10:52 AM

The coherence cache server's logs are also available - see coherence/<machine-name>/cache-server.log.

  • There was only a single storage enable cache server running. It formed the cluster with the storage-disabled GF cache nodes
  • The cache-server.log shows indications of failed members around the time of deploy for both the test cases.

NOTE: A core dump is also available. This was obtained before and for a different test run than the 2 sets of attached test logs. A "kill -SIGABRT pid" in this case had created a core dump rather than a thread dump in the instance logs.

  • Please send us an email and we will send its location.


 Comments   
Comment by Shing Wai Chan [ 20/Jan/12 12:09 AM ]

I notice the following coherence related messages in the instance log files.
Per discussion with James, this is very likely due to a resource or network issue.
So, this may be a result rather a cause of 100% cpu usage.

#|2012-01-19T04:06:40.072-0800|SEVERE|glassfish3.1.2|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=25;_ThreadName=Thread-2;|2012-01-19 04:06:40.070/1652.885 Oracle Coherence GE 3.7.0.0 <Error> (thread=Termination Thread, member=n/a): Full Thread Dump

[#|2012-01-19T04:06:40.294-0800|SEVERE|glassfish3.1.2|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=25;_ThreadName=Thread-2;|2012-01-19 04:06:40.293/1653.108 Oracle Coherence GE 3.7.0.0 <Error> (thread=http-thread-pool-24849(2), member=n/a): Error while starting cluster: com.tangosol.net.RequestTimeoutException: Timeout during service start: ServiceInfo(Id=0, Name=Cluster, Type=Cluster
MemberSet=ServiceMemberSet(
OldestMember=n/a
ActualMemberSet=MemberSet(Size=9, BitSetCount=2
Member(Id=1, Timestamp=2012-01-19 03:38:42.501, Address=10.133.185.54:8088, MachineId=13878, Location=site:us.oracle.com,machine:jed-asqe-24,process:8642, Role=CoherenceServer)
Member(Id=13, Timestamp=2012-01-19 03:58:48.887, Address=10.133.185.54:8090, MachineId=13878, Location=site:us.oracle.com,machine:jed-asqe-24,process:11176)
Member(Id=14, Timestamp=2012-01-19 03:58:50.606, Address=10.133.185.54:8092, MachineId=13878, Location=site:us.oracle.com,machine:jed-asqe-24,process:9028)
Member(Id=16, Timestamp=2012-01-19 03:59:12.252, Address=10.133.185.20:8090, MachineId=13844, Location=site:us.oracle.com,machine:jed-asqe-25,process:2421)
Member(Id=17, Timestamp=2012-01-19 03:59:19.923, Address=10.133.185.20:8094, MachineId=13844, Location=site:us.oracle.com,machine:jed-asqe-25,process:2408)
Member(Id=18, Timestamp=2012-01-19 04:00:47.551, Address=10.133.185.55:8088, MachineId=13879, Location=site:us.oracle.com,machine:jed-asqe-26,process:15657)
Member(Id=19, Timestamp=2012-01-19 04:01:02.177, Address=10.133.185.55:8090, MachineId=13879, Location=site:us.oracle.com,machine:jed-asqe-26,process:15651)
Member(Id=20, Timestamp=2012-01-19 04:01:04.076, Address=10.133.185.55:8092, MachineId=13879, Location=site:us.oracle.com,machine:jed-asqe-26,process:15690)
Member(Id=21, Timestamp=2012-01-19 04:01:18.349, Address=10.133.185.55:8094, MachineId=13879, Location=site:us.oracle.com,machine:jed-asqe-26,process:15658)
)
MemberId/ServiceVersion/ServiceJoined/MemberState
1/3.7/Thu Jan 19 03:38:42 PST 2012/JOINED,
13/3.7/Thu Jan 19 03:58:48 PST 2012/JOINED,
14/3.7/Thu Jan 19 03:58:50 PST 2012/JOINED,
16/3.7/Thu Jan 19 03:59:13 PST 2012/JOINED,
17/3.7/Thu Jan 19 03:59:19 PST 2012/JOINING,
18/3.7/Thu Jan 19 04:00:47 PST 2012/JOINED,
19/3.7/Thu Jan 19 04:01:02 PST 2012/JOINED,
20/3.7/Thu Jan 19 04:01:04 PST 2012/JOINED,
21/3.7/Thu Jan 19 04:01:18 PST 2012/JOINED
)
)
at com.tangosol.coherence.component.util.daemon.queueProcessor.service.Grid.onStartupTimeout(Grid.CDB:6)
at com.tangosol.coherence.component.util.daemon.queueProcessor.Service.start(Service.CDB:28)
at com.tangosol.coherence.component.util.daemon.queueProcessor.service.Grid.start(Grid.CDB:6)
at com.tangosol.coherence.component.net.Cluster.onStart(Cluster.CDB:61)
at com.tangosol.coherence.component.net.Cluster.start(Cluster.CDB:11)
at com.tangosol.coherence.component.util.SafeCluster.startCluster(SafeCluster.CDB:4)
at com.tangosol.coherence.component.util.SafeCluster.restartCluster(SafeCluster.CDB:10)
at com.tangosol.coherence.component.util.SafeCluster.ensureRunningCluster(SafeCluster.CDB:26)
at com.tangosol.coherence.component.util.SafeCluster.start(SafeCluster.CDB:2)
at com.tangosol.net.CacheFactory.ensureCluster(CacheFactory.java:427)
at com.tangosol.coherence.servlet.SessionHelper.checkEdition(SessionHelper.java:295)
at com.tangosol.coherence.servlet.SessionHelper.configure(SessionHelper.java:107)
at com.tangosol.coherence.servlet.SessionHelper.ensureSessionHelper(SessionHelper.java:482)
at com.tangosol.coherence.servlet.glassfish31.CoherenceWebSessionManager.init(CoherenceWebSessionManager.java:133)
at com.tangosol.coherence.servlet.glassfish31.CoherenceWebSessionManager.start(CoherenceWebSessionManager.java:577)
at org.apache.catalina.core.StandardContext.start(StandardContext.java:5370)
at com.sun.enterprise.web.WebModule.start(WebModule.java:503)
at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:917)
at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:901)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:735)
at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:2010)
at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:1661)
at com.sun.enterprise.web.WebApplication.start(WebApplication.java:109)
at org.glassfish.internal.data.EngineRef.start(EngineRef.java:130)
at org.glassfish.internal.data.ModuleInfo.start(ModuleInfo.java:269)
at org.glassfish.internal.data.ApplicationInfo.start(ApplicationInfo.java:302)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:461)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:240)
at org.glassfish.deployment.admin.InstanceDeployCommand.execute(InstanceDeployCommand.java:187)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$1.execute(CommandRunnerImpl.java:348)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:363)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1066)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1200(CommandRunnerImpl.java:95)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1295)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1260)
at com.sun.enterprise.v3.admin.AdminAdapter.doCommand(AdminAdapter.java:461)
at com.sun.enterprise.v3.admin.AdminAdapter.service(AdminAdapter.java:212)
at com.sun.grizzly.tcp.http11.GrizzlyAdapter.service(GrizzlyAdapter.java:179)
at com.sun.enterprise.v3.server.HK2Dispatcher.dispath(HK2Dispatcher.java:117)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:238)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:849)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:747)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1046)
at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:228)
at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:105)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:91)
at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79)
at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:56)
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:662)

Comment by Shing Wai Chan [ 24/Jan/12 01:50 AM ]

Does the same test pass in Oracle JDK?

Comment by varunrupela [ 24/Jan/12 10:23 AM ]

Yes. The coherence tests passed with Oracle JDK. The collected logs from that run do not contain any Thread Dumps and do not indicate delay in execution of DAS commands.

Will send a mail with the results link.

Comment by Shing Wai Chan [ 25/Jan/12 12:22 AM ]

Can you increase the memory for JRockit JVM? I would like to know whether the problems went away after the change.

Comment by varunrupela [ 25/Jan/12 09:27 AM ]

Is there an indication that memory has been an issue ?

Comment by sherryshen [ 30/Jan/12 07:20 PM ]

GF Build: 19
Setup: 10 instance cluster (3 machines)
Platform: OEL6
JDK: JRockit

The execution is hanging on coherence in run 10b,
jed-asqe-28 97% cpu
asqeopteron1,3 2.7% cpu

http://agni-1.us.oracle.com/JSPWiki/Wiki.jsp?page=V312HATest
Varun checked the the log on asqe-log, and found that
both the runs (10a and 10b) have Coherence related failures
due to issue 18222.

*****
[root@jed-asqe-28 coherence-http-runtime]# find . -name "ant.output" | xargs grep "30000"
./com.sun.dft.glassfish.http.failover.runtime.HttpFailoverRuntimeTest4/ant.output: [testng] INFO: The asadmin command - /space/gf-ha/glassfish3/bin/asadmin --user admin deploy --availabilityenabled=true --force=true --target st-cluster /space/gf-ha/agent-repository/glassfish-samples/clusterjsp.ear is taking longer than 300000 milliseconds.
./com.sun.dft.glassfish.http.failover.runtime.HttpFailoverRuntimeTest24/ant.output: [testng] INFO: The asadmin command - /space/gf-ha/glassfish3/bin/asadmin --user admin deploy --availabilityenabled=true --force=true --target st-cluster /space/gf-ha/agent-repository/web/runtime/SimpleSession.war is taking longer than 300000 milliseconds.
[root@jed-asqe-28 coherence-http-runtime]#
[root@jed-asqe-28 coherence-http-runtime]# find . -name "server.log" | xargs grep "Thread Dump"
./com.sun.dft.glassfish.http.failover.runtime.HttpFailoverRuntimeTest4/failoverRuntimeThroughLB/logs/st-cluster/instance101/logs/server.log:[#|2012-01-29T23:36:01.649-0800|SEVERE|glassfish3.1.2|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=24;_ThreadName=Thread-4;|2012-01-29 23:36:01.642/437.818 Oracle Coherence GE 3.7.0.0 <Error> (thread=Recovery Thread, member=n/a): Full Thread Dump
*****

http://agni-1.us.oracle.com/net/asqe-logs.us.oracle.com/export1/3.1.2/Results/build19/ha/oel6nm/all/coherence-http-runtime/com.sun.dft.glassfish.http.failover.runtime.HttpFailoverRuntimeTest4/failoverRuntimeThroughLB/logs/st-cluster/instance101/logs/server.log
http://agni-1.us.oracle.com/net/asqe-logs.us.oracle.com/export1/3.1.2/Results/build19/ha/oel6nm/all/coherence-http-runtime/com.sun.dft.glassfish.http.failover.runtime.HttpFailoverRuntimeTest4/failoverRuntimeThroughLB/logs/coherence/jed-asqe-28.us.oracle.com/cache-server.log

Comment by Shing Wai Chan [ 30/Jan/12 09:59 PM ]

In one of the thread dump, we notice the following:

Thread[Cluster|SERVICE_STARTING|STATE_ANNOUNCE|Member(Id=0, Timestamp=2012-01-29 23:30:08.126, Address=10.133.185.4:8090, MachineId=13828, Location=site:us.oracle.com,machine:jed-asqe-28,process:32266),5,Cluster]
com.tangosol.coherence.component.util.daemon.queueProcessor.packetProcessor.PacketPublisher.drainOverflow(PacketPublisher.CDB:0)
com.tangosol.coherence.component.util.daemon.queueProcessor.packetProcessor.PacketPublisher$InQueue.add(PacketPublisher.CDB:8)
com.tangosol.coherence.component.util.daemon.queueProcessor.service.Grid.dispatchMessage(Grid.CDB:62)
com.tangosol.coherence.component.util.daemon.queueProcessor.service.Grid.post(Grid.CDB:46)
com.tangosol.coherence.component.util.daemon.queueProcessor.service.Grid.send(Grid.CDB:1)
com.tangosol.coherence.component.util.daemon.queueProcessor.service.grid.ClusterService.onTimerAnnouncing(ClusterService.CDB:68)
com.tangosol.coherence.component.util.daemon.queueProcessor.service.grid.ClusterService.onNotify(ClusterService.CDB:11)
com.tangosol.coherence.component.util.Daemon.run(Daemon.CDB:42)
java.lang.Thread.run(Thread.java:662)

Comment by Joe Di Pol [ 01/Feb/12 08:06 PM ]

Current thinking is that this may be a problem with the Coherence code on JRockit. This will not be resolved in time for 3.1.2. We should document this in the release notes as a known issue with JRockit. The work-around is to use the normal Oracle JDK.

Comment by Shing Wai Chan [ 02/Feb/12 11:43 PM ]

If you see the 100% cpu usage again, then please collect the following information. This will help coherence team to debug this further:

  • If this is reproducible, can we take thread dumps every few seconds?
  • Do we know which processes are using up CPU? (using top the pid and then identify what process that pid is)
  • Do we know if this is in user land or kernel? (from top)
Comment by Shing Wai Chan [ 06/Feb/12 09:59 PM ]

An issue is filed on Coherence as follows:
13689509: 100% CPU USAGE IN DEPLOYING COHERENCE 3.7.1 WEB APPLICATION WITH JROCKIT.

Comment by varunrupela [ 07/Feb/12 01:29 PM ]

We are Observing similar thread dumps and GMS related failures in the GF instance server logs with coherence 3.7.1 as well. Will work on collecting the requested frequent thread dumps and then upload the logs.

Comment by Tom Mueller [ 07/Mar/12 02:47 PM ]

Bulk update to set Fix Version to "not determined" for issues that had it set to a version that has already been released.





[GLASSFISH-20884] Does not full fit the javax.servlet.ServletContainerInitializer's functions Created: 07/Nov/13  Updated: 07/Nov/13

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

Type: Bug Priority: Critical
Reporter: chafer Assignee: Shing Wai Chan
Resolution: Unresolved Votes: 0
Remaining Estimate: 1 hour
Time Spent: Not Specified
Original Estimate: 1 hour

Tags:
Participants: chafer and Shing Wai Chan

 Description   

The interface javax.servlet.ServletContainerInitializer has declared that "Implementations of this interface may be annotated with HandlesTypes, in order to receive (at their onStartup(java.util.Set>, javax.servlet.ServletContext) method) the Set of application classes that implement, extend, or have been annotated with the class types specified by the annotation. "
While, when I define an interface A as IA,an interface B as IB which extends IA,and a class C implements IB, the HandlesTypes annotation declared to receive IA classes, the onStartup method does receive the class C.






[GLASSFISH-21007] HTTP Upgrade handler init called twice when access log is turned on Created: 17/Mar/14  Updated: 19/Mar/14

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

Type: Bug Priority: Critical
Reporter: mreichman Assignee: Shing Wai Chan
Resolution: Unresolved Votes: 1
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Glassfish 4.0.1b4 Promoted, Windows 7 x64, JDK 1.7.0_51


Issue Links:
Dependency
blocks TYRUS-306 java.lang.IllegalStateException: Alre... Open
Tags:
Participants: mreichman and Shing Wai Chan

 Description   

When HTTP access logging is turned on, the init method of HttpUpgradeHandler implementations is called twice at upgrade-time. I'd previously filed TYRUS-306 for this, the necessary information, test components to reproduce are in that ticket. In the Tyrus case, the effect is that two websockets are created for one request which creates management difficulty and potential leaks.






[GLASSFISH-3813] Deployment of web app directories without editing domain.xml Created: 26/Oct/07  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: web_container
Affects Version/s: 9.1pe
Fix Version/s: not determined

Type: Improvement Priority: Major
Reporter: jess_holle Assignee: Shing Wai Chan
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 3,813
Tags:
Participants: Hong Zhang, jess_holle, Shing Wai Chan and Tom Mueller

 Description   

Tomcat has now long had the ability to deploy deploy web application directories
without editing server.xml. [By deploy I don't mean copy the web app files, but
rather just enable the web app in the servlet engine using the existing
directory.] Similarly it would be very useful for Glassfish to support this
ability without editing domain.xml.

In Tomcat this is done through a context.xml file just one like that which
Glassfish supports/uses from docroot/META-INF except:

  • The file is named webAppName.xml [only required in later Tomcats]
  • The <context> element must have path and docBase attributes to specify the
    context path and docbase directory of the web app, respectively.

This file is just placed in a specified location in Tomcat and the web app is
loaded automatically shortly thereafter.

This capability has a number of advantages.

First, it is very easy to create this simple XML file in a specified location as
compared to properly inserting into domain.xml.

More importantly, however, it allows one to easily deploy the same web app
directory multiple times, i.e. under different context paths and with different
deployment parameters. For instance, I have a simple web app that is designed
to address a database instance. In Tomcat I create multiple context.xml files
with unique context paths and unique DBCP parameters specifying various database
instances. In Glassfish I currently cannot do this as context.xml always
resides in docroot/META-INF, so I can only have one per docbase.



 Comments   
Comment by Hong Zhang [ 06/Nov/07 06:36 PM ]

Just want to let you know similar things were planned/implemented for v3. For v3
developer profile, the application will not be registered in the central
domain.xml and there will be a separate property file for each deployed
application.

Comment by Hong Zhang [ 08/Nov/07 08:10 AM ]

look in v3.

Comment by Hong Zhang [ 21/Jan/11 10:38 AM ]

I think we already have partial support of context.xml in glassfish, but not sure if this scenario is part of it. Assign to web team to follow up.

Comment by Tom Mueller [ 06/Mar/12 09:56 PM ]

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





[GLASSFISH-4007] support valves as first class object: asadmin command, configuration Created: 16/Jan/08  Updated: 21/Jan/11

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

Type: Improvement Priority: Major
Reporter: writtmeyer Assignee: Shing Wai Chan
Resolution: Unresolved Votes: 2
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Linux


Issue Links:
Duplicate
is duplicated by GLASSFISH-4006 Add more flexible configuration possi... Resolved
Issuezilla Id: 4,007
Tags:
Participants: janey, Shing Wai Chan, Tom Mueller and writtmeyer

 Description   

Right now it is possible to add valves to visual-server elements as well as to
web-module elements using properties. E.g.:
asadmin set
server.http-service.virtual-server.server.property.valve_1=org.apache.catalina.valves.RequestDumperValve

But it is not possible to configure them appropriately - especially to set
properties of the valves themselves.

For the current situation see Jeanfrancois Arcand's blog:
http://weblogs.java.net/blog/jfarcand/archive/2006/09/extending_glass.html

It is highly desirable to be able to do s.th. more Valve-specific - to get an
explicit command line command for valves.

A possible syntax could be s.th. like the following:

asadmin create-valve --class x.y.SomeValve --parent-type
(virtual-server|web-module) --parent /parent/ --target /target/ /valve_name/

--class is obviously the class of the Valve to create.
--parent-type would be either virtual-server or web-module since these are the
only places a Valve can be added to (see Jeanfrancois' post above).
--parent would denote the id for virtual-servers or the name for web-modules
--target would be domain, server or cluster_name

For more about this see the thread on the developer mailing list starting with
the following post:
https://glassfish.dev.java.net/servlets/ReadMsg?list=dev&msgNo=5244



 Comments   
Comment by writtmeyer [ 16/Jan/08 01:45 PM ]

I've selected the wrong issue type for this RFE at the beginning. Sorry!

Comment by writtmeyer [ 16/Jan/08 11:27 PM ]

I've posted a related issue for necessary changes in the domain.xml:

https://glassfish.dev.java.net/issues/show_bug.cgi?id=4006

Comment by janey [ 26/Jan/10 05:59 PM ]

reassign to kedar

Comment by writtmeyer [ 27/Jan/10 01:13 PM ]

I am not sure whether this is relevant for asadmin as well, but Valve and
ValveNode have been enhanced in working on this RFE:

https://glassfish.dev.java.net/issues/show_bug.cgi?id=7177

At least parts of these enhancements might help with this issue.

Comment by Tom Mueller [ 21/Jan/11 10:19 AM ]

The blog entry referred to in the description is now here:
http://jfarcand.wordpress.com/2006/09/08/extending-glassfishs-webcontainer/

Please evaluate this issue to see if it should be closed, included in 3.2, or deferred to a future release.

Comment by Tom Mueller [ 21/Jan/11 11:16 AM ]

Issue 4006 talks about adding configuration data in the domain.xml file for valves. I'm combined that one into this one and closing issue 4006 as a duplicate.

Please consider the implementation of valve-specific data in the domain.xml along with commands for managing valves when evaluation this bug.





[GLASSFISH-16049] implement CORS support Created: 18/Feb/11  Updated: 18/Oct/12

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

Type: Improvement Priority: Major
Reporter: Justin Lee Assignee: Shing Wai Chan
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: ee7ri_cleanup_deferred
Participants: Justin Lee, Shing Wai Chan and Tom Mueller

 Description   

I was talking to a community member and he asked if we had any plans to implement CORS on the server side. All browsers including IE8, android and iOS already support CORS but it needs support on the server side.

http://www.w3.org/TR/cors/



 Comments   
Comment by Tom Mueller [ 18/Oct/12 09:22 PM ]

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 issue 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-16871] Refactoring DefaultServlet.serveResource Created: 16/Jun/11  Updated: 01/Dec/11

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

Type: Improvement Priority: Major
Reporter: Eirik Bjørsnøs Assignee: Shing Wai Chan
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

File Attachments: Text File GLASSFISH-16871-lookup-validation.patch    
Tags:
Participants: Eirik Bjørsnøs and Shing Wai Chan

 Description   

In trying to add a features to DefaultServlet.serveResource I've found the method in it's current form extremely hard to work with.

I'm counting 346 lines, 46 branches (some nested 7 levels deep), 9 return/exception points and mixed concerns including multiple resource location strategies (war file, META-INF/resources, alternate doc base..), directory listing / redirection handling, resource caching, error reporting, range handling, content type resolution and finally several seemingly different strategies for actually serving content.

Before adding any new features, this method needs some refactoring.

What to do? I mainly see two things:

1) We need to separating the concerns of looking up the resource, validating and handling errors for the resource and actually serving the resource.
2) The resource is served in different ways depending on content and use of ranges. The same "type" checks are done repeatedly using if statements.This could probably be split into one class per strategy using basic polymorphism.



 Comments   
Comment by Eirik Bjørsnøs [ 16/Jun/11 05:37 AM ]

The attached patch (GLASSFISH-16871-lookup-validation.patch) is an attempt at refactoring DefaultServlet.serveResource by:

  • Separating the concern of locating a CacheEntry into its own method lookupCacheEntry
  • Separating the validation and error handling into its own method hasValidationErrors

To do this, I had to do a couple of tweaks (in addtion to extract the methods):

  • The redirect if a directory is requested without a "/" in case of resources inside META-INF/lib/ jars was moved to the error handling method.
  • The write to the proxyHandler local variable when a META-INF/lib/ directory resource is requested has been replaced with setting the cacheEntry.context to be the FileDirContext. The creation of a ProxyDirContext wrapper around the FileContext was moved to the call of the render() method (which handles directory listings)
  • The check and handling for the situation where directory listings are suppressed was moved into the hasValidationErrors method.

This patch does not change the actual serving of the resource.

Comment by Eirik Bjørsnøs [ 23/Jun/11 06:59 AM ]

I also found the whole mixing of resource lookup and resource caching to be confusing.

The use of CacheEntry seems to indicate that the resource or at least its representation is cached in some way. However, when debugging I noticed that ProxyDirContext's cache field is only optional. By default, there seems to be no cache. Still, a CacheEntry is created and returned.

When implementing support for META-INF/resources lookups, the lookup results in an instance of the same CacheEntry class, without there ever being caching involved in the lookup. This really confused me.

A refactoring of this method should consider separating the lookup of a resource from the caching. That way, resources could be cached regardless of where they're looked up from (given that the source is cacheable, that is)





[GLASSFISH-16901] tcp-no-delay attribute in Http is not working Created: 23/Jun/11  Updated: 26/Mar/13

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

Type: Bug Priority: Major
Reporter: Shing Wai Chan Assignee: Shing Wai Chan
Resolution: Unresolved Votes: 0
Σ Remaining Estimate: Not Specified Remaining Estimate: Not Specified
Σ Time Spent: Not Specified Time Spent: Not Specified
Σ Original Estimate: Not Specified Original Estimate: Not Specified

Sub-Tasks:
Key
Summary
Type
Status
Assignee
GLASSFISH-16902 [UB]Need to document that tcp-no-dela... Sub-task Resolved Rebecca Parks  
Tags: 3_1_1-next 3_1_1-scrubbed 3_1_2-exclude
Participants: Shing Wai Chan

 Description   

The tcp-no-delay attribute in Http is not processed.
Instead the tcpNoDelay property in http-service is processed.
Note that the tcpNoDelay property is not documented.






[GLASSFISH-17131] JSessionID from url dropped in case of http/ https redirect cycle Created: 29/Jul/11  Updated: 26/Mar/13

Status: Reopened
Project: glassfish
Component/s: web_container
Affects Version/s: 3.1
Fix Version/s: 4.0.1

Type: Bug Priority: Major
Reporter: KBachl Assignee: Shing Wai Chan
Resolution: Unresolved Votes: 1
Σ Remaining Estimate: Not Specified Remaining Estimate: Not Specified
Σ Time Spent: Not Specified Time Spent: Not Specified
Σ Original Estimate: Not Specified Original Estimate: Not Specified
Environment:

All; Happens at least on Glassfish 3.1.1 and 3.1;
Tested with wicket 1.4.17, but JSessionID handling is done by glassfish container;


File Attachments: Zip Archive GlassfishSessionFail.zip     XML File web.xml    
Sub-Tasks:
Key
Summary
Type
Status
Assignee
GLASSFISH-17191 jsessionId is lost while redirecting ... Sub-task Closed Shing Wai Chan  
Tags: 3_1_2-exclude
Participants: calocoj, KBachl and Shing Wai Chan

 Description   

Example trace:

L Status Type File Size Transfer Size
0 http://loalhost/index
1 https://localhost/login 200 doc 2.5kB 1.2kB
2 https://localhost/login/wicket:interface/:0:login::IFormSubmitListener::;jsessionid=554a68e4c0acb1a7caf7588a6c0c 302 redirect 0 0
3 https://localhost/;jsessionid=554a68e4c0acb1a7caf7588a6c0c 302 redirect 0 0
4 https://localhost/index;jsessionid=554a68e4c0acb1a7caf7588a6c0c 302 redirect 0 0
5 http://localhost/index 302 redirect 0 1.9kB
6 http://localhost/login;jsessionid=554b893eee44aa121d9cc42d6e9c 302 redirect 0 0
7 https://localhost/resources/login.SecureLoginPage/loginpage.css 200 (cache) css 3.4kB 1kB

it can be seen here that between 4 and 5 the session got lost; The container didn't rewrite the URL 5 to inlcude the jsession id. This makes it impossible to have a secure only page login. As soon as the index part was changed to SSL access all worked fine.



 Comments   
Comment by Shing Wai Chan [ 29/Jul/11 05:12 PM ]

Can you attach a test case? I would like to take a look at that, especially web.xml.

Comment by KBachl [ 30/Jul/11 08:10 AM ]

Hello,

its kinda related to http://java.net/jira/browse/GLASSFISH-16301 as well as http://java.net/jira/browse/GLASSFISH-13129 now only in the case a http/ https redirect cycle also happens. I'll try to get up a test case in next days, however, I also observed the behaviour that URLs that are not generated are not taken care by glassfish.

E.g. say you have a CMS. You send out the stream to the client. The response is not checked by glassfish for links and added the JsessionId there making it impossible to feed on static resources while cookies are not enabled in a protected environment. This is different to the behaviour of other containers like jetty or tomcat. IMHO the jsessionId thing is kinda broken in case one needs protocol changes and or static feed content.

Comment by KBachl [ 30/Jul/11 08:24 AM ]

enclosed is an example web.xml from a live project that fails with that bug; As you can see there is nothing special in web.xml; Please not that some names have been obscured but not errors occur during deployment/ runtime and all works as long as cookies are enabled;

Comment by Shing Wai Chan [ 01/Aug/11 07:43 PM ]

The attached web.xml does not have any security constraint defined there. Are you using JavaEE security there?
What is the url of triggering the creation of HTTP session?

Can you attach a unit test case for that?

Comment by KBachl [ 03/Aug/11 11:06 AM ]

Apologies for the late answer. Enclosed is a Netbeans-Maven simple project that has 2 wicket pages that loose JSessionId in HTTP/HTTPS redirect cycle. This is IMHO the most easy setup

If you have any questions please do not hesitate to contact me.

Comment by Shing Wai Chan [ 03/Aug/11 09:27 PM ]

In the original description, the session is created through https and then switch to http.
In the attached test case, when I click on the "Back to HomePageSSL", the session is created through http and then call encoding url starting with https.

In your scenario, can you clarify when is session created? through http or through https?

Comment by KBachl [ 04/Aug/11 08:00 AM ]

Sorry for beeing unspecific. Wicket will allways create a session in HTTP. Even if you are in https mode, it will issue a 302 to http, create session there, and then go to https via 302. Reason is that HTTPS cookies else won't be allowed to HTTP by the browsers. The "Back to xxx" btw. doesn't mean anything, it was just copy'n'pasted as only the link is dynamically done. In either case both pages have a stateful component on them to trigger session, meaning if you want to test SSL open this page in a cookie disbaled browser first and you see the https to http cycle failing.

However, in our case, with jsessionID (= cookies off at browser) it won't matter. In either 302 the session will be lost. Meaning http -> https will loose and vice versa (https -> http); The log I did on the top was from a live app on a 3.1.1 glassfish where I "fixed" the domainname.

Comment by Shing Wai Chan [ 09/Aug/11 01:43 AM ]

fix in trunk:
Sending src/main/java/org/apache/catalina/connector/Response.java
Transmitting file data .
Committed revision 48656.

fix in 3.1.2:
Sending web-core/src/main/java/org/apache/catalina/connector/Response.java
Transmitting file data .
Committed revision 48657.

Comment by Shing Wai Chan [ 26/Aug/11 02:05 AM ]

There is an issue with the previous fix.
When the port numbers are different, it may be a different server instance or even not a GlassFish server. In that case, one should append the jsessionid.

revert the previous fix in trunk:
Sending web-core/src/main/java/org/apache/catalina/connector/Response.java
Transmitting file data .
Committed revision 49051.

revert the previous fix in 3.1.2:
Sending web-core/src/main/java/org/apache/catalina/connector/Response.java
Transmitting file data .
Committed revision 49052.

Comment by Shing Wai Chan [ 26/Aug/11 02:13 AM ]

Change priority from Blocker to Major as this will work for cookies enabled browsers.

I have checked that other servers, like Tomcat, also behave the same.

Comment by KBachl [ 27/Aug/11 08:40 AM ]

Shing Wai, I request to put level to Blocker again.
We're in EU (European Union) and there is currently a legal directive introduction taking place (it already took place in e.g. Great Britain). The directive forbids services to use cookies. Meaning if the issue is not resolved quickly we are forced to drop our use of glassfish legally. The only reason why we still can use it is that the directive is not yet active in Germany, but will be introduced shortly.
We need our applications to work the same way as if cookies are enabled or disabled so we simply can turn them off when we are asked by our lawyers. For more details about EU wide needs see here: http://www.aboutcookies.org/Default.aspx?page=3

Comment by Shing Wai Chan [ 28/Aug/11 03:10 AM ]

Blocker issue means no workaround. And this is not the case.

According to the info of http://www.aboutcookies.org/Default.aspx?page=3, it does not prohibit the use of cookies. For example, one can use cookies to remember the contents of a user's shopping cart .

As I mentioned in previous comment, there may involve an internal interface change. If that is the case, then I can only checkin the fix into the trunk, not 3.1.x.

Since you know the http and https port in your environment (not a general environment), one can write an utility method to do the encoding. This may help you to resolve the issue in the specific environment.

Comment by Shing Wai Chan [ 30/Aug/11 08:41 PM ]

Per discussion with Ron, one may like to consider the case of load balancer, too. I have checked that some of the required information is not on the front web server side, not on the GlassFish side.

Comment by KBachl [ 01/Sep/11 09:29 AM ]

Hi Shing Wai,

thank you for staying on this issue. Can you give me please a better hint on how to workaround this?

PS: regarding the legal situation: the text on aboutcookies was just to illustrate you the problem, its not the real law. In fact, Britains authorities are now forcing webmaster to specifically ask users via pop-up before using any cookies. The german law, thats introduced soon, even states "cookies may not be used when other methods are technically available". All laws and regulations share that they are not differing between cookies origin and dont posess a bit of technical background - meaning you need to see this from a pure lawyer view without technical aspects. For details see http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=CELEX:32009L0136:EN:NOT and http://www.ico.gov.uk/

Comment by Shing Wai Chan [ 14/Dec/11 06:51 PM ]

I cannot open the above two urls.

In this case, you may need to write an utility to explicit append the jsessionid if necessary.

Comment by KBachl [ 14/Dec/11 09:08 PM ]

Urls open from here - no idea why you can't access them. How could one attach the jsession ID to all links on a page? Is there any way to parse the whole document right before it goes back to the browser?

Beside that - you know that the current behaviour in glassfish is the opposite how it works on the other containers like JBoss, Jetty, Tomcat etc.?

Comment by Shing Wai Chan [ 14/Dec/11 09:50 PM ]

First, you may like to turn on url tracking mode in web.xml
<session-config>
<tracking-mode>URL</tracking-mode>
</session-config>
Second, whenever you do a switch in protoocl, then you need some special coding to append jsessionid. (The attached example uses wicket. You may like to look into that.)

I can access both the url now.
From http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=CELEX:32009L0136:EN:NOT ,
I notice the following:
"(66) Third parties may wish to store information on the equipment of a user, or gain access to information already stored, for a number of purposes, ranging from the legitimate (such as certain types of cookies) to those involving unwarranted intrusion into the private sphere (such as spyware or viruses). It is therefore of paramount importance that users be provided with clear and comprehensive information when engaging in any activity which could result in such storage or gaining of access. ..."

So, this does not forbid the use of cookies.

When I access http://www.ico.gov.uk/, I notice that it has a box at the top of the page to ask you to accept the cookies and continue.

Let me clarify the behavior. For switching from https to http, then one should not attend jsessionid in for security reason. The question is for switching from http to https. In my previous investigation, I change the behavior of HttpServletRequest#encodeRedirectURL and #encodeURL.
It is not working for general case with load balancer.
In your scenario, you may have a simpler setup and hence you can install a filter with ServletRequestWrapper overriding the above two methods. (You should know the http, https mapping in your case.)

I have confirmed that Tomcat and GlassFish has the same behaviors for the above two APIs.

Comment by KBachl [ 16/Dec/11 03:15 PM ]

Hi,

apologise for late answer. The EUR-Lex document is not the actual law, but the new EU wide legislative basement, meaning that this will be put into 27 different laws for each of the 27 EU countries. Therefore the way what "may" or "may not" be allowed can't be forseen all over (it's a quite complex legal thing) - meaning you read only the document that needs to be cared about by the creators of the local laws, not the resulting law itself.

However, I think I can make a workaround by letting the user stay in SSL mode once he got into it, so there would be no dump.

Regarding the Tomcat/ Glassfish: if I download the demo app, deploy it to tomcat 6 and glassfish 3.1 i get following behaviour:

Tomcat: call HTTP-> jsession appended -> go to HTTPS -> session stays same -> go back to HTTP -> still same session
Glassfish: call HTTP -> jsession sppended -> go to HTTPS -> session stays same -> go back to HTTP (now link wihtout jsessionId) -> get new session, old one is dropped

Comment by calocoj [ 11/Sep/12 06:44 AM ]

It is possible to know whether this incident will be patched soon or scheduled for a next release? I am using apache as load balancer and upon entering without http authentication page redirects me to https but then changes the JSESSIONID to a new node. I appreciate your help.
I'm working with GlassFish Server Open Source Edition 3.1.2.2 (build 5)

Comment by Shing Wai Chan [ 26/Mar/13 09:05 PM ]

I have tried 3.1.2 FCS build with the attached GlassfishSessionFail-1.0.war application.

1. access localhost:8080/GlassfishSessionFail-1.0
2. click on the url "Back to HomePageSSL"
3. click on the url "Back to HomePage"

In the above three cases, the session id is the same.
In (2) and (3) above, I do not see the appended jsessionid in url.

But according to KBach's comment above, we see jsessionid in the url when it is switching from http to https.

Is the war attached illustrates the test case?
Is this resolved in 3.1.2 FCS?





[GLASSFISH-17323] Unsupported deployment descriptors element library-name in weblogic.xml Created: 20/Sep/11  Updated: 26/Mar/13

Status: Open
Project: glassfish
Component/s: web_container
Affects Version/s: 4.0
Fix Version/s: future release

Type: Bug Priority: Major
Reporter: sonialiu Assignee: Shing Wai Chan
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

File Attachments: File gradeschool.war    
Tags: 3_1_2-exclude
Participants: Shing Wai Chan and sonialiu

 Description   

*report the bug for backward compatibility requirement for future BG product*

I tried to deploy the attached Weblogic QA test application to Glassfish v3.1.1, the deployment was successful. However, in the server.log it displayed the following messages:

"[#|2011-09-20T10:25:45.812-0700|INFO|glassfish3.1.1|org.glassfish.admingui|_Thre
adID=19;_ThreadName=Thread-2;|uploadFileName=gradeschool.war|#]

[#|2011-09-20T10:25:45.968-0700|WARNING|glassfish3.1.1|javax.enterprise.system.t
ools.deployment.org.glassfish.deployment.common|_ThreadID=17;_ThreadName=Thread-
2;|DPL8007: Unsupported deployment descriptors element library-name value playgr
ound|#]

[#|2011-09-20T10:25:45.968-0700|WARNING|glassfish3.1.1|javax.enterprise.system.t
ools.deployment.org.glassfish.deployment.common|_ThreadID=17;_ThreadName=Thread-
2;|DPL8007: Unsupported deployment descriptors element library-name value cafete
ria|#]"

The following is the snapshot of the weblogic.xml of the test app.
<weblogic-web-app>

<library-ref>
<library-name>playground</library-name>
</library-ref>

<library-ref>
<library-name>cafeteria</library-name>
</library-ref>

</weblogic-web-app>

We might have to make sure we will support the above elements in weblogic.xml in the future BG release. Thanks.



 Comments   
Comment by sonialiu [ 20/Sep/11 09:58 PM ]

add fix version 4.0

Comment by sonialiu [ 21/Sep/11 05:03 PM ]

changed affects version to 4.0





[GLASSFISH-17787] provide an asadmin command that secures a deployed Java EE archive Created: 21/Nov/11  Updated: 01/Feb/13

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

Type: Improvement Priority: Major
Reporter: vince kraemer Assignee: Shing Wai Chan
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: Hong Zhang, Shing Wai Chan and vince kraemer

 Description   

Currently, it is possible to make an artifact that doesn't require authentication and then change it to require authentication... It is not even a hard thing to do... but it sure is tedious.

And it requires a developer/deployer to alter the archive... which opens up the possibility that they will make a mistake as they go through the process of doing the conversion.

It would be nice to have a single command that would alter a deployed artifact to use authentication, without forcing the user to explode their app, edit files, rebuild the archive and redeploy.

The command may do all those things (behind the scenes).



 Comments   
Comment by Hong Zhang [ 10/Oct/12 02:06 AM ]

Reassign to web team to see if it makes sense to implement something like this.

Comment by Shing Wai Chan [ 01/Feb/13 05:52 PM ]

In order to a secure a web application with authentication, one need to have the following:
a) auth-method (associated login pages, etc if necessary)
b) realm name
c) security-constraint
d) security-role mapping

We have default for a) and b) in GlassFish.
For c) and d), we need to wait for http://java.net/jira/browse/SERVLET_SPEC-34, where one can define a constraint for a valid authenticated users without roles.

Comment by vince kraemer [ 01/Feb/13 08:49 PM ]

one thing to note... I guess this would apply to any Java EE artifact that is deployed and has the ability to be secured... it does not have to be just for web apps

Comment by vince kraemer [ 01/Feb/13 08:52 PM ]

extended the goal of the improvement to all deployable, securable Java EE artifacts.





[GLASSFISH-19113] [PERF] Forwarded JSP makes multiple calls to InvocationManagerImpl Created: 28/Sep/12  Updated: 26/Mar/13

Status: Open
Project: glassfish
Component/s: web_container
Affects Version/s: 4.0_b55
Fix Version/s: 4.0.1

Type: Bug Priority: Major
Reporter: Scott Oaks Assignee: Shing Wai Chan
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: PSRBUG
Participants: Scott Oaks and Shing Wai Chan

 Description   

When a simple servlet forwards a response to a JSP, there are multiple calls made to InvocationManagerImpl.preInvoke and postInvoke.

In the case of preInvoke, the first of these calls comes from ApplicationDispatcher.invoke -> ApplicationDispatcher.doInvoke -> InstanceSupport.fireInstanceEvent -> J2EEInstanceListener.instanceEvent. In that case the instance event is the InstanceEvent.EventType.BEFORE_DISPATCH_EVENT (line 792 of ApplicationDispatcher). The second call comes from line 821, which calls StandardWrapper.service -> InstanceSupport.fireInstanceEvent. In that case the instance event is InstanceEvent.EventType.BEFORE_SERVICE_EVENT. So within J2EEInstanceListener, the events are different. But that information isn't passed into the InvocationManagerImpl.preInvoke method, which appears just to be doing duplicate work. Unless the event is somehow passed to the lower methods in a way I'm just missing.

Can we figure out a way to eliminate the duplicate processing?

This is doubtless a long-standing issue that we've just discovered, in part because of a large regression in the performance of InvocationManagerImpl.preInvoke and postInvoke. But even if we fix the invocation manager performance, we should eliminate this duplicate call.






[GLASSFISH-19283] CLONE -Managing custom error pages for different http errors Created: 03/Nov/12  Updated: 03/Nov/12

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

Type: New Feature Priority: Major
Reporter: Wasomumba Assignee: Shing Wai Chan
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Macintosh


Issuezilla Id: 13,297
Tags:
Participants: Shing Wai Chan and Wasomumba

 Description   

Hi,

recently I was trying to to find a way to changes the default glassfish error
pages, such as

  • 404
  • 500
  • ...

I prefered to do this somehow globally instead of only webapp based (web.xml).
The only way to do this is in the domain.xml file. An example could be:

<virtual-server hosts="${com.sun.aas.hostName}"
http-listeners="http-listener-1,http-listener-2" id="server"
log-file="${com.sun.aas.instanceRoot}/logs/server.log" state="on">
<property name="docroot" value="${com.sun.aas.instanceRoot}/docroot"/>
<property name="accesslog" value="${com.sun.aas.instanceRoot}/logs/access"/>
<property name="sso-enabled" value="false"/>
<property name="send-error_1" value="path=../errors/404.html
reason=Resource_not_found code=404"/>
</virtual-server>

I am ok with this part, but unfortunately one has to maintain each of the http
errors 1 by 1. Imagine you want to catch all of the 400 and 500 error codes -
that would cause you a lot of work...

My idea would be to offer something like this:

<property name="send-error_1" value="path=../errors/4x.html
reason=Resource_not_found code=4*"/>

or

<property name="send-error_1" value="path=../errors/5x.html
reason=Resource_not_found code=5*"/>

or even

<property name="send-error_1" value="path=../errors/x.html
reason=Resource_not_found code=*"/>

And in the file you have specified you could either add some "static" contetn
like "An Error has occured". Of course you could even offer some kind of feature
that allows you to place plcaholders in that files to be filled with the error
code itself. The advantage would be that one only would need to specify one
error file and the content of that file would be dynamic.



 Comments   
Comment by Wasomumba [ 03/Nov/12 08:54 AM ]

I'm really looking for such a feature too.





[GLASSFISH-20202] compilation warning about authorization from web cli Created: 05/Apr/13  Updated: 05/Apr/13

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

Type: Bug Priority: Major
Reporter: Shing Wai Chan Assignee: Shing Wai Chan
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: Shing Wai Chan

 Description   

I notice the following while complying the web/admin and web-gui-plugin-common.

[WARNING] Following command classes neither provide nor inherit authorization: [org.glassfish.web.admin.cli.CreateHttp, org.glassfish.web.admin.cli.CreateHttpListener, org.glassfish.web.admin.cli.CreateHttpRedirect, org.glassfish.web.admin.cli.CreateNetworkListener, org.glassfish.web.admin.cli.CreateProtocol, org.glassfish.web.admin.cli.CreateProtocolFilter, org.glassfish.web.admin.cli.CreateProtocolFinder, org.glassfish.web.admin.cli.CreateTransport, org.glassfish.web.admin.cli.CreateVirtualServer, org.glassfish.web.admin.cli.DeleteHttp, org.glassfish.web.admin.cli.DeleteHttpListener, org.glassfish.web.admin.cli.DeleteHttpRedirect, org.glassfish.web.admin.cli.DeleteNetworkListener, org.glassfish.web.admin.cli.DeleteProtocol, org.glassfish.web.admin.cli.DeleteProtocolFilter, org.glassfish.web.admin.cli.DeleteProtocolFinder, org.glassfish.web.admin.cli.DeleteTransport, org.glassfish.web.admin.cli.DeleteVirtualServer, org.glassfish.web.admin.cli.ListHttpListeners, org.glassfish.web.admin.cli.ListNetworkListeners, org.glassfish.web.admin.cli.ListProtocolFilters, org.glassfish.web.admin.cli.ListProtocolFinders, org.glassfish.web.admin.cli.ListProtocols, org.glassfish.web.admin.cli.ListTransports, org.glassfish.web.admin.cli.ListVirtualServers]

[WARNING] Following command classes neither provide nor inherit authorization: [org.glassfish.web.plugin.common.ListWebContextParamCommand, org.glassfish.web.plugin.common.ListWebEnvEntryCommand, org.glassfish.web.plugin.common.SetWebContextParamCommand, org.glassfish.web.plugin.common.SetWebEnvEntryCommand, org.glassfish.web.plugin.common.UnsetWebContextParamCommand, org.glassfish.web.plugin.common.UnsetWebEnvEntryCommand]

Per discussion with Tom, this is related to role based access control feature.






[GLASSFISH-20622] NullPointerException is throwed by OutputBuffer.java Created: 11/Jun/13  Updated: 08/Jul/13

Status: Open
Project: glassfish
Component/s: web_container
Affects Version/s: v2.1.1
Fix Version/s: None

Type: Bug Priority: Major
Reporter: kyoLiu Assignee: Shing Wai Chan
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Solaris 10


Tags: NullPointerException web-container
Participants: kyoLiu, Shing Wai Chan and wizard.liyd

 Description   

When a web application is running on glassfish, below exception is throwed unexpectedly.
java.lang.NullPointerException
at org.apache.coyote.tomcat5.OutputBuffer.addSessionCookieWithJvmRoute(OutputBuffer.java:689)
at org.apache.coyote.tomcat5.OutputBuffer.doFlush(OutputBuffer.java:370)
at org.apache.coyote.tomcat5.OutputBuffer.close(OutputBuffer.java:336)
at org.apache.coyote.tomcat5.CoyoteResponse.finishResponse(CoyoteResponse.java:594)
at org.apache.coyote.tomcat5.CoyoteAdapter.afterService(CoyoteAdapter.java:354)
at com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.postResponse(DefaultProcessorTask.java:625)
at com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.doProcess(DefaultProcessorTask.java:612)
at com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.process(DefaultProcessorTask.java:889)
at com.sun.enterprise.web.connector.grizzly.DefaultReadTask.executeProcessorTask(DefaultReadTask.java:341)
at com.sun.enterprise.web.connector.grizzly.DefaultReadTask.doTask(DefaultReadTask.java:263)
at com.sun.enterprise.web.connector.grizzly.DefaultReadTask.doTask(DefaultReadTask.java:214)
at com.sun.enterprise.web.connector.grizzly.TaskBase.run(TaskBase.java:267)
at com.sun.enterprise.web.connector.grizzly.WorkerThreadImpl.run(WorkerThreadImpl.java:118)



 Comments   
Comment by Shing Wai Chan [ 11/Jun/13 05:53 PM ]

Can you provide a test case for the above scenario?

Comment by Shing Wai Chan [ 25/Jun/13 06:26 PM ]

I have compared the codes in v3 and v4. There are a lot changes there. Can you download an updated version of GlassFish to see whether the issue is already resolved?

Comment by Shing Wai Chan [ 08/Jul/13 10:51 PM ]

Do we still have the issue in GlassFish v3 or GlassFish v4?
If yes, please provide a test case to illustrate the issue.

If you have question on GlassFish, please send email to users@glassfish.java.net
(There are many other experts subscribing the alias.)





[GLASSFISH-20788] Order ServletContainerInitializers according to web-fragment order Created: 31/Aug/13  Updated: 31/Aug/13

Status: Open
Project: glassfish
Component/s: web_container
Affects Version/s: 3.1.2.2, 4.0
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: Nick Williams Assignee: Shing Wai Chan
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: servlet-container-initializer web-fragment order
Participants: Nick Williams and Shing Wai Chan

 Description   

For context, see https://java.net/jira/browse/SERVLET_SPEC-79.

The Servlet 3.0 and 3.1 specs require no specific order for ServletContainerInitializers. This is a serious flaw in the spec, because it eliminates the ability to guarantee that certain code runs before any other code (for example, initialization of logging frameworks). In Servlet 2.5 and earlier, you could guarantee a exact ordering of startup code, but you can't do that anymore. To be clear, the spec does not prohibit the container from ordering them in a certain way, it just doesn't specify an order that should be followed.

Tomcat (confirmed), TomEE (confirmed), JBoss (confirmed), WebLogic (apparent), and WebSphere (apparent) order SCIs according to the order of the web-fragments they appear in. That way, either using <order> or <absolute-ordering>, an application can guarantee that a particular SCI will run first. GlassFish executes SCIs in the order they are returned by the ClassLoader.

I believe it would be an improvement for GlassFish and for the community as a whole if GlassFish would order SCIs according to the web-fragment order, just like the five aforementioned containers. Furthermore, since GlassFish currently copies the URL array from the ClassLoader, rips out URLs that would be excluded by the web-fragment order, then creates a NEW ClassLoader just to load SCIs using the ServiceLoader (a very clunky process, to say the least), this change would represent a major improvement to the process GlassFish uses to load SCIs, and could even improve startup performance.

Finally, I intend to lobby hard for this to be the required behavior in the Servlet 3.2 spec. If GlassFish 3 and 4 implemented this behavior, it would make the argument more compelling, and also require no changes in GlassFish 5 once Servlet 3.2 is finalized.

(FYI: I am filing similar enhancement requests for Resin and Jetty.)






[GLASSFISH-20868] Alternate Docroot does not work as server property Created: 23/Oct/13  Updated: 23/Oct/13

Status: Open
Project: glassfish
Component/s: web_container
Affects Version/s: 4.0_b89_RC5
Fix Version/s: None

Type: Bug Priority: Major
Reporter: UncleMoose Assignee: Shing Wai Chan
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Ubuntu(64) jdk1.7.0_17 non-clustered


Tags:
Participants: Shing Wai Chan and UncleMoose

 Description   

Glassfish 4 build 89 jdk1.7 Ubuntu::
Server property: alternatedocroot_1 from=/exports/* dir=/apps/myApp
"166.34.148.150" "NULL-AUTH-USER" "22/Oct/2013:15:04:56 -0700" "GET /exports HTTP/1.1" 404 1082
Expected results is a directory listing

Glassfish 3.1.1 (build 12) clustered, jdk1.6, Solaris::
Does not work as server configuration or application property.
Server property results in 404.
Application property results in Invalid alternate_docroot from=/exports/* dir=/apps/myApp

Works in glassfish 2.1.1 on Solaris jdk1.5 in clustered environment

Does not matter how many times the cluster and server is bounced.



 Comments   
Comment by Shing Wai Chan [ 23/Oct/13 06:55 PM ]

There is no support for directory listing for alternated docroot.
http://docs.oracle.com/cd/E19798-01/821-1752/geqpl/index.html

Comment by UncleMoose [ 23/Oct/13 07:42 PM ]

So how do you get this added back? It works in version 2.1.1?





[GLASSFISH-20916] Terminating Browser Leaves Open/Lingering WebSockets Created: 05/Dec/13  Updated: 09/Dec/13

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

Type: Bug Priority: Major
Reporter: kag0782 Assignee: Shing Wai Chan
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows 32bit


Tags: websockets
Participants: kag0782, Pavel Bucek and Shing Wai Chan

 Description   

If a browser that has opened a websocket is killed (not closed, but terminated abruptly), the websocket connection on the server is still considered "open" (i.e. onClose is not called on the endpoint), and still allows data to be written to the session without exceptions being thrown.

Example:

@ServerEndpoint("/test")
@WebServlet(urlPatterns={"/connections"})
public class Test extends HttpServlet {

    private static final HashSet<Session> sessions = new HashSet<Session>();

    @Override
    protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException {
        resp.getWriter().print(sessions.size());
    }

    @OnOpen
    public void onOpen(Session session, EndpointConfig config) {
        sessions.add(session);
    }
    
    @OnClose
    public void onClose(Session session, CloseReason reason) {
        sessions.remove(session);
    }
    
}

Establishing a websocket connection to /test above will cause the /connections servlet to respond with "1". If the browser is terminated, /connections will still return "1". If another websocket connection to /test is made, then /connections will show "2". This is leading to a memory leak.



 Comments   
Comment by Pavel Bucek [ 06/Dec/13 08:32 AM ]

are you sure that @OnClose is not ever called? (It probably might take some time, since it looks that underlying TCP connection is not properly closed - it will need to hit some idle timeout).

There is not much we can do in Tyrus (WebSocket RI) to improve this - we do rely on Servlet's mechanism to report us that connection has been closed and if that don't happens, the connection is considered to be open. Furthermore, the fact that you are able to write the data to the session means that the TCP connection is still open.

You can try to reproduce jt by using just plain Servlet API (HttpUpgradeHandler#destroy should be called when client disconects) and then maybe file a bug against it..

Comment by kag0782 [ 07/Dec/13 01:03 AM ]

Thank you. Destroy is apparently only ever called when the WebConnection object is closed; which means that the web socket must be closed through the handshake method. That is not good.

Comment by kag0782 [ 07/Dec/13 11:33 AM ]

I reproduced the issue using the plain servlet API as you said. The servlet does indeed instruct the handler that the connection was closed; however, it is not done through the destroy method, but rather through the ServletInputStream of the WebConnection object as given to the HttpUpgradeHandler. When the socket is closed, the ReadListener's onDataAvailable method is called indicating some data has arrived. When the input stream is then read from it throws a EOFException. This should instruct the web socket implementation to forcibly close the connection by calling close on the WebConnection (and incidentally the @OnClose method of the endpoint). This in turn calls the destroy method on the HttpUpgradeHandler.

Here is my example:

@WebServlet(urlPatterns={"/test5"})
public class UpgradeTest extends HttpServlet implements HttpUpgradeHandler {

    @Override
    protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException {
        try {
            MessageDigest cipher = MessageDigest.getInstance("SHA-1");
            cipher.reset();
            cipher.update((req.getHeader("sec-websocket-key") + "258EAFA5-E914-47DA-95CA-C5AB0DC85B11").getBytes());
            resp.setHeader("Sec-Websocket-Accept", new BASE64Encoder().encode(cipher.digest()));
            resp.setHeader("Upgrade", "websocket");
            resp.setHeader("Connection", "Upgrade");
            resp.setStatus(101);
            resp.flushBuffer();
            req.upgrade(UpgradeTest.class);
        } catch (Exception e) {
        }
    }
    
    public void destroy() {
        System.err.println("Destroyed");
    }
    
    public void init(final WebConnection wc) {
        System.err.println("Initialized");
        try {
            R r = new R(wc.getInputStream());
            wc.getInputStream().setReadListener(r);
            wc.getOutputStream().setWriteListener(r);
        } catch (IOException e) {
        }
    }
    
    public static class R implements ReadListener, WriteListener {
        private final ServletInputStream i;
        
        public R(ServletInputStream i) {
            this.i = i;
        }
        
        public void onAllDataRead() {
            System.err.println("All data read");
        }

        public void onDataAvailable() {
            System.err.println("Data available");
            try {
                System.err.println(i.readLine(new byte[1000], 0, 1000));
            } catch (IOException e) {
                e.printStackTrace();
            }
        }

        public void onError(Throwable t) {
            t.printStackTrace();
        }

        public void onWritePossible() {
            System.err.println("Write possible");
        }
    }
    
}
Comment by Pavel Bucek [ 09/Dec/13 02:32 PM ]

I cannot reproduce it on my Mac. I guess this might be platform related issue.

.. anyway, this is not related to Tyrus, it is more Servlet issue from my point of view. Reassigning to Servlet group for further evaluation.





[GLASSFISH-20933] When the session is newly made by asynchronization Servlet, the time-outis not done while locked Created: 18/Dec/13  Updated: 18/Dec/13

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

Type: Bug Priority: Major
Reporter: xianwu Assignee: Shing Wai Chan
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

OS
Windows 7 Enterprise (Service Pack 1)

JDK
java version "1.7.0_11"
Java(TM) SE Runtime Environment (build 1.7.0_11-b21) Java HotSpot(TM) 64-Bit Server VM (build 23.6-b04, mixed mode)

GlassFish build: glassfish-4.0.1-b02-07_22_2013


Tags:
Participants: Shing Wai Chan and xianwu

 Description   

We have a web application atest2.war, which contains two servlets: "simple" and "test".
"simple" is a non-async servlet and "test" is an async servlet.
The session time out was set to 1 minute in web.xml

When accessing non-async servlet "/simple", a session was created, then destroyed when time out was reached

However, when accessing async servlet "/test", a session was created but not destroyed time out was reached.

Reproducible operational steps:

1) deploy atest2.war
asadmin deploy c:\tmp\atest2.war
Application deployed with name atest2.
Command deploy executed successfully.

2) access non-async servlet
http://localhost:8080/atest2/simple

The lifecycle of the session can be confirmed in the server.log. The session (2d5e8779e02499f08d42ea52cd0a)was created then destroyed when time out was reached.

[2013-12-18T10:13:29.719+1100] [glassfish 4.0] [INFO] [] [] [tid: _ThreadID=106 _ThreadName=Thread-7] [timeMillis: 1387322009719] [levelValue: 800] [[
SessionCreated: 2d5e8779e02499f08d42ea52cd0a]]

[2013-12-18T10:14:52.990+1100] [glassfish 4.0] [INFO] [] [] [tid: _ThreadID=147 _ThreadName=Thread-7] [timeMillis: 1387322092990] [levelValue: 800] [[
SessionDestroyed: 2d5e8779e02499f08d42ea52cd0a]]

3) access async servlet
http://localhost:8080/atest2/test

The lifecycle of the session can be confirmed in the server.log. The session (2f028ea7bf9fc3aa8c6680ed196e)was created but it was not destroyed when time out (about 1 minute) was reached.

[2013-12-18T10:42:10.154+1100] [glassfish 4.0] [INFO] [] [] [tid: _ThreadID=180 _ThreadName=Thread-7] [timeMillis: 1387323730154] [levelValue: 800] [[
SessionCreated: 2f028ea7bf9fc3aa8c6680ed196e]]

[2013-12-18T10:42:10.154+1100] [glassfish 4.0] [INFO] [] [] [tid: _ThreadID=180 _ThreadName=Thread-7] [timeMillis: 1387323730154] [levelValue: 800] [[
AsyncHandler#onComplete]]

4) stop domain to stop the process of async servlet
asadmin stop-domain domain1
Waiting for the domain to stop .
Command stop-domain executed successfully.

When the server was shutdown, then, the session of async servlet (2f028ea7bf9fc3aa8c6680ed196e) was destroyed.

[2013-12-18T10:47:25.246+1100] [glassfish 4.0] [INFO] [NCLS-CORE-00092] [javax.enterprise.system.core] [tid: _ThreadID=182 _ThreadName=Thread-35] [timeMillis: 1387324045246] [levelValue: 800] [[
Server shutdown initiated]]

[2013-12-18T10:47:25.246+1100] [glassfish 4.0] [INFO] [NCLS-BOOTSTRAP-00028] [javax.enterprise.bootstrap] [tid: _ThreadID=182 _ThreadName=Thread-35] [timeMillis: 1387324045246] [levelValue: 800] [[
Unregistered com.sun.enterprise.glassfish.bootstrap.osgi.EmbeddedOSGiGlassFishImpl@658f8f43 from service registry.]]

[2013-12-18T10:47:25.246+1100] [glassfish 4.0] [INFO] [] [] [tid: _ThreadID=182 _ThreadName=Thread-7] [timeMillis: 1387324045246] [levelValue: 800] [[
FileMonitoring shutdown]]

[2013-12-18T10:47:25.246+1100] [glassfish 4.0] [INFO] [NCLS-JMX-00002] [javax.enterprise.system.jmx] [tid: _ThreadID=182 _ThreadName=Thread-35] [timeMillis: 1387324045246] [levelValue: 800] [[
JMXStartupService: Stopped JMXConnectorServer: null]]

[2013-12-18T10:47:25.246+1100] [glassfish 4.0] [INFO] [NCLS-JMX-00001] [javax.enterprise.system.jmx] [tid: _ThreadID=182 _ThreadName=Thread-35] [timeMillis: 1387324045246] [levelValue: 800] [[
JMXStartupService and JMXConnectors have been shut down.]]

[2013-12-18T10:47:25.277+1100] [glassfish 4.0] [INFO] [] [] [tid: _ThreadID=186 _ThreadName=Thread-7] [timeMillis: 1387324045277] [levelValue: 800] [[
SessionDestroyed: 2f028ea7bf9fc3aa8c6680ed196e]]



 Comments   
Comment by xianwu [ 18/Dec/13 12:16 AM ]

I have uploaded the sample application atest.war at

https://www.dropbox.com/s/x5tbo5yqca9whrg/atest2.war





[GLASSFISH-20932] Error occurs when default-web-module is set. Created: 17/Dec/13  Updated: 24/Jan/14

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

Type: Bug Priority: Major
Reporter: xianwu Assignee: Shing Wai Chan
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

OS
Windows 7 Enterprise (Service Pack 1)

JDK
java version "1.7.0_11"
Java(TM) SE Runtime Environment (build 1.7.0_11-b21) Java HotSpot(TM) 64-Bit Server VM (build 23.6-b04, mixed mode)

GlassFish build: glassfish-4.0.1-b02-07_22_2013


Tags:
Participants: jifeng, Shing Wai Chan and xianwu

 Description   

Reproducible operational steps:

1) deploy a web application e.g. HelloServlet.war
asadmin deploy c:\tmp\HelloServlet.war
Application deployed with name HelloServlet.
Command deploy executed successfully.

2) set default-web-module to HelloServlet
asadmin set server.http-service.virtual-server.server.default-web-module=HelloServlet
server.http-service.virtual-server.server.default-web-module=HelloServlet
Command set executed successfully.

3) set http-listener-1.http.max-post-size-bytes
asadmin set server.network-config.protocols.protocol.http-listener-1.http.max-post-size-bytes=2000
server.network-config.protocols.protocol.http-listener-1.http.max-post-size-bytes=2000
Command set executed successfully.

4) error occurs in server.log

[2013-12-17T16:29:08.916+1100] [glassfish 4.0] [SEVERE] [AS-WEB-GLUE-00115] [javax.enterprise.web] [tid: _ThreadID=145 _ThreadName=pool-50-thread-1] [timeMillis: 1387258148916] [levelValue: 1000] [[
Exception processing HttpService configuration change
org.apache.catalina.LifecycleException: java.lang.Exception: No context matching /HelloServlet deployed on virtual server server
at com.sun.enterprise.web.WebContainer.updateDefaultWebModule(WebContainer.java:2340)
at com.sun.enterprise.web.WebContainer.updateHost(WebContainer.java:3157)
at com.sun.enterprise.web.reconfig.WebConfigListener$1.changed(WebConfigListener.java:156)
at org.jvnet.hk2.config.ConfigSupport.sortAndDispatch(ConfigSupport.java:331)
at com.sun.enterprise.web.reconfig.WebConfigListener.changed(WebConfigListener.java:132)
at org.jvnet.hk2.config.Transactions$ConfigListenerJob.process(Transactions.java:400)
at org.jvnet.hk2.config.Transactions$ConfigListenerJob.process(Transactions.java:390)
at org.jvnet.hk2.config.Transactions$ConfigListenerNotifier$1$1.call(Transactions.java:280)
at org.jvnet.hk2.config.Transactions$ConfigListenerNotifier$1$1.call(Transactions.java:278)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
at java.util.concurrent.FutureTask.run(FutureTask.java:166)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:722)
Caused by: java.lang.Exception: No context matching /HelloServlet deployed on virtual server server
at org.glassfish.grizzly.http.server.util.Mapper.addDefaultContext(Mapper.java:791)
at org.glassfish.grizzly.http.server.util.Mapper.setDefaultContextPath(Mapper.java:755)
at com.sun.enterprise.web.WebContainer.updateDefaultWebModule(WebContainer.java:2332)
... 13 more
]]

5) get http-listener-1.http.max-post-size-bytes
asadmin get server.network-config.protocols.protocol.http-listener-1.http.max-post-size-bytes
server.network-config.protocols.protocol.http-listener-1.http.max-post-size-bytes=2000
Command get executed successfully.



 Comments   
Comment by jifeng [ 13/Jan/14 11:12 AM ]

Hi
Shing Wai Chan
xianwu

After a few investigation about the source, I found the exact precise place where the failure happens:

org.glassfish.grizzly.http.server.util.Mapper
private void addDefaultContext(Host host, String defaultContextPath)
            throws Exception {

        boolean defaultContextFound = false;

        Context[] contexts = host.contextList.contexts;

        if (contexts != null) {
            for (Context context1 : contexts) {
                if (context1.name.equals(defaultContextPath)) {
                    host.defaultContexts[0] = context1;
                    defaultContextFound = true;
                    break;
                }
            }
        }

        if (!defaultContextFound) {
            throw new Exception("No context matching " + defaultContextPath
                                + " deployed on virtual server "
                                + host.name);★
        }
    }

I have debuged the 'Mapper' class and found the [context.name] object has never been valued。

The [context.name] object's initialization processing as follows:

package com.sun.enterprise.v3.services.impl.ContainerMapper
private final static String ROOT = "";★
protected void configureMapper() {
    ......
    try {
    ....
         mapper.addContext(defaultHostName, ROOT★,
                    new ContextRootInfo(this, null),
                    new String[]{"index.html", "index.htm"}, null);
    ....
        } finally {
            mapperLock.writeLock().unlock();
        }
}

org.glassfish.grizzly.http.server.util.Mapper
public void addContext
            (String hostName, String path★, Object context,
            String[] welcomeResources, NamingContext resources,
            List<AlternateDocBase> alternateDocBases) {
    ......
    newContext.name = path;★//the [context.name] object's 
                             //value always equals to ""
    ......
 }
Comment by jifeng [ 24/Jan/14 07:25 AM ]

Hi
Shing Wai Chan
xianwu

I modify the following code, it works fine,could you please confirm it and give me some suggestions?

package com.sun.enterprise.v3.services.impl.ContainerMapper
@@ -69,6 +69,8 @@
 import org.glassfish.grizzly.http.util.MimeType;
 import org.glassfish.internal.grizzly.ContextMapper;
 import org.glassfish.kernel.KernelLoggerInfo;
+import com.sun.enterprise.config.serverbeans.ConfigBeansUtilities;
+import com.sun.enterprise.config.serverbeans.VirtualServer;
 
 /**
  * Container's mapper which maps {@link ByteBuffer} bytes representation to an  {@link HttpHandler}, {@link
@@ -148,7 +150,7 @@
         try {
             mapper.setDefaultHostName(defaultHostName);
             mapper.addHost(defaultHostName, new String[]{}, null);
-            mapper.addContext(defaultHostName, ROOT,
+            mapper.addContext(defaultHostName, getContextRoot(),
                     new ContextRootInfo(this, null),
                     new String[]{"index.html", "index.htm"}, null);
             // Container deployed have the right to override the default setting.
@@ -157,7 +159,29 @@
             mapperLock.writeLock().unlock();
         }
     }
-
+    
+    private String getContextRoot() {
+        String defaultWebModule = null;
+        String contextRoot = null;
+        Collection<VirtualServer> list = grizzlyService.getHabitat().getAllServices(VirtualServer.class);
+        ConfigBeansUtilities cbu = grizzlyService.getHabitat().getService(ConfigBeansUtilities.class);
+        for (VirtualServer virtualServer : list) {
+            if (virtualServer.getId().equals(defaultHostName)) {
+                defaultWebModule = virtualServer.getDefaultWebModule();
+                if (cbu == null) {
+                    contextRoot = null;
+                }
+                else {
+                    if (defaultWebModule != null) {
+                        contextRoot = cbu.getContextRoot(defaultWebModule);
+                    }
+                }
+                break;
+            }
+        }
+        return contextRoot == null ?ROOT:contextRoot;
+    }
+




[GLASSFISH-20988] session replication occasionally not work on different physical machine Created: 18/Feb/14  Updated: 18/Feb/14

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

Type: Bug Priority: Major
Reporter: makschim Assignee: Shing Wai Chan
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

JDK1.7, Glassfish 3.1.2,apache 2.4.4


Tags:
Participants: makschim and Shing Wai Chan

 Description   

I create a cluster using above mentioned enviroment. In this cluster, we have two different physical machine. We name them instance1 and instance2.
But the session replication between the two physical machine occasionally doesn't work. When the login request is sent to instance1, a session is created and the authentication information is stored in this session. When another new request for query data is forwarded by apache server to the instance2, the ssesion of instance1 is not correctly replicated from instance1. So there is no authentication information in instance2. Then the new request cannot query data from instance2.

I read before reported bugs for GF 3.1.1, and it indicates that this session replication lost bug has been fixed in GF 3.1.2. But for us, this bug is still exist. How can we fix this issue.

This is our glassfih-web.xml

<glassfish-web-app error-url="">
<context-root>/</context-root>

<session-config>
<session-manager persistence-type="replicated">
<manager-properties>
<property name="persistenceFrequency" value="time-based"/>
<property name="reapIntervalSeconds" value="30"/>
<property name="relaxCacheVersionSemantics" value="true"/>
</manager-properties>
<store-properties>
<property name="persistenceScope" value="session"/>
</store-properties>
</session-manager>
</session-config>
</glassfish-web-app>






[GLASSFISH-20849] "maxHistoryFile" is not honored if "GFFileHandler.file" does not point to default location in logging.properties Created: 11/Oct/13  Updated: 26/Feb/14

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

Type: Bug Priority: Major
Reporter: bhuvangu Assignee: Shing Wai Chan
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

RedHat 6, glassfish v3.1.2.2


Tags: logging
Participants: bhuvangu and Shing Wai Chan

 Description   

In "logging.properties" under "domains/mydomain/config"
If i change
com.sun.enterprise.server.logging.GFFileHandler.file=/TO/MY/LOCATION/file.log

then i can see log getting created, but
"com.sun.enterprise.server.logging.GFFileHandler.maxHistoryFiles=1"
is not honored.

If i change the
com.sun.enterprise.server.logging.GFFileHandler.file=/GF_LOCATION/domains/mydomain/logs/server.log
Then maxHistoryFiles works fine.



 Comments   
Comment by bhuvangu [ 26/Oct/13 08:13 AM ]
nucleus/core/logging/src/main/java/com/sun/enterprise/server/logging/GFFileHandler.java?rev=62871
...
private static final String LOG_FILE_NAME = "server.log";
...
public void cleanUpHistoryLogFiles() {
...
   File[] fset = dir.listFiles();
   ArrayList candidates = new ArrayList();

   for (int i = 0; fset != null && i < fset.length; i++) {

      if (!LOG_FILE_NAME.equals(fset[i].getName()) && fset[i].isFile()
         && fset[i].getName().startsWith(LOG_FILE_NAME)) {  -----This will always be false if log filename is changed in logging.properties file.

         candidates.add(fset[i].getAbsolutePath());
      }
   }
...

Here LOG_FILE_NAME always remain as "server.log" and while cleanup the if condition always fails.

Instead of using "LOG_FILE_NAME" in if condition we should use "absoluteFile.getName()"





[GLASSFISH-20872] Update DefaultServlet to leverage non-blocking APIs added in Servlet 3.1. Created: 24/Oct/13  Updated: 24/Oct/13

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

Type: Improvement Priority: Major
Reporter: Ryan Lubke Assignee: Shing Wai Chan
Resolution: Unresolved Votes: 1
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: Ryan Lubke and Shing Wai Chan

 Description   

Per the summary.






[GLASSFISH-21026] SEVERE failure in FRESH GlassFish 4.0 installation Created: 01/Apr/14  Updated: 01/Apr/14

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

Type: Bug Priority: Major
Reporter: mkarg Assignee: Shing Wai Chan
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

GlassFish 4.0 GA ZIP, Win 7 Pro SP1 (64 Bit), JDK 1.8.0 (32 Bit)


Tags:
Participants: mkarg and Shing Wai Chan

 Description   

After fresh installation of GF 4.0 I am getting the following SEVERE message in server.log.
I think it is not nice that a brand-new freshly installed GlassFish produces several of these.
It is scary for an administrator to find ANY SEVERE stuff in a freshly installed server having NO MODIFICATIONS and NO DEPLOYED APPLICATIONS.

[2014-04-01T14:40:50.083+0200] [glassfish 4.0] [SEVERE] [] [javax.enterprise.web.util] [tid: _ThreadID=184 _ThreadName=Thread-26] [timeMillis: 1396356050083] [levelValue: 1000] [[
The web application [] created a ThreadLocal with key of type [java.lang.ThreadLocal] (value [java.lang.ThreadLocal@27535138]) and a value of type [org.glassfish.admingui.theme.AdminguiThemeContext] (value [org.glassfish.admingui.theme.AdminguiThemeContext@5d1efaf3]) but failed to remove it when the web application was stopped. Threads are going to be renewed over time to try and avoid a probable memory leak.]]






[GLASSFISH-21032] NPE if alternatedocroot_1 has from=/* Created: 07/Apr/14  Updated: 15/Apr/14

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

Type: Bug Priority: Major
Reporter: m.zdila Assignee: Shing Wai Chan
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

glassfish-4.0.1-b04-04_05_2014-ml
java version "1.7.0_51"
OpenJDK Runtime Environment (IcedTea 2.4.5) (7u51-2.4.5-2)
OpenJDK 64-Bit Server VM (build 24.51-b03, mixed mode)


Tags:
Participants: m.zdila and Shing Wai Chan

 Description   

glassfish-4.0.1-b04-04_05_2014-ml

In glassfish-web.xml I have following element:
<property name="alternatedocroot_1" value="from=/* dir=/home/martin/teris-client"/>

On deploy Glassfish throws exception:

2014-04-07T16:32:31.149+0200|SEVERE: ContainerBase.addChild: start:
org.apache.catalina.LifecycleException: org.apache.catalina.LifecycleException: start:
at org.apache.catalina.core.StandardContext.start(StandardContext.java:5898)
at com.sun.enterprise.web.WebModule.start(WebModule.java:691)
at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:1041)
at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:1024)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:747)
at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:2286)
at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:1932)
at com.sun.enterprise.web.WebApplication.start(WebApplication.java:139)
at org.glassfish.internal.data.EngineRef.start(EngineRef.java:122)
at org.glassfish.internal.data.ModuleInfo.start(ModuleInfo.java:291)
at org.glassfish.internal.data.ApplicationInfo.start(ApplicationInfo.java:352)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:500)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:219)
at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:491)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:539)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:535)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:356)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2.execute(CommandRunnerImpl.java:534)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$3.run(CommandRunnerImpl.java:565)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$3.run(CommandRunnerImpl.java:557)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:356)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:556)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1464)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1300(CommandRunnerImpl.java:109)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1846)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1722)
at com.sun.enterprise.v3.admin.AdminAdapter.doCommand(AdminAdapter.java:534)
at com.sun.enterprise.v3.admin.AdminAdapter.onMissingResource(AdminAdapter.java:224)
at org.glassfish.grizzly.http.server.StaticHttpHandlerBase.service(StaticHttpHandlerBase.java:189)
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:215)
at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:291)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:209)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:137)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:115)
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:550)
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:744)
Caused by: org.apache.catalina.LifecycleException: start:
at org.apache.catalina.loader.WebappLoader.start(WebappLoader.java:770)
at org.apache.catalina.core.StandardContext.start(StandardContext.java:5864)
... 49 more
Caused by: java.lang.StringIndexOutOfBoundsException: String index out of range: 0
at java.lang.String.charAt(String.java:658)
at org.apache.naming.resources.WebDirContext.getAbsoluteJarResourceName(WebDirContext.java:416)
at org.apache.naming.resources.WebDirContext.lookupAllFromJars(WebDirContext.java:349)
at org.apache.naming.resources.WebDirContext.list(WebDirContext.java:214)
at org.apache.catalina.loader.WebappLoader.copyDir(WebappLoader.java:1321)
at org.apache.catalina.loader.WebappLoader.setRepositories(WebappLoader.java:1116)
at org.apache.catalina.loader.WebappLoader.start(WebappLoader.java:759)
... 50 more

In Glassfish 4.0 it works.






[GLASSFISH-20917] a wrong implementation for web-fragment.xml with <distributable/> issue Created: 06/Dec/13  Updated: 15/Apr/14

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

Type: Bug Priority: Major
Reporter: jumperchen Assignee: Shing Wai Chan
Resolution: Unresolved Votes: 1
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

fail with both Glassfish 3 and 4 version


Tags:
Participants: jumperchen and Shing Wai Chan

 Description   

If a web application contains with a jar (for example Spring 3.2.2 version) that enables the attribute <distributable/> in the web-fragment.xml, this setting will cause glassfish server run in cluster environment.

You may refer to this fixed in Spring's tracker - https://jira.springsource.org/browse/SPR-10219

To reproduce this issue is to save a non-serializable object to session attribute, for example

<%
   session.setAttribute( "test", new java.io.ByteArrayOutputStream(20) );
%>

Note that the web.xml doesn't specify the <distributable/>.






[GLASSFISH-21043] Glassfish 4 admin gui class loading issue when built from source (as at svn revision 63170) Created: 17/Apr/14  Updated: 18/Apr/14

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

Type: Bug Priority: Major
Reporter: Dave Whitla Assignee: Shing Wai Chan
Resolution: Unresolved Votes: 0
Remaining Estimate: 0 minutes
Time Spent: Not Specified
Original Estimate: 0 minutes
Environment:

Apache Maven 3.0.5 (r01de14724cdef164cd33c7c8c2fe155faf9602da; 2013-02-19 23:51:28+1000)
Maven home: /opt/local/share/java/maven3
Java version: 1.7.0_55, vendor: Oracle Corporation
Java home: /Library/Java/JavaVirtualMachines/jdk1.7.0_55.jdk/Contents/Home/jre
Default locale: en_US, platform encoding: utf-8
OS name: "mac os x", version: "10.9.2", arch: "x86_64", family: "mac"


Tags: admin-gui
Participants: Anissa Lam, Dave Whitla and Shing Wai Chan

 Description   

The default domain starts without error. Attempting to access the admin application fails with the root cause being failure to locate com.sun.webui.jsf.faces.UIComponentELResolver.
The class in question exists within $INSTALL_ROOT/lib/install/applications/__admingui/WEB-INF/extra/webui-jsf-4.0.2.10.jar and was compiled using the same JDK I am using to start the container.

Root cause:

The current source for sun-web.xml in the __admingui module contains the following:

<class-loader delegate="true"
extra-class-path="WEB-INF/extra/webui-jsf-suntheme-4.0.2.10.jar
:WEB-INF/extra/dojo-ajax-nodemo-0.4.1.jar
:WEB-INF/extra/webui-jsf-4.0.2.10.jar
:WEB-INF/extra/commons-fileupload-1.1.1.jar
:WEB-INF/extra/commons-io-1.3.1.jar
:WEB-INF/extra/json-1.0.jar
:WEB-INF/extra/prototype-1.5.0.jar" />

com.sun.enterprise.glassfish.web.WarHandler.configureLoaderAttributes() does not strip whitespace characters when splitting extra-class-path into path elements.
See com.sun.enterprise.glassfish.web.WarHandler:286 for details.

Consequently at line 310:
URL url = file.toURI().toURL();

the spaces are URL encoded as %20 before passing the string to:
cloader.addRepository(url.toString());

which then silently fails to add the jar to the classpath.
Strangely addRepository(String) converts the string back to a URL before passing it (eventually) to URLClassPath.addURL(). I don't have the source for this class but it evidently doesn't like the trailing encoded whitespace characters, because after this call returns the classpath has not changed.

A patch for the issue is attached to https://www.java.net/forum/topic/glassfish/glassfish/glassfish-4-admin-console-class-loading-issue-when-built-source where the problem was first reported.



 Comments   
Comment by Dave Whitla [ 17/Apr/14 07:00 PM ]

When reviewing my changes to commit the fix (to my git clone) I noticed that the reformatting of sun-web.xml had actually been done automagically by my IDE (IntelliJ).
This explains the issue not affecting others.

While the conditions were thus self inflicted, I think this is still a latent bug.
The documentation does state that the extra-class-path consists of path elements separated by ':' or ';' with no explicit allowance for whitespace. However whitespace at the end of a path is perfectly valid and failure to handle it robustly is a future problem. Further, the root cause failure is silent in the shipped configuration, giving new users/developers no clue at all as to why their application fails to load.

Request that you apply the patch.

Comment by Anissa Lam [ 17/Apr/14 07:02 PM ]

Thanks for filing and debugging the issue.
The suspect code is in web container, I am transferring this to that team for further evaluation.
If we can't load the console, then this is very critical and we will need to upgrade this to P2 and need to be fixed for 4.0.1.

Comment by Dave Whitla [ 18/Apr/14 03:03 AM ]

Hi Anissa,

You may have missed that I already have a fix and that, on further analysis, this does not affect all users as first suspected - indeed it is a bit of an edge case.
I would attach my patch but I don't seem to have permissions to attach files to this bug report.

Please see the link in my original report for the patch I have created for this issue.

Comment by Anissa Lam [ 18/Apr/14 05:10 AM ]

Yes, looks like our comments cross each other, with 2 min. difference.
The web container team will make the decision on how to proceed with the bug.
thanks.





[GLASSFISH-5320] Support for HTTP1.1 Expect Header Created: 17/Jul/08  Updated: 26/Mar/13

Status: Open
Project: glassfish
Component/s: web_container
Affects Version/s: v2.1
Fix Version/s: future release

Type: Bug Priority: Minor
Reporter: udaysubbarayan Assignee: Shing Wai Chan
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


File Attachments: Zip Archive Issue5320.zip    
Issuezilla Id: 5,320
Status Whiteboard:

v3_exclude

Tags: 3_1-exclude
Participants: craigmcc, jagadesh, jfarcand, kumara, oleksiys, sanandal, Santiago Pericas-Geertsen, Shing Wai Chan, Tom Mueller and udaysubbarayan

 Description   

I discussed this defect with Jeanfrancois & other Glassfish team members and
decided to file a bug report for it.

-Uday.
------------------------------------xxx--------------------------------
Glassfish doesn't properly handle the HTTP 1.1 "Expect:100-continue" header.

Detail:
When my client sends a request with "Expect:100-Continue" header, the Glassfish
(http server?) immediately sends a 100 Continue response back to my client
before it reaches my Servlet. So, i can't build any business logic with the
header info and reject the request based on it.....

Here is an example. My client sends this request:
-------------------------------------------------

  • About to connect() to localhost port 8080 (#0)
  • Trying 127.0.0.1... connected
  • Connected to localhost (127.0.0.1) port 8080 (#0)
    > PUT /testci/index HTTP/1.1
    > User-Agent: curl/7.18.2 (i386-pc-win32) libcurl/7.18.2 OpenSSL/0.9.8h
    zlib/1.2.3
    > Host: localhost:8080
    > Accept: /
    > Content-Length: 40
    > Expect: 100-continue
    >

The response from Glassfish:
-----------------------------
< HTTP/1.1 100 Continue
< HTTP/1.1 417 Expectation Failed
< X-Powered-By: Servlet/2.5
< Server: Sun Java System Application Server 9.1
< Content-Type: text/html
< Content-Language:
< Content-Length: 1058
< Date: Thu, 17 Jul 2008 14:42:30 GMT
<

Pl pay attention to the first 2 lines from Glassfish. Yes, there are 2
responses. The first one is the immediate response from GF. This made my client
to send the body and it landed in my Servelt. If you look at the 2nd line, it's
the response i send from my servlet, but no-effect. Before my servlet rejects
the request, the GF allowed the client to continue the request.

This completely breaks this HTTP1.1 Expect Header std. and is an serious issue
to build the RESTful PUT/POST API with Glassfish.

------------------------------------------------------------------------------



 Comments   
Comment by jfarcand [ 17/Jul/08 02:32 PM ]

Change the target and sustaining will makes sure it will be back ported, if a
bug exists . Mark the bug as started, although I'm not convinced the bug is
in Grizzly/Tomcat (this is handled by the Coyote code). Looking at it....

Comment by jfarcand [ 17/Jul/08 02:53 PM ]

Fix Target.

Comment by jfarcand [ 24/Jul/08 08:13 PM ]

The Servlet spec is quite unclear about how 100-Continue should be implemented.
Jan description here

http://forums.java.net/jive/thread.jspa?messageID=286576

describe the difference amongst current WebContainer. I do believe our
implementation is correct but different than what you can see when using Jetty.
I'm downgrading the issue to a p3 for now even if I do think this is not a bug.
I'm currently evaluating how dangerous it would be to change the current
behavior to accommodate your needs. One solution would consist of adding a
property and let the current behavior untouched.

Comment by udaysubbarayan [ 24/Jul/08 09:30 PM ]

I totally disagree with you. This is NOT a Servlet Issue and it's about
supporting HTTP 1.1 protocol.
http://www.ietf.org/rfc/rfc2616.txt

If the servlet spec doesn't mention about 100 status, pl file a bug against the
servlet spec.

If Glassfish supports HTTP 1.1, then this should be a P1 bug. If Glassfish
doesn't support HTTP 1.1, then I agree that this is P3 bug.

Question:
Is Glassfish is a HTTP 1.1 complaint server?

-Uday.

Comment by jfarcand [ 09/Oct/08 06:01 PM ]

Looking at it again to see if I can cut something safe for the 2.1 release.

Comment by jfarcand [ 20/Nov/08 10:27 AM ]

Working on it. Will ask for approval into 2.1

Comment by sanandal [ 11/Jan/09 07:01 AM ]

"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 jfarcand [ 15/Apr/09 06:29 PM ]

Bring that one to life.

Comment by craigmcc [ 31/May/09 01:11 PM ]

Add myself to the cc list.

Comment by jfarcand [ 08/Jun/09 10:02 AM ]

Fix will be available in 1.0.30, which release target is June 19. Grizzly 1.0 is
developed under the grizzly.dev.java.net and can be downloaded from here:

http://download.java.net/maven/2/com/sun/grizzly/grizzly-framework-http/

You can boostrap it using Maven 2:

<groupId>com.sun.grizzly</groupId>
<artifactId>grizzly-framework-http</artifactId>
<version>1.0.29</version>

Comment by kumara [ 01/Sep/09 01:09 AM ]

Changing version from 9.1.1 to v2.1 to reflect new name/version.

Comment by jagadesh [ 15/Oct/09 04:20 PM ]

Will not be fixed for V2.1.1

Comment by jagadesh [ 15/Oct/09 04:22 PM ]

Will not be fixed for V2.1.1

Comment by jfarcand [ 29/Oct/09 12:38 PM ]

Bring this issue to life so we can evaluate it for v3.

Comment by jfarcand [ 02/Nov/09 12:38 PM ]

Too dangerous for GF v3, but will commit the fix in Grizzly 1.0.32 and Grizzly
1.9.19 so v2 and v3 can be upgraded after FCS release. Hopefully the code goes
in this week.

Comment by jfarcand [ 03/Nov/09 12:27 PM ]

...

Comment by jfarcand [ 01/Dec/09 08:00 AM ]

Alexey is now the owner

Comment by oleksiys [ 07/Oct/10 03:00 AM ]

Grizzly supports Response.acknowledge() method.
Now it's up to web container to use it properly. Currently I see StandardWrapperValve to call acknowledge
automatically for all requests, so as I understand, user doesn't have a chance to customize it.

May be servlet filters should have a chance to process the expect header?
Passing to Shing Wai

Comment by oleksiys [ 07/Oct/10 03:10 AM ]

cc'ing myself

Comment by Santiago Pericas-Geertsen [ 13/Oct/10 07:12 AM ]

I agree with Alexey. The problem appears to be in StandardWrapperValve. It is calling
response.sendAcknowledgement() before the application filters. Calling that method results in
"HTTP/1.1 100 Continue" to be returned to the client. Thus, not giving the application a chance
to reject the operation, if so desired.

Is there any risk to move the acknowledgement code after the code that runs the filters? A filter
could throw a ServletException if such a request is to be rejected. I'll attach a test case.

Comment by Santiago Pericas-Geertsen [ 13/Oct/10 07:25 AM ]

Created an attachment (id=5140)
NB project that uses a JUnit test based on Jersey client. Use monitor on port 9090 to eavesdrop traffic.

Comment by Santiago Pericas-Geertsen [ 21/Oct/10 09:45 AM ]

Further analysis shows that there are other problems beyond GF. As explained in
this blog,

http://blogs.sun.com/jcc/entry/httpurlconnection_and_100_continue

JDK 6 is currently ignoring (skipping over) the "HTTP/1.1 100 Continue"
response. As a result, there is no easy way for a java client app to determine
if a request to send data is accepted or not. This is being addressed in JDK 7.

It is possible for the web container to let a servlet respond to a request that
includes an "Expect: 100-continue". However, assuming the servlet accepts the
request, the natural response will be:

HTTP/1.1 100 Continue
Server: Glassfish ...
Date: ...
Content-Length: 0

Unfortunately, the JDK will get stuck on this response after skipping over the
first line and looking for another status code. Currently, GF will return two
response codes: 100 by the web container and then the response code from the
servlet.

In summary, fixing this issue in GF will not help Java clients much, and may
even break some existing ones. Of course, we ought to support non-Java clients,
but lacking good JDK support makes testing more difficult.

Comment by Tom Mueller [ 06/Mar/12 09:57 PM ]

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





[GLASSFISH-6045] May have incorrect default value of class-loader delegate in sun-web.xml Created: 09/Sep/08  Updated: 26/Mar/13

Status: Open
Project: glassfish
Component/s: web_container
Affects Version/s: V3
Fix Version/s: future release

Type: Bug Priority: Minor
Reporter: Shing Wai Chan Assignee: Shing Wai Chan
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Macintosh


Issuezilla Id: 6,045
Status Whiteboard:

gfv3-prelude-included

Tags:
Participants: kumara, Shing Wai Chan and Tom Mueller

 Description   

In sun-web-app_2_2-0.dtd, sun-web-app_2_3-0.dtd, sun-web-app_2_3-1.dtd, the
delegate attribute of class-loader in sun-web.xml has a default value false.
While in newer versions, like sun-web-app_2_4-0.dtd, sun-web-app_2_4-1.dtd,
sun-web-app_2_5-0.dtd has a default value true.

In current impl, we have default value true. This will be an issue for old dtds.



 Comments   
Comment by Shing Wai Chan [ 09/Sep/08 05:43 PM ]

...

Comment by kumara [ 10/Sep/08 10:19 AM ]

v3 defect tracking

Comment by Tom Mueller [ 06/Mar/12 09:55 PM ]

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





[GLASSFISH-20777] Web fragment resources not found on exploded War Created: 22/Aug/13  Updated: 22/Aug/13

Status: Open
Project: glassfish
Component/s: web_container
Affects Version/s: 3.1.2_b04
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: michael.friedrich Assignee: Shing Wai Chan
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows


Tags: exploded web-fragment war
Participants: michael.friedrich and Shing Wai Chan

 Description   

I tried to use exploded Wars with included and also exploded Web Fragments for shorter development turn arounds.
This didn't really work out because the WebappClassLoader ignores resources in META-INF/resources.
Example war directory structure:
ExplodedWar
WEB-INF
lib
WebFragment.jar(directory)
META-INF/resources
hello.html
If WebFragment.jar is packaged as Jar 'hello.html' is found fine.
Our workaround for now is to use custom javax.faces.view.facelets.ResourceResolver which first calls WebappClassLoader#getResource("META-INF/resources" + path) in Development project stage.






[GLASSFISH-20729] ServletRequest.getLocales() and BCP47 style Language tags. Created: 26/Jul/13  Updated: 02/Oct/13

Status: Open
Project: glassfish
Component/s: web_container
Affects Version/s: v2.1.1, v3.0.1, 4.0
Fix Version/s: 4.0

Type: Bug Priority: Minor
Reporter: Ed Burns Assignee: Shing Wai Chan
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: Ed Burns, Ryan Lubke and Shing Wai Chan

 Description   

If a user agent sends an Accept-Language: header with language tags that conform to BCP47 <http://tools.ietf.org/html/bcp47>, the current implementation of ServletRequest.getLocales() may not behave correctly. This is because additional actions must be taken with new methods in the java.util.Locale API added in JavaSE 7.

For more on this issue see bugdb bug 14676641.



 Comments   
Comment by Ed Burns [ 29/Jul/13 01:47 PM ]

>>>>> On Fri, 26 Jul 2013 12:27:47 -0700, Blake Sullivan said:

B> The correct thing to do in Java 7 is to create the correct locale by
B> calling Locale, forLanguageTag() on each locale passed in (which is
B> one of the reasons for preserving the BCP locales) and fixing your
B> locale matching code to take the scripts into account (the scripts
B> are more important than the territories, which is why they appear
B> after the languages in the BCP locales). The Locale code in Java7
B> should make the comparisons you want work correctly because I believe
B> that "zh-TW" will be turned into "zh-Hant-TW. Therefore a request
B> for "zh-Hant" will match "zh-Hant-TW", which is what you want.

Comment by Shing Wai Chan [ 07/Aug/13 06:58 PM ]

In GlassFish, ServletRequest.getLocale has delegated to Grizzly which is in JDK 6.
We can override that in GlassFish if necessary. Let me do further investigation.

Comment by Ryan Lubke [ 09/Aug/13 08:39 PM ]

Fixed in Grizzly 2.3.5 (not yet released) under https://java.net/jira/browse/GRIZZLY-1570 .

Comment by Ed Burns [ 02/Oct/13 03:32 PM ]

Because this is fixed in GRIZZLY-1570, can we close this issue?

Comment by Shing Wai Chan [ 02/Oct/13 06:37 PM ]

The trunk is in Grizzly 2.3.3, not even Grizzly 2.3.4. That is why I have not closed the issue yet.





Generated at Wed Apr 23 15:09:19 UTC 2014 using JIRA 4.0.2#472.