Links

  • 1. Sogeti
  • 2. JBoss
  • 3. IBM
  • 4. Oracle
  • 5. SpringSource
  • 6. NL-JUG
  • 7. Java

Archives

Syndication  RSS 2.0

RSS 1.0
RSS 2.0

Bookmark this site

Add 'JCN Blog' site to delicious  Add 'JCN Blog' site to technorati  Add 'JCN Blog' site to digg  Add 'JCN Blog' site to dzone

Posted by Patrick Kik at 11:42 on Thursday 27 February    Add 'Custom argument matching with EasyMock' site to delicious  Add 'Custom argument matching with EasyMock' site to technorati  Add 'Custom argument matching with EasyMock' site to digg  Add 'Custom argument matching with EasyMock' site to dzone

EasyMock is a very useful framework when creating unittests. One particular useful feature is the ability to expect the method arguments:

accountService.deleteAccounts(EasyMock.notNull());

But what if these out of the box expectations are not enough? You write your own argument matcher!

Read the rest of this entry »

Posted by Erwin De Gier at 12:47 on Tuesday 28 January    Add 'Mocken van javax.mail.Session met Mock JavaMail' site to delicious  Add 'Mocken van javax.mail.Session met Mock JavaMail' site to technorati  Add 'Mocken van javax.mail.Session met Mock JavaMail' site to digg  Add 'Mocken van javax.mail.Session met Mock JavaMail' site to dzone

Voor het testen van het versturen van email via JavaMail zijn verschillende oplossingen, bijvoorbeeld zelf een mock versie schrijven of zelfs een dummy smtp server gebruiken. Het gebruik van het Mock JavaMail project maakt het echter wel heel makkelijk.

Voeg de volgende depedency toe via maven:

<dependency>     
    <groupId>org.jvnet.mock-javamail </groupId>
    <artifactId>mock-javamail </artifactId>
    <version>1.9</version>
    <scope>test</scope>
</dependency>

Stuur een email vanuit je code via JavaMail:

MimeMessage msg = new MimeMessage();
msg.setRecipients(TO,"mail@test.com");
Transport.send(msg);

Controleer vervolgens in je unit test of deze mail is verstuurd, met behulp van mock-javamail:

List inbox = Mailbox. get(EMAIL_TO);
              
//Controlleer of de email verzonden is
assertEquals(inbox.size(), 1);

Message msg = inbox.remove(0);
              
//Valideer het content type
assertTrue(msg .getContentType().startsWith("text/plain" ));
              
String body = (String) msg.getContent();
              
//Valideer de email body
assertTrue(body.contains( EMAIL_BODY));

//Valideer het onderwerp
assertEquals( EMAIL_SUBJECT, msg.getSubject());
              
//Valideer de to en from emailadressen
assertEquals( EMAIL_TO, msg .getAllRecipients()[0].toString());
assertEquals( EMAIL_FROM, msg.getFrom()[0].toString());

Mock JavaMail gebruikt het plugin mechanisme van JavaMail. Op het moment dat de mock-javamail jar op het classpath staat, dan wordt er een in-memory mailbox gebruikt voor het versturen van de mail.

Posted by Erik-Berndt Scheper at 18:27 on Monday 9 December    Add 'True Hot Swap in Java with DCEVM on OS-X' site to delicious  Add 'True Hot Swap in Java with DCEVM on OS-X' site to technorati  Add 'True Hot Swap in Java with DCEVM on OS-X' site to digg  Add 'True Hot Swap in Java with DCEVM on OS-X' site to dzone

Last Tuesday in the ‘living room session’ held at our HQ in Vianen, Volkert de Buisonje brought my attention to the Dynamic Code Evolution VM (DCEVM) project which describes itself as “a modification of the Java HotSpot(TM) VM that allows unlimited redefinition of loaded classes at runtime”.

A frequent problem with debugging in any IDE is that the current hotswapping mechanism of the HotSpot(TM) VM allows only changing method bodies. The DCEVM allows adding and removing fields and methods as well as changes to the super types of a class. This would make it a poor man’s alternative for JRebel.

Intrigued by the idea, I’ve tried it and it works!!. The current code base has been kept up-to-date by GuideWire at Github. It took me some time to get the right prerequisites for OS-X 10.9 but eventually I’ve successfully built it against the most recent OS-X JDK 1.7.0_45. It’s now my standard JDK for GlassFish debugging sessions in IntelliJ and I can hot swap any changed code. Of course it’s not as full featured as JRebel, but it still saves me plenty of redeployment time during the day.
Read the rest of this entry »

Posted by Patrick Kik at 15:47 on Saturday 16 November    Add 'J-Fall 2013 – Practices and Tools for Building Better APIs – Peter Hendriks' site to delicious  Add 'J-Fall 2013 – Practices and Tools for Building Better APIs – Peter Hendriks' site to technorati  Add 'J-Fall 2013 – Practices and Tools for Building Better APIs – Peter Hendriks' site to digg  Add 'J-Fall 2013 – Practices and Tools for Building Better APIs – Peter Hendriks' site to dzone

Peter Hendriks (@PeterHendriks80) gaf op J-Fall 2013 een presentatie over Practices and Tools for Builder Better APIs.

In zijn presentatie gaf hij een aantal praktische handreikingen om API’s makkelijk in gebruik en stabieler te maken. Niet alleen ontwikkelaars van frameworks kunnen baat hebben bij Peters tips, ook de rest van de ontwikkelaars zien handige tips in zijn presentatie. Elk stuk software wordt immers zo modulair mogelijk opgezet. En hoe praten die modules met elkaar? Juist! Via API’s.

Ik kan iedereen aanbevelen om naar SlideShare te gaan en direct de laatste slide te bekijken. Dit is een handige cheat sheet die zijn presentatie samenvat. En hij nodigt meteen uit om de presentatie zelf ook door te kijken.

Posted by Jaap Coomans at 10:12 on Wednesday 13 November    Add 'JFall 2013: Designing Distributed Programs with a Raspberry Pi cluster' site to delicious  Add 'JFall 2013: Designing Distributed Programs with a Raspberry Pi cluster' site to technorati  Add 'JFall 2013: Designing Distributed Programs with a Raspberry Pi cluster' site to digg  Add 'JFall 2013: Designing Distributed Programs with a Raspberry Pi cluster' site to dzone

De eerste sessie na de middagkeynote op JFall 2013 was voor mij “Designing Distributed Programs with a Raspberry Pi cluster” door Arjan Lamers van First8. Natuurlijk kwam ik in eerste instantie af op het geek-appeal van de titel, maar al snel bleek dit ook inhoudelijk een erg goede sessie.

De essentie van het verhaal was dat Arjan een proof-of-concept omgeving had gemaakt voor gedistribueerd programmeren met behulp van een batterij Raspberry Pi’s. De hardware setup bestond uit twee clusters van 4 Raspberry Pi’s, per cluster aangesloten op een switch. Deze twee switches waren onderling met elkaar verbonden. Zo had hij dus voor een zeer beperkt budget twee “datacenters” met ieder 4 nodes. Naast dat dit voordelig, compact en geeky is, brengt het ook als voordeel mee dat de Pi’s traag zijn. De redenatie van Arjan: als je je gedistribueerde applicatie op een Pi al goed kan laten performen, dan komt het in je productiecluster zeker goed. Daar valt uiteraard wat voor te zeggen.

Om het geheel te demonstreren had Arjan een eenvoudig gedistribueerd programma gebouwd: Pigs in Space. Niet veel meer dan een veld waar ruimteschepen overheen vliegen met collision detection om te zorgen dat ze niet door elkaar heen vliegen. Met behulp van Hazelcast was het veld in sectoren opgesplitst en verdeeld over de diverse Pi’s. Aan de achtergrondkleur van de sector was af te lezen welke Pi de sector onder zijn hoede had.

Hoewel dit allemaal geen rocket-science lijkt, is het wel een hele goede opzet om basale problemen van gedistribueerd programmeren duidelijk te maken. Zo was al snel te zien dat op de grenzen van de sectoren, waar de ruimteschepen van de ene Pi naar de andere Pi overgingen, ruimteschepen vaak samenklonterden. Ook liet Arjan zien wat er gebeurde in geval van fail-over. Als hij een of meerdere Pi’s eruit trok, was duidelijk te zien dat het geheel even haperde en dat in eerste instantie de sectoren van de uitgevallen Pi’s wel snel werden overgenomen, maar niet eerlijk verdeeld werden onder de andere Pi’s. Dit evenwicht werd later hersteld. Ook was duidelijk te zien dat ruimteschepen in drukke sectoren langzamer vlogen. Een probleem dat zichzelf alleen maar versterkt, omdat ruimteschepen sneller zo’n sector in vliegen dan eruit.

Voor mij persoonlijk was de grootste eye-opener zijn demonstratie van het split-brain probleem. Hiervoor had hij afgedwongen dat de failover van elke Pi zich in het andere “datacenter” bevond. Een opzet die veel bedrijven in werkelijkheid ook gebruiken om de geografische risico’s te spreiden. Na een tijdje werd de connectie tussen de twee datacenters verbroken (split-brain). Zoals verwacht ging alles in principe gewoon door. Sectoren uit het andere datacenter werden overgenomen door de Pi’s in het overgebleven datacenter. Het interessante deel kwam echter toen de verbinding werd hersteld. Op dat moment waren er twee waarheden: de waarheid in het ene datacenter en de waarheid in het andere datacenter. Het gevolg was dat op beeld de ruimteschepen van hot naar her versprongen. Voor de Facebooks en de Amazons van deze wereld zijn dit serieuze problemen waarvoor een herstelstrategie bedacht moet worden: doe je een merge, kies je de ene waarheid boven de andere? In het geval van Amazon wist Arjan te vertellen dat ze in zo’n geval zo vriendelijk zijn om je twee shopping carts bij elkaar op te tellen: ze willen natuurlijk geen omzetverlies :)

Ondanks dat er maar beperkt code op het scherm te zien was, was dit toch een van de beste sessies van de dag. Een sessie die je aan het denken zet.

Wil je meer weten over PigsInSpace? Arjan heeft de source op GitHub gezet:
https://github.com/First8/pigsinspace

Posted by Jasper Kuperus at 15:07 on Monday 11 November    Add 'J-Fall 2013: Code-driven introduction to the Java EE 7 Platform' site to delicious  Add 'J-Fall 2013: Code-driven introduction to the Java EE 7 Platform' site to technorati  Add 'J-Fall 2013: Code-driven introduction to the Java EE 7 Platform' site to digg  Add 'J-Fall 2013: Code-driven introduction to the Java EE 7 Platform' site to dzone

Bij J-Fall 2013 heb ik de sessie ‘Code-driven introduction to the Java EE 7 Platform’ bijgewoond. Zoals de titel al doet vermoeden waren er geen slides, alleen code. De spreker, Arun Gupta, gebruikte zijn GitHub (met zo’n 170 Java EE 7 voorbeelden!) als basis. In deze blog ga ik kort op een aantal besproken onderwerpen in.

Batch

De nieuwe batch API van EE 7 lijkt veel op Spring Batch. Onderstaande afbeelding zal er dan ook wel verdacht bekend uit zien voor de mensen die al eens met Spring Batch hebben gewerkt:

1965481
Bron: http://www.oracle.com/technetwork/articles/java/batch-1965499.html

Een batch proces wordt opgebouwd als een Job die bestaat uit één of meerdere Steps. Elke Step in jouw Job bestaat uit drie onderdelen:

  • ItemReader – Leest exact 1 ‘item’ in. De enige verantwoordelijkheid van de ItemReader is inlezen. Het is niet de bedoeling om hier verdere processing uit te voeren. In het voorbeeld van Gupta wordt hier één regel van een CSV bestand ingelezen.
  • ItemProcessor – Verwerkt het item aan de hand van business logica en geeft het verwerkte item aan de batch runtime voor aggregatie. In het voorbeeld van Gupta wordt hier de ingelezen CSV regel omgezet naar een Person object.
  • ItemWriter – Als er voldoende items ingelezen en verwerkt zijn, worden deze aan de ItemWriter gegeven. De ItemWriter  zorgt er voor dat de data wordt weggeschreven. In het voorbeeld van Gupta worden de Person objecten met JPA in de database opgeslagen.

Verder biedt de JobOperator een interface om Jobs te (her)starten, stoppen, etc. En de JobRepository weet alles over Jobs die worden uitgevoerd of in het verleden zijn uitgevoerd.

Voorbeelden van code kan je vinden in het CSV batch voorbeeld van Gupta. En verdere documentatie bij Oracle.

JSON-P

De JSON API van EE 7 biedt twee onderliggende modellen: Een in-memory object model en een streaming event-based model. Hiermee lijkt de API op de XML APIs van Java en is het vergelijkbaar met DOM en SAX. Tijdens de sessie werd een voorbeeld getoond voor streaming JSON genereren

Om JSON te genereren heb je eerst een JsonGenerator nodig. Vervolgens is de API vrij vanzelfsprekend en kan je al je commando’s chainen. Onderstaand voorbeeld schrijft een simpel JSON document naar de standaard output:

JsonGenerator generator = Json.createGenerator(new PrintWriter(System.out));
generator.writeStartObject()
    .write("firstName", "Duke")
    .write("lastName", "Java")
    .writeStartArray("phoneNumbers")
        .write("111-111-1111")
        .write("222-222-2222")
    .writeEnd()
.writeEnd();
generator.close();

Voor verdere uitleg over de JSON API kan je terecht bij Oracle.

WebSockets & JMS 2.0

WebSockets en JMS 2.0 zijn op deze weblog al uitgebreid besproken, dus zal ik hier niet veel verder op in gaan. Tijdens de sessie werden deze onderwerpen aan de hand van de volgende voorbeelden besproken: WebSockets, JMS 2.0.

EE 7 – en nog veel meer…

Tenslotte werden de volgende onderwerpen tijdens de sessie uitgelegd:

Het was een erg nuttige sessie, waarin in korte tijd veel nieuwe dingen van Java EE 7 werden uitgelegd. Mocht je met Java EE 7 aan de slag gaan, dan raad ik je zeker aan om de GitHub van Arun Gupta er eens bij te pakken.

Posted by Patrick Kik at 20:51 on Sunday 10 November    Add 'J-Fall 2013 – Shootout! Template Engines on the JVM – Jeroen Reijn' site to delicious  Add 'J-Fall 2013 – Shootout! Template Engines on the JVM – Jeroen Reijn' site to technorati  Add 'J-Fall 2013 – Shootout! Template Engines on the JVM – Jeroen Reijn' site to digg  Add 'J-Fall 2013 – Shootout! Template Engines on the JVM – Jeroen Reijn' site to dzone

Afgelopen J-Fall heb ik de early birdsessie “Shootout! Template Engines on the JVM” van Jeroen Reijn (@jreijn) bijgewoond (SlideShare).

Jeroen gaf van vier template engines (Thymeleaf, Mustache, Jade en Scalate) een korte beschrijving. Daarnaast had hij een benchmarkproject (GitHub) opgesteld waarmee hij deze template engines vergeleek met elkaar en de bekendere template engines als JSP, Freemarker en Velocity.

Elk van de behandelde template engines heeft zijn eigen voor- en nadelen qua syntax en gebruik. Jeroen gaf een heldere uitleg en simpele voorbeelden. Wanneer je overweegt van templates gebruik te maken (binnen een webcontext of stand-alone), loont het zeker om even naar Jeroens presentatie te kijken.

Posted by Martijn Cremer at 11:29 on Tuesday 29 October    Add 'Are you a Master of Java?' site to delicious  Add 'Are you a Master of Java?' site to technorati  Add 'Are you a Master of Java?' site to digg  Add 'Are you a Master of Java?' site to dzone

Met enige trots delen we vanuit Sogeti Nederland & de NLJUG dat de Masters of Java terug is van weggeweest! We willen jou uitdagen om samen met een andere Javaan mee te doen met deze ‘funprogging contest’.

Masters of Java is een programmeerwedstrijd met verschillende grappige of interessante opdrachten die je binnen dertig minuten op moet lossen. Met iedere seconde die je overhoudt, scoor je een punt. Het team dat aan het einde van het event de meeste punten heeft, mag zich ‘Master of Java 2013′ noemen. Natuurlijk zijn daarbij mooie prijzen te winnen.

En hoewel het evenement inderdaad bedoeld is als ‘funprogging contest’, betekent dat niet dat iedereen het slechts voor het plezier meedoet. Integendeel: in het verleden heeft er al vaak een verhitte strijd plaatsgevonden tussen de deelnemers. Ook dit jaar hopen we de passie die wij als Javanen hebben daar te zien uitspatten.

 Je kunt je hier inschrijven!

Posted by Milo van der Zee at 15:14 on Friday 18 October    Add 'Memory leak investigation' site to delicious  Add 'Memory leak investigation' site to technorati  Add 'Memory leak investigation' site to digg  Add 'Memory leak investigation' site to dzone

We all know the hassle of investigating memory leaks in Java. Tools like jConsole and jVisualVM help a lot. Especially one function I found out about recently is very useful.

In jVisualVM it is possible to walk through a heapdump and find out about the ‘Nearest GC root’ of an object. What I find extremely helpful is that it is possible to right-click on the GC-root and then select ‘Show in Threads’. This results in heavy cpu usage and after a while in a page showing the stacktrace leading to this GC-root. Now you know exactly which methods and which objects result in this object and so are a huge step in the direction of solving the memory leak. Saved my day.

Posted by Eric Gunnewegh at 9:14 on Tuesday 20 August    Add 'JMS 2.0' site to delicious  Add 'JMS 2.0' site to technorati  Add 'JMS 2.0' site to digg  Add 'JMS 2.0' site to dzone

Inleiding

Eén van de vernieuwde API’s in JEE7 is JMS 2.0. De JMS API is lang stabiel gebleven na de release van JMS 1.1 in 2002. Sinds JavaEE 1.4 maakt JMS 1.1 onderdeel uit van het Java EE platform. Twee zaken die opvallen in de nieuwe JMS API zijn het vereenvoudigde programmeermodel en het gebruik van de nieuwe features die het Java SE platform inmiddels biedt met Java SE 7. Daarnaast zijn er aan de JMS API ook een aantal nieuwe features toegevoegd.

Vereenvoudigd programmeermodel

In figuur 1 is het klassieke JMS programmeermodel weergegeven dat bestaat sinds 2002.

 

JMS 1.1

Figuur 1: Het klassieke JMS 1.1 programmeermodel

In JMS 2.0 is dit programmeermodel vereenvoudigd met de introductie van de JMSContext, zoals weergegeven in figuur 2. De JMSContext combineert de Connection en Session objecten in één object. Daarnaast bevat de nieuwe API de nieuwe JMSConsumer en JMSProducer objecten. De klassieke API wordt overigens niet vervangen door de nieuwe API. Beide API’s blijven naast elkaar bestaan. Wat dit vereenvoudigd programmeermodel betekent voor de Java code, laat zich goed illustreren door codefragment 1.

JMS 2.0

Figuur 2: Het vereenvoudigde JMS 2.0 programmeermodel

   @Resource(lookup = “java:comp/DefaultJMSConnectionFactory”)
   private static ConnectionFactory connectionFactory;

   @Resource(lookup = “jms/TestQueue”)
   private static Queue queue;

   String message = “Een test message”;
   try (JMSContext context = connectionFactory.createContext();) {
      context.createProducer().
         setDeliveryMode(DeliveryMode.NON_PERSISTENT).
         setPriority(9).
         setTimeToLive(10000).
         send(queue, message);
   } catch (JMSRuntimeException e) {
      System.out.println(e);
   }

Codefragment 1: Het versturen van een message

Codefragment 1 laat zien hoe je met de vernieuwde JMS API op vereenvoudigde manier een bericht kunt sturen. Vergeleken met de klassieke API vallen een aantal zaken op.

  1. Een Producer creëren gaat sneller via een JMSContext dan in het oude model via achtereenvolgens een Connection en een Session.
  2. Er hoeft niet eerst een TextMessage gecreëerd te worden. De Producer accepteert ook een String.
  3. Het creëren van JMSContext gebeurt in een try-with-resources block, een nieuw feature van het Java SE7 platform. De JMSContext interface extends de AutoCloseable interface, zodat bij het afsluiten van het try-with-resources block automatisch de close() methode wordt aangeroepen.
  4. Bij het creëren van de JMSProducer kan method chaining gebruikt worden voor het zetten van de diverse opties. In JMS 2.0 hebben de diverse setters voor het zetten van opties, headers en properties de JMSProducer als return value, wat method chaining mogelijk maakt.

Ook het ontvangen van berichten is vereenvoudigd. Zie ter illustratie het volgende codevoorbeeld waarbij het niet nodig is om een Message om te zetten naar een TextMessage om hier vervolgens de body uit op te vragen.

   String msg = context.createConsumer(queue).receiveBody(String.class, 1000);

Injectie van JMSContext

In een servlet of EJB is het mogelijk om direct de JMSContext te injecteren, in plaats van deze aan te maken via een geïnjecteerde ConnectionFactory.

   @Inject
   @JMSConnectionFactory(“jms/MyConnectionFactory”)
   private JMSContext context;

Wanneer gebruik gemaakt wordt van de default ConnectionFactory, kan de @JMSConnectionFactory achterwege gelaten worden.

sessionMode

De introductie van de sessionMode biedt de ontwikkelaar een duidelijker keuze in het gebruik van een transactionele sessie of een acknowledge mode. In de klassieke JMS API bevat het Connection object de volgende methode die de ontwikkelaar op het verkeerde been kan zetten.

   Session createSession(boolean transacted, int acknowledgeMode) throws JMSException;

Het probleem met deze methode is dat niet alle combinaties valide zijn. Bij een transactionele sessie (transacted=true) vindt een acknowledgement automatisch plaats na een commit. In deze situatie heeft het geen zin om een acknowledgeMode op te geven. Andersom geldt ook dat een acknowledgeMode alleen betekenis heeft bij transacted=false.

De vernieuwde JMS API biedt meer duidelijkheid met de volgende methode in het Connection object

   Session createSession(int sessionMode) throws JMSException;

of de volgende methode in het ConnectionFactory of JMSContext object.

   JMSContext createContext(int sessionMode);

De sessionMode kan één van de volgende waarden hebben, waardoor de ontwikkelaar moet kiezen tussen een transactionele sessie of een acknowledgement mode.

   Session.SESSION_TRANSACTED
   Session.CLIENT_ACKNOWLEDGE
   Session.AUTO_ACKNOWLEDGE
   Session.DUPS_OK_ACKNOWLEDGE
   Session.TRANSACTED

Hoewel dit een stuk duidelijker is dan in de klassieke JMS API, geldt ook hier dat niet elke waarde in alle situaties geldig is. Bijvoorbeeld, als de methode wordt aangeroepen in een Web of EJB container in een actieve transactionele JTA context, wordt de sessionMode genegeerd. Voor de details wordt verwezen naar de Javadoc, die met betrekking tot dit onderwerp in JMS 2.0 ook een stuk uitgebreider is geworden, zie http://docs.oracle.com/javaee/7/api/javax/jms/Connection.html#createSession(int).

Shared subsriptions

Eén van de nieuwe features in de JMS 2.0 API zijn de shared subscriptions op topics. Voor wat betreft topics waren er voorheen twee varianten, durable en non-durable topics, die beiden alleen unshared subscriptions ondersteunden. In JMS 2.0 kunnen subscriptions ook shared zijn.

In de JMS 1.1 API konden meerdere consumers een eigen subscription hebben op hetzelfde topic. Elke consumer met een eigen subscription (unshared subscription) ontving dan elk bericht dat op het topic gepubliceerd werd. Pas in JMS 2.0 is het mogelijk dat meerdere consumers een subscription kunnen delen (shared subscription). De berichten die op een topic met een shared subscription gepubliceerd worden, worden door de JMS provider verdeeld over de consumers die bij de shared subscription horen, waarmee het mogelijk wordt berichten parallel af te handelen in meerdere threads.

Exception handling

In de JMS 2.0 API wordt de unchecked JMSRuntimeException gebruikt in plaats van de checked JMSException, zie bijvoorbeeld ook codefragment 1. Dit betekent dat de aanroeper van de methodes in de JMS 2.0 API niet verplicht is deze Exception af te vangen.

Zie ter illustratie ook de createTextMessage() methode in respectievelijk de objecten Session en JMSContext.

   //klassieke API
   TextMessage createTextMessage() throws JMSException;

   //JMS 2.0
   TextMessage createTextMessage();

Wat ook een verbetering is in de JMS 2.0 API is dat de JMSRuntimeException nu ook een constructor heeft met een Throwable als argument. Bij de klassieke JMSExcepion ontbrak een dergelijke contstructor. In plaats daarvan heeft de JMSExcepion een linkedException, die in de praktijk vaak over het hoofd wordt gezien.

Aan de slag met JMS 2.0

Voor wie zelf wil ontdekken wat JMS 2.0 nog meer te bieden heeft, kan snel aan de slag met GlassFish en de JEE 7 SDK. De downloads bevatten diverse examples. Wie gebruik maakt van de built-in JMS Provider van GlassFish, is QBrowser een handige tool voor het bekijken van queues, topics en berichten.

http://www.oracle.com/technetwork/java/javaee/downloads/index.html
http://sourceforge.net/projects/qbrowserv2/
http://docs.oracle.com/javaee/7/tutorial/doc/partmessaging.htm#GFIRP3
https://jms-spec.java.net/2.0/apidocs/


© 2014 Java Competence Network. All Rights Reserved.