Search Results

Search found 296 results on 12 pages for 'jsr'.

facebook twitter digg google delicious technorati stumbleupon myspace wordpress linkedin gmail igoogle windows live tumblr viadeo yahoo buzz yahoo mail yahoo bookmarks favorites email print

Page 2/12 | < Previous Page | 1 2 3 4 5 6 7 8 9 10 11 12  | Next Page >

  • EL 3.0 Public Review - JSR 341 and Java EE 7 Moving Along

    - by arungupta
    Following closely on the lines of EL 3.0 Early Draft, the specification is now available for a Public Review. The JCP2 Process Document defines different stages of the specifications. This review period closes Jul 30, 2012. Some of the main goals of the JSR are to separate ELContext into parsing and evaluation contexts, adding operators like equality, string concatenation, etc, and integration with CDI. The section A.7 of the specification highlights the difference between Early Draft and Public Review. Download the Public Review and and follow the updates at el-spec.java.net. For more information about EL 3.0 (JSR 341), check out the JSR project on java.net. The archives of EG discussion are available at jsr341-experts and you can subscribe to the users@el-spec and other aliases on the Mailing Lists page.

    Read the article

  • Adopt a Java EE 7 JSR!

    - by reza_rahman
    Broad community participation is key to the success of any technology worth it's salt. The Adopt-a-JSR program was launched in recognition of this fact. It is an initiative by some key JUG leaders around the World to encourage JUG members to get involved in a JSR and to evangelize that JSR to their JUG and the wider Java community, in order to increase grass roots participation. There are a number of JUGs that have already jumped in like the Chennai JUG, SouJava, London Java Community, BeJUG, GoJava, Morrocco JUG, Campinas JUG and ItpJava. Note that any developer can participate, there isn't a need to be a JUG leader. There are a number of Java EE 7 JSRs that could use your help right now including WebSocket, JSON, Caching, Concurrency for EE, JAX-RS2 and JMS2. Find out more here.

    Read the article

  • Devoxx UK JCP & Adopt-a-JSR activities

    - by Heather VanCura
    Devoxx UK starts this week!  The JCP Program is organizing many activities throughout the conference, including some tables in the Hackergarten area on 12-13 June.  Topics include Java EE, Data Grids, Java SE 8 (Lambdas and Date & Time API), Money & Currency API and OpenJDK.  We will have two book signings by Richard Warburton and Peter Pilgrim during the Hackergarten - free signed copy of their books at these times - first come, first served (limited quantities available).  Thursday night is the party and the Birds of a Feather (BoF) sessions - come with your favorite questions and topics related to the JCP, Adopt-a-JSR and Adopt OpenJDK Programs!  See below for the schedule of activities; I will fill in details for each session tomorrow.    Thursday 12 June 10:20 - 12:50 Java EE -- Arun Gupta 13:30-17:00 Lambdas/Date & Time API --Richard Warburton & Raoul-Gabriel Urma (also a book signing with Richard Warburon during the afternoon break) 14:30-17:30 Data Grids - Peter Lawrey 14:30-18:00 Money & Currency -- Anatole Tresch 18:45 Adopt OpenJDK BoF session (Java EE BoF runs concurrently) 19:45 JCP & Adopt-a-JSR BoF session Friday 13 June 10:20-13:00 OpenJDK -- Mani Sarkar  10:20- 14:30 Money & Currency -- Anatole Tresch 10:20 - 13:00 Java EE -- Peter Pilgrim 13:00-13:30 Peter Pilgrim Java EE 7 Book signing sponsored by JCP @ lunch time 13:30 - 15:30 JCP.Next/JSR 364 -- Heather VanCura

    Read the article

  • JSR-107 Early Draft Released

    - by rob.misek
    After nearly 12 years the early draft of JSR-107 has been released. Brian Oliver, co-spec lead, details this update including information on the source, resourcing and the JCP 2.7 process. Check out Brian's update here. "Yesterday the JCP made the important step of posting the Early Draft specification and API for JSR107. [...]While an enormous amount of progress was made last year and early this year (by many people – not so much me) the JSR was somewhat delayed while the legals were resolved, especially with respect to ensuring clean and clear IP for Java itself, the eventual JCache Providers and the community.   Thankfully this stage is complete and we can move forward."

    Read the article

  • JSR 355 Final Release, and moves JCP to version 2.9

    - by heathervc
    JSR 355, JCP EC Merge, passed the JCP EC Final Approval Ballot on 13 August 2012, with 14 Yes votes, 1 abstain (1 member did not vote) on the SE/EE EC, and 12 yes votes (2 members were not eligible to vote) on the ME EC.  JSR 355 posted a Final Release this week, moving the JCP program version to JCP 2.9.  The transition to a merged EC will happen after the 2012 EC Elections, as defined in the Appendix B of the JCP (pasted below), and the EC will operate under the new EC Standing Rules. In the previous version (2.8) of this Process Document there were two separate Executive Committees, one for Java ME and one for Java SE and Java EE combined. The single Executive Committee described in this version of the Process Document will be implemented through the following process: The 2012 annual elections will be held as defined in JCP 2.8, but candidates will be informed that if they are elected their term will be for only a single year, since all candidates must stand for re-election in 2013. Immediately after the 2012 election the two ECs will be merged. Oracle and IBM's second seats will be eliminated, resulting in a single EC with 30 members. All subsequent JSR ballots (even for in-progress JSRs) will then be voted on by the merged EC. For the 2013 annual elections three Ratified and two Elected Seats will be eliminated, thereby reducing the EC to 25 members. All 25 seats will be up for re-election in 2013. Members elected in 2013 will be ranked to determine whether their initial term will be one or two years. The 50% of Ratified and 50% of Elected members who receive the most votes will serve an initial two-year term, while all others will serve an initial one year term. All members elected in 2014 and subsequently will serve a two-year term. For clarity, note that the provisions specified in this version of the Process Document regarding a merged EC will apply to subsequent ballots on all existing JSRs, whether or not the Spec Leads of those JSRs chose to adopt this version of the Process Document in its entirety. <end of Appendix> Also of note:  the materials and minutes from the July EC meeting and the June EC Meeting are now available--following the July EC Meeting, Samsung and SK Telecom lost their EC seats. The June EC meeting also had a public portion--the audio from the public portion of the EC meeting are now posted online.  For Spec Leads there is also the recording of the EG Nominations call.

    Read the article

  • Global Adopt a JSR Program Update

    - by heathervc
    The Global Adopt a JSR program, combining efforts of SouJava and London Java Community,  is an excellent place to get some Java User Group (JUG) resources for JSRs.  It also has the potential to act as an extra set of eyes, ears and volunteers for JSRs. The Global project to go to is at: http://adoptajsr.java.net.  The wiki page explaining the whole program and benefits to Spec Leads and EG's can be found there, including: The mailing list: [email protected] . Portugese speakers-mainly Brazlian JUG members-have their own mailing list and more language lists may be added as required. The IRC channel is at adoptajsr on irc.freenode.net Also check out this InfoQ article with Martijn Verburg about the London Java user group, the Adopt a JSR program, the JCP and Oracle’s handling of the Java community.

    Read the article

  • JSR updates - First Merged EC Ballots

    - by Heather VanCura
    As the second part of the JCP.Next effort, JCP 2.9 launched 2 weeks ago on 13 November, and the first JCP EC ballots with the Merged EC have concluded.   JSR 339, JAX-RS 2.0: The Java API for RESTful Web Services, passed EC Public Review Ballot and was approved by the EC -- 22 yes votes, 2 abstain, 2 did not vote -- view results. JSR 349, Bean Validation 1.1, passed EC Public Review Ballot and was approved by the EC --17 yes votes, 2 abstain, 5 did not vote --  view results.

    Read the article

  • Java EE 7 Status Update - November 2012

    - by arungupta
    Here is a quick status update on different components that are targeted to be included in the Java EE 7 Platform: Java EE 7 Platform (JSR 342) - Early Draft 2 (list, project, javadocs ?) Java Persistence API 2.1 (JSR 338) - Early Draft 2 (list, project, javadocs ?) Java API for RESTful Web Services 2.0 (JSR 339) - Public Review (list, project, javadocs) Servlets 3.1 (JSR 340) - Early Draft (list, project, javadocs ?) Expression Language 3.0 (JSR 341) - Public Review (list, project, javadocs ?) Java Message Service 2.0 (JSR 343) - Early Draft (list, project, javadocs) JavaServer Faces 2.2 (JSR 344) - Early Draft (list, project, javadocs ?) Enterprise JavaBeans 3.2 (JSR 345) - Early Draft (list, project, javadocs ?) Context & Dependency Injection 1.1 (JSR 346) - Early Draft (list, project, javadocs) Bean Validation 1.1 (JSR 349) - Public Review (list, project, javadocs ?) JCACHE Java Temporary Caching API (JSR 107) - Early Draft (list, project, javadocs) Batch Applications for the Java Platform (JSR 352) - Early Draft (list, project, javadocs) Java API for JSON Processing (JSR 353) - Early Draft (list, project, javadocs) Java API for WebSocket (JSR 356) - Early Draft (list, project, javadocs) As evident, all the components have released at least an Early Draft specification. Some have released second Early Draft and some even have a Public Review in different stages. Several implementations are already integrated in GlassFish 4. Promoted Builds. Which ones are you tracking or contributing ? Make sure to file an issue so that your usecase and needs are addressed. Download GlassFish 4. Promoted Build and provide feedback.  

    Read the article

  • Inactive JSRs looking for Spec Leads

    - by heathervc
    You may have noticed that some JSRs have a classification of "Inactive" on their JSR page.  The introduction of this term in 2009 was part of an effort to enable and encourage more transparency into the development of JSRs.  You can read more about Inactive JSRs here and also in the JCP FAQ.The following JSR proposals have been Inactive since at least 2009. If you are a JCP Member and are interested in taking over the Specification Lead role for one of these JSRs, please contact the PMO at [email protected] on or before 23 April 2012. With that message, please include the following: the subject line "Spec Lead for JSR ###," where '###' is the JSR number which JCP Member you represent why you wish to take over the Specification lead role Here is the current list of Inactive JSRs for which Members can request to become Specification Leads: JSR 122, JAIN JCAT JSR 161, JAIN ENUM API Specification JSR 182, JPay - Payment API for the Java Platform JSR 210, OSS Service Quality Management API JSR 241, The Groovy Programming Language JSR 251, Pricing API JSR 278, Resource Management API for Java ME JSR 304, Mobile Telephony API v2 JSR 305, Annotations for Software Defect Detection JSR 320, Services Framework

    Read the article

  • JSR 308 Moves Forward

    - by abuckley
    I am pleased to announce a number of recent milestones for JSR 308, Annotations on Java Types: Adoption of JCP 2.8 Thanks to the agreement of the Expert Group, JSR 308 operates under JCP 2.8 from September 2012. There is a publicly archived mailing list for EG members, and a companion list for anyone who wishes to follow EG traffic by email. There is also a "suggestion box" mailing list where anyone can send feedback to the E.G. directly. Feedback will be discussed on the main EG list. Co-spec lead Prof. Michael Ernst maintains an issue tracker and a document archive. Early-Access Builds of the Reference Implementation Oracle has published binaries for all platforms of JDK 8 with support for type annotations. Builds are generated from OpenJDK's type-annotations/type-annotations forest (notably the langtools repo). The forest is owned by the Type Annotations project. Integration with Enhanced Metadata On the enhanced metadata mailing list, Oracle has proposed support for repeating annotations in the Java language in Java SE 8. For completeness, it must be possible to repeat annotations on types, not only on declarations. The implementation of repeating annotations on declarations is already in the type-annotations/type-annotations forest (and hence in the early-access builds above) and work is underway to extend it to types.

    Read the article

  • Concurrency Utilities for Java EE Early Draft (JSR 236)

    - by arungupta
    Concurrency Utilities for Java EE is being worked as JSR 236 and has released an Early Draft. It provides concurrency capabilities to Java EE application components without compromising container integrity. Simple (common) and advanced concurrency patterns are easily supported without sacrificing usability. Using Java SE concurrency utilities such as java.util.concurrent API, java.lang.Thread and java.util.Timer in a Java EE application component such as EJB or Servlet are problematic since the container and server have no knowledge of these resources. JSR 236 enables concurrency largely by extending the Concurrency Utilities API developed under JSR-166. This also allows a consistency between Java SE and Java EE concurrency programming model. There are four main programming interfaces available: ManagedExecutorService ManagedScheduledExecutorService ContextService ManagedThreadFactory ManagedExecutorService is a managed version of java.util.concurrent.ExecutorService. The implementations of this interface are provided by the container and accessible using JNDI reference: <resource-env-ref>  <resource-env-ref-name>    concurrent/BatchExecutor  </resource-env-ref-name>  <resource-env-ref-type>    javax.enterprise.concurrent.ManagedExecutorService  </resource-env-ref-type><resource-env-ref> and available as: @Resource(name="concurrent/BatchExecutor")ManagedExecutorService executor; Its recommended to bind the JNDI references in the java:comp/env/concurrent subcontext. The asynchronous tasks that need to be executed need to implement java.lang.Runnable or java.util.concurrent.Callable interface as: public class MyTask implements Runnable { public void run() { // business logic goes here }} OR public class MyTask2 implements Callable<Date> {  public Date call() { // business logic goes here   }} The task is then submitted to the executor using one of the submit method that return a Future instance. The Future represents the result of the task and can also be used to check if the task is complete or wait for its completion. Future<String> future = executor.submit(new MyTask(), String.class);. . .String result = future.get(); Another example to submit tasks is: class MyTask implements Callback<Long> { . . . }class MyTask2 implements Callback<Date> { . . . }ArrayList<Callable> tasks = new ArrayList<();tasks.add(new MyTask());tasks.add(new MyTask2());List<Future<Object>> result = executor.invokeAll(tasks); The ManagedExecutorService may be configured for different properties such as: Hung Task Threshold: Time in milliseconds that a task can execute before it is considered hung Pool Info Core Size: Number of threads to keep alive Maximum Size: Maximum number of threads allowed in the pool Keep Alive: Time to allow threads to remain idle when # of threads > Core Size Work Queue Capacity: # of tasks that can be stored in inbound buffer Thread Use: Application intend to run short vs long-running tasks, accordingly pooled or daemon threads are picked ManagedScheduledExecutorService adds delay and periodic task running capabilities to ManagedExecutorService. The implementations of this interface are provided by the container and accessible using JNDI reference: <resource-env-ref>  <resource-env-ref-name>    concurrent/BatchExecutor  </resource-env-ref-name>  <resource-env-ref-type>    javax.enterprise.concurrent.ManagedExecutorService  </resource-env-ref-type><resource-env-ref> and available as: @Resource(name="concurrent/timedExecutor")ManagedExecutorService executor; And then the tasks are submitted using submit, invokeXXX or scheduleXXX methods. ScheduledFuture<?> future = executor.schedule(new MyTask(), 5, TimeUnit.SECONDS); This will create and execute a one-shot action that becomes enabled after 5 seconds of delay. More control is possible using one of the newly added methods: MyTaskListener implements ManagedTaskListener {  public void taskStarting(...) { . . . }  public void taskSubmitted(...) { . . . }  public void taskDone(...) { . . . }  public void taskAborted(...) { . . . } }ScheduledFuture<?> future = executor.schedule(new MyTask(), 5, TimeUnit.SECONDS, new MyTaskListener()); Here, ManagedTaskListener is used to monitor the state of a task's future. ManagedThreadFactory provides a method for creating threads for execution in a managed environment. A simple usage is: @Resource(name="concurrent/myThreadFactory")ManagedThreadFactory factory;. . .Thread thread = factory.newThread(new Runnable() { . . . }); concurrent/myThreadFactory is a JNDI resource. There is lot of interesting content in the Early Draft, download it, and read yourself. The implementation will be made available soon and also be integrated in GlassFish 4 as well. Some references for further exploring ... Javadoc Early Draft Specification concurrency-ee-spec.java.net [email protected]

    Read the article

  • Project Coin: JSR 334 has a Proposed Final Draft

    - by darcy
    Reaching nearly the last phase of the JCP process, JSR 334 now has a proposed final draft. There have been only a few refinements to the specification since public review: Incorporated language changes into JLS proper. Forbid combining diamond and explicit type arguments to a generic constructor. Removed unusual protocol around Throwable.addSuppressed(null) and added a new constructor to Throwable to allow suppression to be disabled. Added disclaimers that OutOfMemoryError, NullPointerException, and ArithmeticException objects created by the JVM may have suppression disabled. Added thread safely requirements to Throwable.addSuppressed and Throwable.getSuppressed. Next up is the final approval ballot; almost there!

    Read the article

  • JCP 2012 Award Nominations Announced

    - by heathervc
      The 10th Annual JCP Program Award Nominations have been posted on JCP.org.  The community gets together every year during JavaOne to congratulate the winners and nominees at the JCP Community Party held in San Francisco. This year there are three awards: JCP Member/Participant of the Year, Outstanding Spec Lead, and Most Significant JSR. Member of the Year: Stephen Colebourne Markus Eisele Google JUG Chennai Werner Keil London Java Community and SouJava Antoine Sabot-Durand Outstanding Spec Lead Michael Ernst, JSR 308, Annotations on Java Types Victor Grazi, Credit Suisse, JSR 354, Money and Currency API Nigel Deakin, Oracle, JSR 343, Java Message Service 2.0 Pete Muir, Red Hat, JSR 346, Contexts and Dependency Injection for Java EE 1.1 Most Significant JSR API for JSON Processing, JSR 353 Money and Currency API, JSR  354 Java State Management, JSR 350 Java Message Service 2, JSR 343 JCP.Next, JSR 348, JSR 355, and JSR 358 Congratulations to the nominees; you can read the nomination text and more information about the awards here.  And remember to join us on Tuesday, 2 October at the Infusion Lounge to celebrate with the winners and nominees!

    Read the article

  • Java Spotlight Episode 75: Greg Luck on JSR 107 Java Temporary Caching API

    - by Roger Brinkley
    Tweet Recorded live at Jfokus 2012, an interview with Greg Luck on JSR 107 Java Temporary Caching API. Joining us this week on the Java All Star Developer Panel is Alexis Moussine-Pouchkine, Java EE Developer Advocate. Right-click or Control-click to download this MP3 file. You can also subscribe to the Java Spotlight Podcast Feed to get the latest podcast automatically. If you use iTunes you can open iTunes and subscribe with this link:  Java Spotlight Podcast in iTunes. Show Notes News JavaOne 2012 call for papers is open (closes April 9th) LightFish, Adam Bien's lightweight telemetry application Java EE 6 sample code JavaFX 1.2 and 1.3 EOL Repeating Annotations in the Works Events March 26-29, EclipseCon, Reston, USA March 27, Virtual Developer Days - Java (Asia Pacific (English)),9:30 am to 2:00pm IST / 12:00pm to 4.30pm SGT  / 3.00pm - 7.30pm AEDT April 4-5, JavaOne Japan, Tokyo, Japan April 12, GreenJUG, Greenville, SC April 17-18, JavaOne Russia, Moscow Russia April 18–20, Devoxx France, Paris, France April 26, Mix-IT, Lyon, France, May 3-4, JavaOne India, Hyderabad, India Feature Interview Greg Luck founded Ehcache in 2003. He regularly speaks at conferences, writes and codes. He has also founded and maintains the JPam and Spnego open source projects, which are security focused. Prior to joining Terracotta in 2009, Greg was Chief Architect at Wotif.com where he provided technical leadership as the company went from a single product startup to a billion dollar public company with multiple product lines. Before that Greg was a consultant for ThoughtWorks with engagements in the US and Australia in the travel, health care, geospatial, banking and insurance industries. Before doing programming, Greg managed IT. He was CIO at Virgin Blue, Tempo Services, Stamford Hotels and Resorts and Australian Resorts. He is a Chartered Accountant, and spent 7 years with KPMG in small business and insolvency. Mail Bag What’s Cool RT @harkje: To update an earlier tweet: #JavaFX feels like Swing with added convenience methods, better looking widgets, nice effects and...

    Read the article

  • Spring + JSR 303 Validation group is ignored [closed]

    - by nsideras
    we have a simple bean with JSR annotations public class CustomerDTO { private static final long serialVersionUID = 1L; private Integer id; @NotEmpty(message = "{customer.firstname.empty}") private String firstName; @NotEmpty(message = "{customer.lastname.empty}") private String lastName; @NotEmpty(groups={PasswordChange.class}, message="{password.empty}") private String password; @NotEmpty(groups={PasswordChange.class}, message="{confirmation.password.empty}") private String password2; } and we have a Spring Controller @RequestMapping(value="/changePassword", method = RequestMethod.POST) public String changePassword(@Validated({ PasswordChange.class }) @ModelAttribute("customerdto") CustomerDTO customerDTO, BindingResult result, Locale locale) { logger.debug("Change Password was submitted with information: " + customerDTO.toString()); try { passwordStrengthPolicy.checkPasswordStrength(locale, customerDTO.getPassword()); if (result.hasErrors()) { return "changePassword"; } logger.debug("Calling customer service changePassword: " + customerDTO); customerOnlineNewService.changePassword(customerDTO); } catch (PasswordNotChangedException e) { logger.error("Could not change password PasswordNotChangedException: " + customerDTO.toString()); return "changePassword"; } catch (PasswordNotSecureException e) { return "changePassword"; } return createRedirectViewPath("changePassword"); } Our problem is that when changePassword is invoked the validator ignores the group(PasswordChange.class) and validates only firstName and lastName which are not in the group. Any idea? Thank you very much for your time.

    Read the article

  • WebSocket and Java EE 7 - Getting Ready for JSR 356 (TOTD #181)

    - by arungupta
    WebSocket is developed as part of HTML 5 specification and provides a bi-directional, full-duplex communication channel over a single TCP socket. It provides dramatic improvement over the traditional approaches of Polling, Long-Polling, and Streaming for two-way communication. There is no latency from establishing new TCP connections for each HTTP message. There is a WebSocket API and the WebSocket Protocol. The Protocol defines "handshake" and "framing". The handshake defines how a normal HTTP connection can be upgraded to a WebSocket connection. The framing defines wire format of the message. The design philosophy is to keep the framing minimum to avoid the overhead. Both text and binary data can be sent using the API. WebSocket may look like a competing technology to Server-Sent Events (SSE), but they are not. Here are the key differences: WebSocket can send and receive data from a client. A typical example of WebSocket is a two-player game or a chat application. Server-Sent Events can only push data data to the client. A typical example of SSE is stock ticker or news feed. With SSE, XMLHttpRequest can be used to send data to the server. For server-only updates, WebSockets has an extra overhead and programming can be unecessarily complex. SSE provides a simple and easy-to-use model that is much better suited. SSEs are sent over traditional HTTP and so no modification is required on the server-side. WebSocket require servers that understand the protocol. SSE have several features that are missing from WebSocket such as automatic reconnection, event IDs, and the ability to send arbitrary events. The client automatically tries to reconnect if the connection is closed. The default wait before trying to reconnect is 3 seconds and can be configured by including "retry: XXXX\n" header where XXXX is the milliseconds to wait before trying to reconnect. Event stream can include a unique event identifier. This allows the server to determine which events need to be fired to each client in case the connection is dropped in between. The data can span multiple lines and can be of any text format as long as EventSource message handler can process it. WebSockets provide true real-time updates, SSE can be configured to provide close to real-time by setting appropriate timeouts. OK, so all excited about WebSocket ? Want to convert your POJOs into WebSockets endpoint ? websocket-sdk and GlassFish 4.0 is here to help! The complete source code shown in this project can be downloaded here. On the server-side, the WebSocket SDK converts a POJO into a WebSocket endpoint using simple annotations. Here is how a WebSocket endpoint will look like: @WebSocket(path="/echo")public class EchoBean { @WebSocketMessage public String echo(String message) { return message + " (from your server)"; }} In this code "@WebSocket" is a class-level annotation that declares a POJO to accept WebSocket messages. The path at which the messages are accepted is specified in this annotation. "@WebSocketMessage" indicates the Java method that is invoked when the endpoint receives a message. This method implementation echoes the received message concatenated with an additional string. The client-side HTML page looks like <div style="text-align: center;"> <form action=""> <input onclick="send_echo()" value="Press me" type="button"> <input id="textID" name="message" value="Hello WebSocket!" type="text"><br> </form></div><div id="output"></div> WebSocket allows a full-duplex communication. So the client, a browser in this case, can send a message to a server, a WebSocket endpoint in this case. And the server can send a message to the client at the same time. This is unlike HTTP which follows a "request" followed by a "response". In this code, the "send_echo" method in the JavaScript is invoked on the button click. There is also a <div> placeholder to display the response from the WebSocket endpoint. The JavaScript looks like: <script language="javascript" type="text/javascript"> var wsUri = "ws://localhost:8080/websockets/echo"; var websocket = new WebSocket(wsUri); websocket.onopen = function(evt) { onOpen(evt) }; websocket.onmessage = function(evt) { onMessage(evt) }; websocket.onerror = function(evt) { onError(evt) }; function init() { output = document.getElementById("output"); } function send_echo() { websocket.send(textID.value); writeToScreen("SENT: " + textID.value); } function onOpen(evt) { writeToScreen("CONNECTED"); } function onMessage(evt) { writeToScreen("RECEIVED: " + evt.data); } function onError(evt) { writeToScreen('<span style="color: red;">ERROR:</span> ' + evt.data); } function writeToScreen(message) { var pre = document.createElement("p"); pre.style.wordWrap = "break-word"; pre.innerHTML = message; output.appendChild(pre); } window.addEventListener("load", init, false);</script> In this code The URI to connect to on the server side is of the format ws://<HOST>:<PORT>/websockets/<PATH> "ws" is a new URI scheme introduced by the WebSocket protocol. <PATH> is the path on the endpoint where the WebSocket messages are accepted. In our case, it is ws://localhost:8080/websockets/echo WEBSOCKET_SDK-1 will ensure that context root is included in the URI as well. WebSocket is created as a global object so that the connection is created only once. This object establishes a connection with the given host, port and the path at which the endpoint is listening. The WebSocket API defines several callbacks that can be registered on specific events. The "onopen", "onmessage", and "onerror" callbacks are registered in this case. The callbacks print a message on the browser indicating which one is called and additionally also prints the data sent/received. On the button click, the WebSocket object is used to transmit text data to the endpoint. Binary data can be sent as one blob or using buffering. The HTTP request headers sent for the WebSocket call are: GET ws://localhost:8080/websockets/echo HTTP/1.1Origin: http://localhost:8080Connection: UpgradeSec-WebSocket-Extensions: x-webkit-deflate-frameHost: localhost:8080Sec-WebSocket-Key: mDbnYkAUi0b5Rnal9/cMvQ==Upgrade: websocketSec-WebSocket-Version: 13 And the response headers received are Connection:UpgradeSec-WebSocket-Accept:q4nmgFl/lEtU2ocyKZ64dtQvx10=Upgrade:websocket(Challenge Response):00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00 The headers are shown in Chrome as shown below: The complete source code shown in this project can be downloaded here. The builds from websocket-sdk are integrated in GlassFish 4.0 builds. Would you like to live on the bleeding edge ? Then follow the instructions below to check out the workspace and install the latest SDK: Check out the source code svn checkout https://svn.java.net/svn/websocket-sdk~source-code-repository Build and install the trunk in your local repository as: mvn install Copy "./bundles/websocket-osgi/target/websocket-osgi-0.3-SNAPSHOT.jar" to "glassfish3/glassfish/modules/websocket-osgi.jar" in your GlassFish 4 latest promoted build. Notice, you need to overwrite the JAR file. Anybody interested in building a cool application using WebSocket and get it running on GlassFish ? :-) This work will also feed into JSR 356 - Java API for WebSocket. On a lighter side, there seems to be less agreement on the name. Here are some of the options that are prevalent: WebSocket (W3C API, the URL is www.w3.org/TR/websockets though) Web Socket (HTML5 Demos - html5demos.com/web-socket) Websocket (Jenkins Plugin - wiki.jenkins-ci.org/display/JENKINS/Websocket%2BPlugin) WebSockets (Used by Mozilla - developer.mozilla.org/en/WebSockets, but use WebSocket as well) Web sockets (HTML5 Working Group - www.whatwg.org/specs/web-apps/current-work/multipage/network.html) Web Sockets (Chrome Blog - blog.chromium.org/2009/12/web-sockets-now-available-in-google.html) I prefer "WebSocket" as that seems to be most common usage and used by the W3C API as well. What do you use ?

    Read the article

  • JCP.next.3: time to get to work

    - by Patrick Curran
    As I've previously reported in this blog, we planned three JSRs to improve the JCP’s processes and to meet our members’ expectations for change. The first - JCP.next.1, or more formally JSR 348: Towards a new version of the Java Community Process - was completed in October 2011. This focused on a small number of simple but important changes to make our process more transparent and to enable broader participation. We're already seeing the benefits of these changes as new and existing JSRs adopt the new requirements. However, because we wanted to complete this JSR quickly we deliberately postponed a number of more complex items, including everything that would require modifying the JSPA (the legal agreement that members sign when they join the organization) to a follow-on JSR. The second JSR (JSR 355: JCP Executive Committee Merge) is in progress now and will complete later this year. This JSR is even simpler than the first, and is focused solely on merging the two Executive Committees into one for greater efficiency and to encourage synergies between the Java ME and Java SE platforms. Continuing the momentum to move Java and the JCP forward we have just filed the third JSR (JCP.next.3) as JSR 358: A major revision of the Java Community Process. This JSR will modify the JSPA as well as the Process Document, and will tackle a large number of complex issues, many of them postponed from JSR 348. For these reasons we expect to spend a considerable amount of time working on it - at least a year, and probably more. The current version of the JSPA was created back in 2002, although some minor changes were introduced in 2005. Since then the organization and the environment in which we operate have changed significantly, and it is now time to revise our processes to ensure that they meet our current needs. We have a long list of topics to be considered, including the role of independent implementations (those not derived from the Reference Implementation), licensing and open source, ensuring that our new transparency requirements are implemented correctly, compatibility policy and TCKs, the role of individual members, patent policy, and IP flow. The Expert Group for JSR 358, as with all process-change JSRs, consists of all members of the Executive Committees. Even though the JSR has just been filed we started discussions on the various topics several months ago (see the EC's meeting minutes for details) and our EC members - including the new members who joined within the last year or two - are actively engaged. Now it's your opportunity to get involved. As required by version 2.8 of our Process (introduced with JSR 348) we will conduct all our business in the open. We have a public java.net project where you can follow and participate in our work. All of our deliberations will be copied to a public Observer mailing list, we'll track our issues on a public Issue Tracker, and all our documents (meeting agendas and minutes, task lists, working drafts) will be published in our Document Archive. We're just getting started, but we do want your input. Please visit us on java.net where you can learn how to participate. Let's get to work...

    Read the article

  • JSR-299 CDI / Weld vs. Google Guice

    - by deamon
    Weld, the JSR-299 Contexts and Dependency Injection reference implementation, considers itself as a kind of successor of Spring and Guice. CDI was influenced by a number of existing Java frameworks, including Seam, Guice and Spring. However, CDI has its own, very distinct, character: more typesafe than Seam, more stateful and less XML-centric than Spring, more web and enterprise-application capable than Guice. But it couldn't have been any of these without inspiration from the frameworks mentioned and lots of collaboration and hard work by the JSR-299 Expert Group (EG). http://docs.jboss.org/weld/reference/latest/en-US/html/1.html What makes Weld more capable for enterprise application compared to Guice? Are there any advantages or disadvantages compared to Guice? What do you think about Guice AOP compared to Weld interceptors? What about performance?

    Read the article

  • JSR 275 - Units, Percent per second

    - by I82Much
    Hi all, I need to represent the unit of Percent per second using the JScience.org's JSR 275 units and measures implementation. I am trying to do to the following: Unit<Dimensionless> PERCENT_PER_SECOND = NonSI.PERCENT.divide(Si.SECOND).asType(Dimensionless.class) but I am getting a ClassCastException when I try to do that. The following works, but I'm not sure if there's a better way: public interface PercentOverTime extends Quantity {} public static Unit<PercentOverTime> PERCENT_PER_SECOND = new BaseUnit<PercentOverTime>("%/s"); Any thoughts? The closest I could find to this is the question on Cooking Measurements (which is how I saw how to define your own units).

    Read the article

  • Possible to create JSR 286 portlet using Coldfusion?

    - by Jakub
    I was just thinking this morning, since ColdFusion is essentially built on JAVA, is it possible to create JSR 286 portlets using coldfusion? A search revealed that it might be possible, but I cannot find any material on this? Reason I ask is because I would love to be able to create Liferay compatible portlets with ColdFusion, as I am not a JAVA dev. Thoughts? Does anyone have any tutorials or references on this subject? EDIT Is there anyways to get CF portlets without CF running in the container? I'm curious how this would work with having only one license of CF. Would I need another license to run under liferay (if I can even run in liferay?)

    Read the article

facebook twitter digg google delicious technorati stumbleupon myspace wordpress linkedin gmail igoogle windows live tumblr viadeo yahoo buzz yahoo mail yahoo bookmarks favorites email print

< Previous Page | 1 2 3 4 5 6 7 8 9 10 11 12  | Next Page >