[WEBSOCKET_SPEC-2] TCK/RI license terms prevent EC evaluation Created: 02/Mar/12  Updated: 30/Oct/12  Resolved: 30/Oct/12

Status: Closed
Project: websocket-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Task Priority: Major
Reporter: starksm64 Assignee: dannycoward
Resolution: Invalid Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Not withstanding the current claim that Section 4B of the JSPA 2 allows an "evaluation license to members of the EC", the wording of Section 4B does not explicitly name the Executive Committee:

B. Grants to Other Expert Group Members. You hereby grant to Member represented on any
Expert Group on which You are also represented under Your applicable patents, copyrights and trade secret
rights which You currently have or may acquire in the future a perpetual, non-exclusive, worldwide, royalty free,
fully paid-up, irrevocable license to use Your Contributions for research and development purposes
related to the activities of such Expert Group. Similarly, Oracle makes the same grant to You with respect to its
Contributions concerning Expert Groups on which You are represented. These grants, from You to other
Members and from Oracle to You, shall not include distribution to third parties of early access implementations
of the Spec under development by Your Expert Group until the draft Spec has been released for Public
Review.

This needs to be spelled out explicitly.

Further, in the interest of transparency, JCP members should be able to provide input on the validity of RIs and TCKs without the burdon of having to become licensees of the technology.



 Comments   
Comment by dannycoward [ 30/Oct/12 ]

This is the venue for tracking technical issues with the JSR 356 specification.

I am closing this issue because it isn't a technical; this is not the right venue for a discussion about the legal aspects of Oracle's TCK License.

Scott, I am going to ask you to raise this at in JCP Executive Committee directly through your representative, Mark Little.





[WEBSOCKET_SPEC-1] TCK license conflicts with JCP 2.8 section 1.4 Created: 02/Mar/12  Updated: 30/Oct/12  Resolved: 30/Oct/12

Status: Closed
Project: websocket-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Task Priority: Major
Reporter: starksm64 Assignee: dannycoward
Resolution: Invalid Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: PDF File SATCK JSR 356 JavaAPI for Web Sockets 1.0 redline 2 29 12.pdf    

 Description   

There are several statements in the TCK license that appear to conflict with the following requirement from JCP 2.8:

"TCK license terms must permit implementors to freely and publicly discuss the testing process and detailed TCK test results with all interested parties."



 Comments   
Comment by starksm64 [ 02/Mar/12 ]

Items that continue be in conflict with the requirement include the following from section 2.1(b) of the attached TCK redline document:

(iv) develop other test suites intended to validate compatibility with the Java Specification(s) to which the TCK(s) licensed hereunder corresponds; or

(vi) use the TCK to make claims of comparative compatibility (for example, a claim either that a Product is “90% compatible” or that the Product is “more compatible” than another implementation of the same Java Specification).

Comment by dannycoward [ 30/Oct/12 ]

This is the venue for tracking technical issues with the JSR 356 specification.

I am closing this issue because it isn't a technical; this is not the right venue for a discussion about the legal aspects of Oracle's TCK License.

Scott, I am going to ask you to raise this at in JCP Executive Committee directly through your representative, Mark Little.





[WEBSOCKET_SPEC-172] Define what Exception should be thrown if Session#addMessageHandler, Session#close, Session#getRemote called on already closed Session instance. Created: 13/Mar/13  Updated: 19/Mar/13  Resolved: 19/Mar/13

Status: Closed
Project: websocket-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: stepan.kopriva Assignee: dannycoward
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: final

 Description   

Session#close wouldn't throw exception since it needs to adhere to Closeable#close() contract.

I would think it would be IllegalStateException in other cases.



 Comments   
Comment by stepan.kopriva [ 14/Mar/13 ]

OK I agree, but I think it needs to be designed which Session methods should throw the exception and when.
For example if Session#addMessageHandler throws exception, should Session#removeMessageHandler throw one etc.

Comment by dannycoward [ 18/Mar/13 ]

There is a class level comment:-

  • <p>Once the session is closed, it is no longer valid for use by applications. Calling any of
  • its methods once the session has been closed will result in an {@link java.lang.IllegalStateException}

    being thrown.

  • Developers should retrieve any information from the session during the
  • {@link Endpoint#onClose }

    method.

is that specific enough ?

BTW: I think once the session is closed calling close again is weird. I think IllegalState is good for that particular case too.

Comment by jitu [ 18/Mar/13 ]

Session#close need to follow Closeable#close semantics since Session is implementing Closeable. Closeable#close allows closing an object multiple times without throwing an exception.

Comment by dannycoward [ 19/Mar/13 ]

closing this since 174 has more detail.





[WEBSOCKET_SPEC-48] Clarify precedence of MessageHandler calling in the case where there are multiple handlers Created: 22/Oct/12  Updated: 09/Nov/12  Due: 09/Nov/12  Resolved: 09/Nov/12

Status: Closed
Project: websocket-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: dannycoward Assignee: dannycoward
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

For example, if there is an AsyncText, Text handlers added to the session - which gets called ?

What happens if the incoming message is async and there is only a Text handler ? (should specify).



 Comments   
Comment by dannycoward [ 09/Nov/12 ]

Duplicate of 39





[WEBSOCKET_SPEC-40] Defer ability to subclass Endpoint to next version. Just rely on POJOs Created: 17/Oct/12  Updated: 29/Oct/12  Resolved: 29/Oct/12

Status: Closed
Project: websocket-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: dannycoward Assignee: Unassigned
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

As summary. Some people think we should not have programmatic APIs for creating endpoints.



 Comments   
Comment by dannycoward [ 29/Oct/12 ]

Closing because this is a duplicate of issue 14, so we will deal with the feedback there.





[WEBSOCKET_SPEC-31] Specify relationship between Web Socket Session and HttpSession Created: 17/Oct/12  Updated: 30/Nov/12  Due: 09/Nov/12  Resolved: 30/Nov/12

Status: Closed
Project: websocket-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Task Priority: Major
Reporter: dannycoward Assignee: dannycoward
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

What we want is to be able to prevent httpsessions timing out when web socket connections with that user are active.

One solution is to set the cookie to never expire on the http opening handshake response, and to use httpsession.setMaxInactiveInterval() to a negative value.

http://docs.oracle.com/javaee/5/api/javax/servlet/http/HttpSession.html#setMaxInactiveInterval%28int%29

We are exploring what other (better) ways we can achieve this.



 Comments   
Comment by Martin Matula [ 09/Nov/12 ]

This is a duplicate of WEBSOCKET_SPEC-5

Comment by dannycoward [ 30/Nov/12 ]

duplicate of issue #5





[WEBSOCKET_SPEC-21] How many Endpoint instances ? Created: 12/Oct/12  Updated: 03/Nov/12  Due: 09/Nov/12  Resolved: 03/Nov/12

Status: Closed
Project: websocket-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: dannycoward Assignee: dannycoward
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Clearly we need at least one Endpoint instance per VM. Should the spec simplify this to say 'exactly one' ? Then the programmer can rely on being able to save state in the endpoint instance in that VM.



 Comments   
Comment by dannycoward [ 03/Nov/12 ]

More recent feedback is guiding us towards having one instance per connection.

Comment by dannycoward [ 03/Nov/12 ]

of 37





[WEBSOCKET_SPEC-19] Encoder/Decoder mechanism: Can we reuse the JAX-RS scheme ? Created: 12/Oct/12  Updated: 09/Nov/12  Due: 09/Nov/12  Resolved: 09/Nov/12

Status: Closed
Project: websocket-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: dannycoward Assignee: dannycoward
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Will research this.



 Comments   
Comment by dannycoward [ 09/Nov/12 ]

Duplicate of 25





[WEBSOCKET_SPEC-125] ServerApplicationConfiguration should be renamed Created: 28/Jan/13  Updated: 08/Feb/13  Resolved: 08/Feb/13

Status: Closed
Project: websocket-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: stepan.kopriva Assignee: Unassigned
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

According to the spec, there may be more than one ServerApplicationConfiguration classes in the application. In that case ServerApplicationConfiguration should be renamed to something else, as it is not application configuration.



 Comments   
Comment by dannycoward [ 01/Feb/13 ]

any suggestions ?

how about ServerDeployentFilter ?

Comment by dannycoward [ 08/Feb/13 ]

This hasn't been resolved, but I've added it to http://java.net/jira/browse/WEBSOCKET_SPEC-9 which deals with a fe renaming issues. We need to consider all the potential renames at once, so we have a consistent look.

So I'm closing it as a duplicated and tracking it in 9 instead.





Generated at Wed Apr 26 18:09:59 UTC 2017 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.