mercredi novembre 11, 2009
|
Atmosphere jeudi, Devoxx lundi
Avec servlet 3, managed beans, bean validation, etc... cette session ira clairement au delà du contenu du bouquin d'Antonio (pourtant déjà très riche). Reste la question du JSR 299 qui mérite une session à lui tout seul (difficile de ne faire qu'une intro, la technologie a un ticket d'entrée non négligeable). En tout cas je trouve la progression dans la douzaine de démos plutôt sympa (une idée d'Antonio). Pour ce qui est du contenu GlassFish (keynote, sessions, etc...): les détails sont ici. ( nov. 11 2009, 11:24:55 AM CET ) Permalink Comments [1]La présentation du séminaire GlassFish ( nov. 09 2009, 03:02:00 PM CET ) Permalink Comments [0]You might have hear or "managed beans" before, but chances are these will be new to you. These are not specific to JSF and not related to JMX in any way. Rather, Java EE 6 (well EJB 3.1 to be precise) specifies Managed Beans 1.0, or lightweight components.
Managed beans are plain old java objects whose life-cycle is governed by the container (allowing for creation and destruction callbacks) and supports resource injection (and of course can themselves be injected). To define a managed bean, you simply need to annotate a class with
Such a class can then be deployed within a WAR, an EJB-JAR or an ACC-JAR and can be injected within another Managed Bean, a servlet, an EJB or a JSF Managed Bean using a simple
Whether Managed Beans will be used directly by application developers or mostly for building higher level abstractions such as EJB's (transactional managed beans in a sense), JAX-WS endpoints (SOAP-enabled managed beans) or JSR 299 is yet to be defined. You decide. You can of course try all of the above in GlassFish v3. ( nov. 09 2009, 09:19:56 AM CET ) Permalink Comments [1]
Webinar GlassFish - aujourd'hui à 16h
Jérôme Dochez (l'architecte de GlassFish) et Didier Burkhalter (la cheville ouvrière de nombreux projets GlassFish en entreprise) seront là pour m'aider à répondre au question pendant et après la présentation qui sera relativement courte (environ 30 minutes). A tout à l'heure. ( nov. 03 2009, 08:26:21 AM CET ) Permalink Comments [0]
If anything, the traffic on the "issues" GlassFish mailing list should be a hint on the stabilization work going on before v3 is declared final later this year.
At the same time the FishCAT team is also busy testing the latest releases.
Je ne sais pas si c'est pour fêter la sortie de GlassFish v2.1.1, mais Oracle vient de publier des nouvelles largement rassurantes sur GlassFish dans une nouvelle FAQ sur l'avenir de plusieurs produits Sun dans l'eco-système Oracle une fois l'acquisition finalisée. Il y est entre autre question de continuer un support actif à la communauté et aux clients GlassFish ainsi que d'alignements technologiques entre GlassFish Enterprise et Weblogic. Pour qui connaît les deux offres, je pense que cela apparaîtra assez naturel.
Quoi qu'il en soit, comme je le disais en début de billet, c'est la version 2.1.1 qui est rendue aujourd'hui disponible en même temps que Sun GlassFish Communication Server 2.0 (Sailfin 2.0), l'offre de serveur d'application Telco (SIP, Diameter, etc...) développée avec Ericsson. En attendant la version 3 en décembre, voici donc une version pour tous les clients actuels de GlassFish qui attendent avant tout des évolutions mineures (pour eux, plus de 200 bugs corrigés ce n'est pas mineur) pour leurs systèmes en production plus que des nouveautés comme v3 en apportera. Rarement l'équipe GlassFish aura été aussi sollicitée. GlassFish 2.1.1 est une mise à jour de la version la plus largement déployée de GlassFish en production (niveau d'API Java EE 5). On y trouve de nouvelles versions de composants importants (Java MQ 4.4 / Jersey 1.0.3 / JSF 1.2_13 / Grizzly 1.0.30 / Metro 1.1.6), le support de AIX 6 et de mod_jk ainsi qu'une nouvelle option de partage de charge (par connexion) dans l'ORB. Enfin, le méchanisme de gestion de groupe Shoal propose des améliorations des node agents pour une meilleure détection (plus rapide, plus fiable) des noeuds d'un cluster. Bien entendu cette version continue de proposer une extreme simplicité pour la mise en place d'un cluster et les outils de gestion production GlassFish Enterprise Manager. Téléchargement de GlassFish 2.1.1 ici: https://glassfish.dev.java.net/downloads/v2.1.1-final.html et n'oubliez pas le séminaire en ligne GlassFish de la semaine prochaine. ( oct. 29 2009, 08:39:57 AM CET ) Permalink Comments [3]On don't think this will quite stop people from asking (me and others on the team) the same question, but this new FAQ from Oracle certainly has some positive information on GlassFish's future. The blogosphere and twitosphere have been quite active on that news today... ( oct. 28 2009, 11:55:28 PM CET ) Permalink Comments [2]Séminaire en ligne GlassFish la semaine prochaine
Mardi le 3 novembre 2009 (dans une semaine) à 16h00 Le format est classique: 45 minutes de présentation et le reste de questions/réponses. N'oubliez pas de vous inscrire pour obtenir les détails (URL et mot de passe). ( oct. 28 2009, 09:47:46 AM CET ) Permalink Comments [1]
• Servlet 3.0 (JSR 315) support in Maia
Attending and presenting at Java2Days this week in Sofia
The conference is quite geared towards server-side Java with Spring and Java EE getting great coverage with SpringSource employees and Java EE expert group member Reza Rahman. My first talk on Thursday is on GlassFish v3 while the second is on portability of J2EE/JavaEE applications (lessons learned while migrating customer applications to GlassFish). Should be fun! ( oct. 07 2009, 10:13:50 AM CEST ) Permalink Comments [0]Using the EJBContainer API with or without Maven (but with GlassFish v3)
Updated this blog on October 28th as you no longer need to have a full GlassFish install to test EJBs
There are at least two ways to start GlassFish in embedded mode: using
The goal is to write something like as simple as this to test your EJB :
EJB's found in the classpath of the running code above will automatically be deployed and made available via lookups.
Calls to
To use
You could restrict this to a smaller set of GlassFish artifacts but for non-trivial tests (if you use JPA for instance), you would start to have a fairly long list of dependencies so the above sounds like a reasonable thing to do. This will require Maven to download the GlassFish All-in-one JAR file (40MB or so). The reason I wrote it would be trickier with maven is that you need to pass a property during the
Starting the appserver this way (with or without Maven) exercises the actual GlassFish code, not another implementation or a customized fork. There are some limitations to what you can run and in particular port configuration is ignored (not listening on any) and only local EJB interfaces are available (the spec only requires EJB 3.1 lite support). On the other hand, JPA calls are very much possible. This should all work with v3 promoted build 66 (I just tested this with promoted build 70, see above simplification). Adam Bien beat me to covering that topic, but I hope you get some additional info here. In my case the start-up, setup, deploy and shutdown of GlassFish Embedded are worth about 6 seconds. Note that there is no OSGi involved here.
For a complete working example with JPA calls, check out this sample code.
"Le futur de Java" ce jeudi à l'OpenWorldForum
Avec l'imminence du rachat par Oracle de Sun, un point sur Java semblait intéressant et utile. Au programme, le chemin parcouru par Java SE depuis sa mise en Open Source et les avancées prochaines de JDK7, une table ronde sur les langages dynamiques sur la JVM (Groovy, Scala, Fan, et Clojure, ou Jython, JRuby et PHP?), et enfin un point sur Java EE 6 et son implémentation de référence GlassFish v3. Notre Guillaume Laforge sera de la partie pour la table ronde. Ce sera bref (1h30 au total), mais une occasion concrète de faire le point sur les travaux en cours et sur ce que le futur proche nous réserve.
• Programme: http://openworldforum.org/program/floss-java.
GlassFish tip: customize directory listings
With GlassFish being a very capable HTTP server out of the bowser (thank you Grizzly!), it was time for v3 to offer the ability to configure directory listings. It is now possible to have pages listing files per
Configuration can be done inside
You might find it more convenient to have it be part of
Of course there's also the XSLT approach to have yet more control over the presentation. Check the use of
OK, I really need more than 140 characters for this one (plus it's been a while since I blogged opinions).
Many people have reacted to JBoss' solo launch of REST-*. What I'm concerned about is the approach, not the technology and specifications (I'm probably not the best person to comment on that part).
For one, having rest-star.org redirect to a jboss.org web site is a "bad thing" (tm). JBoss being the only participant is also not giving the underlying technical effort a lot of chance to become a commonly accepted standard, and that's a pity. Over on twitter, my colleague Jason sent me this sensible analysis which also questions the approach taken while finding some merits to the technical parts. Mighty Roy is simply bashing and swinging at the proposal calling for . But then not many people get his blessing from day one. Rickard Oberg is pointing out that JBoss has a interesting track record in terms driving the project (too bad the last paragraph on his affiliation to JBoss is actually taking some credit off of that assertion). Contrary to what Haikal says, JBoss is not late to REST with their very decent JAX-RS implementation and their participation in the standardization effort. In fact, I'm not convinced by the SpringSource excuse (SpringMVC legacy) for not implementing this API. Getting beyond all this criticism, it's rare enough to have people offer to do actual work to demolish it like Anne Thomas is doing. I've been with Sun for too long to throw away the baby with the bath water.. If someone wants to contribute standards, OASIS, W3C, or IETF is where it should happen. Granted you'll be better off starting from some specification or even better yet from a successful implementation (and you may end up not being able to call it REST-anything), but declaring REST-* to the world and making it a one company thing sounds like a marketing mistake to me. ( sept. 17 2009, 11:32:29 PM CEST ) Permalink Comments [2] |