Java EE 7: javaee-api.jar (GLASSFISH-19259)

[GLASSFISH-19375] provide javax.ejb-api under official coordinates Created: 27/Nov/12  Updated: 22/Jan/13  Due: 03/Dec/13  Resolved: 22/Jan/13

Status: Closed
Project: glassfish
Component/s: build_system
Affects Version/s: 4.0_b63
Fix Version/s: 4.0_b65

Type: Sub-task Priority: Major
Reporter: Romain Grécourt Assignee: Romain Grécourt
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 1 week
Time Spent: Not Specified
Original Estimate: 1 week
Environment:

any


Tags: ejb, glassfish, maven

 Description   

1) copy those sources to
> https://svn.java.net/svn/glassfish~svn/trunk/api/javaee-api/javax.ejb
whithout javax.interceptor as it will be released apart.

2) setup release.sh scripts for releasing new versions easily
3) remove appserver/ejb/javax.ejb and replace all the occurences of org.glassfish.main:javax.ejb by javax.ejb:javax.ejb-api or javax.interceptor:javax.interceptor-api

Official coordinates will be javax.ejb:javax-ejb-api:3.2

see https://wikis.oracle.com/display/GlassFish/Maven+Versioning+Rules






[GLASSFISH-19364] web container does not call AsyncContext.complete() if dispatched servlet throws Exception Created: 22/Nov/12  Updated: 22/Dec/12  Resolved: 27/Nov/12

Status: Resolved
Project: glassfish
Component/s: web_container
Affects Version/s: 3.1.2.2
Fix Version/s: 4.0_b65

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

Attachments: File asynctest.war    

 Description   

When an exception occurs in the execution of async dispatch(),
web container MUST call AsyncContext.complete()
if user application(AsyncListener or Error Page) does not call AsyncContext.complete().

This behavior is written in the explanation of AsyncContext in Servlet 3.0 specification, section 2.3.3.3 Asynchronous processing.

Any errors or exceptions that may occur during the execution of the dispatch methods MUST be caught and handled by the container as follows:

i.invoke the AsyncListener.onError(AsyncEvent) method for all instances of the AsyncListener registered with the ServletRequest for which the AsyncContext was created and make the caught Throwable available via the AsyncEvent.getThrowable()
ii. If none of the listeners called AsyncContext.complete or any of the AsyncContext.dispatch methods, then perform an error dispatch with a status code equal to HttpServletResponse.SC_INTERNAL_SERVER_ERROR and make the Throwable available as the value of the RequestDispatcher.ERROR_EXCEPTION request attribute.
iii.If no matching error page is found, or the error page does not call AsyncContext.complete() or any of the AsyncContext.dispatch methods, then the container MUST call AsyncContext.complete.

However, glassfish seems not to call AsyncContext.complete() if AsyncLister.onError() or Error Page does not call AsyncContext.complete().
Therefore, my sample application always waits until async timeout(glassfish default 30 seconds).

In addition, glassfish does not call complete() in case of async timeout of dispatch().
But if I use start() method for async processing, complete() is called in case of async timeout.

Is this a bug?
Otherwise, is my understanding of the specification wrong?



 Comments   
Comment by Shing Wai Chan [ 27/Nov/12 ]

Sending AsyncContextImpl.java
Sending Request.java
Transmitting file data ..
Committed revision 57176.

Comment by winston_jack [ 20/Dec/12 ]

I tried to apply the same fix(rev. 57176) to Glassfish 3.1.2.2.
However, it didn't work well.
It is because ErrorReportValve calls org.apache.catalina.connector.Response#reset(),
and com.sun.grizzly.tcp.Response#reset().
In com.sun.grizzly.tcp.Response#reset(), isSuspended flag is set to false,
and Response is recycled.
Therefore, org.apache.catalina.connector.Request#errorDispatchAndComplete(Throwable) throws IllegalStateException
which is generated in com.sun.grizzly.tcp.Response#resume() because isSuspended is set to false.

Do you have any good ideas to solve it?

Comment by Shing Wai Chan [ 20/Dec/12 ]

In trunk, I have tested http://localhost:8080/asynctest/test and see the following in the log:
[#|2012-12-20T12:12:20.368-0800|INFO|44.0|javax.enterprise.logging.stdout|_ThreadID=82;_ThreadName=glassfish-web-async-thread-1;_TimeMillis=1356034340368;_LevelValue=800;|onComplete|#]

The async code has changed between 3.* and trunk.
Can you try to use the the GlassFish in trunk.

Comment by winston_jack [ 22/Dec/12 ]

In Glassfish 4.0b65, this problem seemed to be fixed.
Thank you for your contribution.

However, I need the patch to Glassfish 3.x.

While it may not be appropriate to ask in this comment,
I want to know the roadmap (schedule) of Glassfish 3.x.
Do you know Glassfish 3.1.2.3 (or 3.2) will be released?,
and is this problem fixed in 3.1.2.3 (or 3.2)?

If 3.1.2.3 (or 3.2) will be released,
I'd like to report some problems about servlet asynchronous processing.





[GLASSFISH-19279] Build Java EE 7 javadocs Created: 02/Nov/12  Updated: 10/Dec/12  Resolved: 10/Dec/12

Status: Resolved
Project: glassfish
Component/s: build_system
Affects Version/s: 4.0_b61
Fix Version/s: 4.0_b65

Type: Improvement Priority: Critical
Reporter: Joe Di Pol Assignee: Romain Grécourt
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Dependency
blocks GLASSFISH-19280 Include Java EE 7 javadocs in installer Resolved
Related
is related to GLASSFISH-19259 Java EE 7: javaee-api.jar Resolved

 Description   

We need to start generating Java EE 7 javadocs as part of our build process.



 Comments   
Comment by Romain Grécourt [ 02/Nov/12 ]

new build process and new workspace is needed. This is not going to be done under the glassfish workspace.

Comment by Romain Grécourt [ 10/Dec/12 ]

See http://dlc.sun.com.edgesuite.net/glassfish/4.0/promoted/javaee-api-7.0-b65-javadoc.jar





[GLASSFISH-19392] Move osgi-container from appserver to nucleus Created: 28/Nov/12  Updated: 28/Nov/12  Resolved: 28/Nov/12

Status: Resolved
Project: glassfish
Component/s: packaging
Affects Version/s: 4.0_b63
Fix Version/s: 4.0_b65

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


 Comments   
Comment by Sanjeeb Sahoo [ 28/Nov/12 ]

svn:
https://svn.java.net/svn/glassfish~svn/trunk/main@57185





[GLASSFISH-19369] Change session id before displaying the login form Created: 27/Nov/12  Updated: 27/Nov/12  Resolved: 27/Nov/12

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

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


 Description   

We would like to port the following changes to GlassFish:

In FormAuthenticator: If it is configured to change Session IDs,
do the change before displaying the login form.

http://svn.apache.org/viewvc?view=revision&revision=1408043



 Comments   
Comment by Shing Wai Chan [ 27/Nov/12 ]

Sending FormAuthenticator.java
Transmitting file data .
Committed revision 57121.





Generated at Mon Apr 27 17:57:07 UTC 2015 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.