Soft Skills: Being a professional from Soft Skills: The software developer's life manual by John Sonmez

[This article excerpted from Soft Skills: The software developer's life manual.] In one of my favorite books of all time, The War of Art, Steven Pressfield expounds upon the difference between being a professional and being an amateur: Turning pro is a mindset. If we are struggling with fear, self-sabotage, procrastination, self-doubt, etc., the problem is, we’re thinking like amateurs. Amateurs don't show up. Amateurs crap out. Amateurs let adversity defeat them. The pro thinks differently. He shows up, he does his work, he keeps on truckin’, no matter what. Being a professional is all about showing up, doing your work, and not letting adversity defeat you. Being a professional requires you to overcome your vices so that you can sit down and produce the best work possible. In this article we’re going to focus on what it means to be a professional and how you can be a professional in your software development job whether you work for someone else directly or produce work for clients. As a software developer, professionalism will be one of your greatest assets. Not only will learning how to act like and be perceived as a professional help you to get better jobs and more clients, but it will also help you feel better about the kind of work you’re doing and to have pride in that work—a critical component of long-term success. What is a professional? Simply put, a professional is someone who takes their responsibilities and career seriously and is willing to make the tough choices that have to be made—often at their own expense—for the purpose of doing what they know is right. For example, imagine what you’d do in a situation where you’ve been asked to cut your normal quality standards and just ship some code as quickly as possible. How do you react in this situation? What if you’re repeatedly asked to work in this way? Can you stand up and do what is right, even if it may end up costing you your job? What principles do you stand for? What quality bar do you personally set on your work? A professional is what we should all strive to be. A professional is someone you can count on to get a job done and to do it right, but a professional also doesn’t just tell you what you want to hear (see Table 1). A professional will let you know when something isn’t possible or the path you want to proceed down is wrong. A professional is someone who may not have all the answers, but thoroughly studies his or her craft and seeks to hone his or her skills. A professional will freely admit when he or she doesn’t know the answer, but you can count on a professional to find it. Perhaps most importantly, a professional is consistent—stable. A professional has a high-quality standard for his or her work and you can expect a professional to adhere to it each and every day. When a professional doesn’t show up, you had better call emergency dispatch, because there is certainly something wrong. Table 1 Professionals versus amateurs Professionals Amateurs Has principles that they abide by Does whatever is asked Is focused on getting the job done right Is focused on getting the job done Isn’t afraid to admit when they are wrong or don’t know Pretends to have knowledge they don’t possess Consistent and stable Unpredictable and unreliable Takes responsibility Avoids responsibility Being a professional (forming good habits) It’s easy to identify a professional, but how do you become one? What is it about you and your work that reeks amateur, and how do you neutralize the odor? It starts with habits. Habits are an essential part of becoming a professional, because a large portion of what we do every day is completely habitual. We get up, we go to work, and we perform our daily routines each and every day, mostly without really thinking about it. If you want to change your life, you need to start with changing your habits. This is, of course, easier said than done. Bad habits are exceedingly difficult to break and new habits aren’t easy to form. But, if you want to become a professional, you need to develop the habits of a professional. At one time when I was working on a team following the Scrum process, where we would have a daily stand-up meeting stating what we had done, what we had planned to do, and what was impeding us, there was one developer in particular who always had a written version of exactly what he was going to say. Every single day before the Scrum meeting he would prepare his statement, instead of coming up with it during the meeting like most of us did. This is the kind of habit a professional develops. Another strong habit to develop as a professional is time-management skills. How good are you at managing your time right now? Do you know what you’re going to work on each day before you work on it? Do you have a good handle on how long routine tasks will take? Get in the habit of effectively managing your time by planning out your day in advance. A professional knows what work must be done each day and knows roughly how long it will take to do the work. These are just two examples of the kinds of habits that are important to develop as a professional software developer. You’ll have to decide for yourself what habit you need to form to reach your own standard of professionalism in your work, but habits are critical because habits build consistency and consistency is what makes you reliable. (For a great book on the subject of habits, check out The Power of Habit by Charles Duhigg.) Doing what is right As a software developer you’re often faced with many difficult challenges, both technical and ethical. If you want to be a professional, you need to be able to make the correct choices in both of these cases. Often the technical challenges you face are more objective. There are right ways to solve technical problems. It’s easy to prove one solution over another. But the ethical challenges can be much more difficult. There isn’t always a clear-cut right answer. One of the biggest ethical challenges software developers face is that of going forward with decisions they know are correct and in the best interest of their client even if making those decisions could jeopardize their own well-being or stability. One of my favorite software developers and authors, Bob Martin, wrote an excellent article on saying “no,” which addresses this very issue. In the article, Bob compares a software developer to a doctor. He talks about how absurd it would be for a patient to tell a doctor how to do his or her job. In his example, a patient tells the doctor that his arm hurts and that he needs to cut it off. Of course the doctor says “no” in this case. But in many cases software developers in a similar situation, fearing the wrath of higher-ups, will say “yes” and perform an amputation on their code. A professional needs to know when to say “no,” even to his or her own employers, because, as Bob put it, professionals have certain lines they won’t cross. It might even mean getting fired, but sometimes that is the price to pay if you want to call yourself a professional. In the short term, it may be painful, but consistently choosing to do the thing you know is right over the course of your career is much more likely to pay off than the alternative—plus you can sleep better at night. Sometimes professionals have to make tough decisions about the priorities of what they work on. Unprofessional developers will often waste time by gold-plating things, because they can’t decide what to work on next or they’ll constantly have to ask someone else to set their priorities. A professional assesses the work that has to be done, prioritizes it, and gets to work. Landmine: What if I can’t afford to say “no”? It’s pretty easy for me to sit back in my chair and tell you that you just have to say “no” sometimes, but not everyone has the luxury of being able to risk their job. I understand that you may be in a position where you literally can’t say “no,” because doing so could be catastrophic for you future. My advice in this situation is to go ahead and do what you need to do to get by, but never let yourself get in this kind of situation again. It’s easy to get trapped into situations where you need a job, but when you get trapped in those situations you really limit your own options and allow people to exercise great power over you. If you’re in this kind of a situation, try to get out of it as fast as possible. Save up some money so that you don’t have to worry so much about losing your job. You might even consider looking for another job where you won’t be required to make so many ethical decisions or where your opinion is more highly valued. When it comes down to it, you have to do what you have to do, but always try to put yourself in positions where you have the upper-hand or are at least on equal footing, whenever possible. Seeking quality and self-improvement As a professional you must strive to constantly be improving and increasing the quality of the work you produce. You won’t always be able to produce the quality of work you desire, but over time, with consistency, you’ll reach your standards. The big mistake many software developers make is to lower their standards when they seem out of reach instead of seeking to improve themselves to rise up to meet the challenge. It’s important to apply quality to every detail of your work, not just the parts that seem most important. A real professional has high-quality standards for all areas of his or her work, because a professional knows that, as T. Harv Ekr put it, “how you do anything is how you do everything.” If you lower your standards in one area, you’ll inadvertently find them dropping in other areas as well. Once you’ve crossed the line of compromise it can be difficult to go back. And don’t forget to play to your strengths. You can, of course, improve your weaknesses, but it’s a good idea to know what your individual strengths are and use them to your advantage. A professional has a good, accurate, and realistic self-assessment of his or her own abilities—and weaknesses. The way a professional meets the high-quality expectations he or she has is by continuous self-improvement. If you want to be a professional, you need to dedicate yourself to always improving your skills and learning more about your craft. Make sure that you have an education plan that you can follow to expand your skills and learn new things that will help you do your job better. Don’t ever be happy with good enough—always strive to become a better version of yourself. Taking action Would you define yourself as a professional today? If so, why? If not, why not? What are your habits? Observe your day and try to identify as many habits as possible. List your habits in two categories, good and bad. Now identify some good habits you need to develop. Come up with a plan for developing those habits. When was the last time you had to say “no”? If you’ve never encountered this situation, think about what you'd do if your boss asked you to do something that you knew was wrong. How would you react? For more, check out Soft Skills: The software developer's life manual.

Posted by on 22 October 2014 | 10:16 am

Getting to Know the Oracle Developer Cloud Service

Oracle Developer Cloud Service is included as a free entitlement with Oracle Java Cloud Service and Oracle Messaging Cloud Service. The Developer Cloud Service includes all the tools you need to support the team development lifecycle. There are popular open source tools such as Git, Maven and Hudson. There's also task management, code reviews and a wiki. The easiest way to experience the Oracle Developer Cloud Service is through a trial of the Oracle Java Cloud Service - SaaS Extension (click the "Try It" button). In this article I will introduce the Developer Cloud Service by using Maven to create a new web application, Git to manage the application source and Hudson to build and deploy my application to the Java Cloud Service. Prerequisites If you plan to follow along, this tutorial also assumes you already have Maven and Git installed. I will be using the Git Console from my desktop to interface with the Developer Cloud Service. The tutorial also assumes, of course, that you have access to the Developer Cloud Service! Create a New Project As a first step, log into the Developer Cloud Service and create a new project. Give the project a Name, Description and select the Privacy setting (for team projects you should select Organization Private): For this example, we will not be using a template: And finally, chose the Wiki markup style you prefer and click Create Project to begin: As the project is being created, you can watch as the services are being provisioned for you. This should only take a couple of seconds: Soon, project service provisioning is complete and you're ready to start using your new project: Develop an Application Here we'll use Maven to quickly create a web application. I'm going to do this from the Git Console so I'll have a consistent local user interface throughout this tutorial. This is the Maven command I'll be running, which creates a fully functional Hello World web application: mvn archetype:generate -DgroupId=HelloDeveloperCloudService -DartifactId=HelloDeveloperCloudService -DarchetypeArtifactId=maven-archetype-webapp -DinteractiveMode=false Let's now put the application under source control management. Git SCM We begin by creating a Git repository for our web application. If you're not already familiar with Git, their Try Git tutorial provides an excellent introduction. Change into the newly created application directory and run: git init Next we need to add the files to the repository index and stage them for commit: git add . Now commit the new files to the local repository. git commit -m "Add initial webapp files" Now we need to add our remote repository (the one in the Developer Cloud) to Git. For this you'll need to copy the Git source code repository URL from your Developer Cloud Service project. 'dcs' is the name we will use to refer to this repository going forward: git remote add dcs {copy https URL from Developer Cloud Service project} Now push our web application project files to the Developer Cloud Service. The name of our remote is 'dcs' and the default local branch name is 'master'. The -u tells Git to remember the parameters, so that next time we can simply run git push and Git will know what to do. git push -u dcs master At this point you'll also be prompted for your Developer Cloud Service password: Build Now that our source code is in the Oracle Cloud, we can run a Hudson build Job. The Developer Cloud Service comes pre-configured with a sample Maven build job that will properly build this application. If you first want to see your code, click the Browse tab and click View Commits: Click the Build tab, where you'll see the provided Sample_Maven_Build: Click the Sample_Maven_Build link to open the job: Feel free to review the configuration (click the Configure link). When you're ready, click the Build Now link. The build will get queued, waiting for an executor: Soon thereafter, the build will begin: Feel free to click the console icon to track the Console Output. In my case, the build has already completed, so the build indicator ball has turned green: .......... Deploy Now that we have a successful build, we can configure deployment. Click the Deploy tab and then click New Configuration: Complete the Deployment Configuration. As I'll be using this configuration for development, I'll set it to deploy automatically after a successful build: Click Save to see your new Deployment Configuration: This deployment will run any time there's a new build. To run this build manually, click the gear icon and select Start: And wait a few seconds for the deployment to succeed: Verify Click the Java Service link to navigate to your Java Service. There, under Jobs, you'll also find that the Deploy Application job is Complete: On the same page, under Applications, click the Test Application icon: Then click the Application URL in the window that pops up: Which will open your application in a new tab: As this application stands right now, it would require cloud credentials in order to run it. Let's quickly remedy that. Updating the Application Back in the Git Console, add and empty <login-config/> tag to the web.xml. You can read about the details of Updating web.xml in the Cloud Documentation. While were are here, let's also make a visible change to the index.jsp: Then commit: Push the changes to the Developer Cloud Service: Return to the Developer Cloud Service Console and optionally view the changed files: Switch to the Build tab and click the Schedule Build icon (just to the right of the Console icon). In the true spirit of continuous integration, it is also possible to configure Hudson to poll for changes to the repository, but that's now how this sample build has been configured. When the build completes, remember deployment is automatic. Just return to your browser and refresh the page: There is much more to experience with the Developer Cloud Service - Tasks, Code Reviews, Wikis. The plan for this tutorial was to give you enough to started. Are you ready?

Posted by on 22 October 2014 | 9:50 am

And the MVC specification project is public

And the MVC specification project is now public at so we are on the way! Enjoy!

Posted by on 21 October 2014 | 6:29 am

Guest post: How to create a newsletter template your marketing team will love

Today, I'd like to introduce you to a colleague of mine: Tomas. Tomas works with Magnolia's marketing team, where he focuses on developing our corporate website, as well as a number of communications tools like newsletters. He's recently taken a liking to blogging, so I'd like to leave him this stage today, as he has some pretty cool pieces of knowledge he'd like to share. Do your CMS editors need to simply (that is, without knowing html, css and other fancy web technologies) create and send out newsletters every week? Do they additionally want to have these newsletters neatly archived on your website, tied nicely to your existing website theme? If you answer these questions with a resounding “Yes!”, there are a few useful tools and functions in Magnolia to get the job done quickly, while keeping everyone happy. First, you’ll need your html prototype for your newsletter. The web is full of resources on how to write a proper html email, usually full of tables and inline styles (I'm sure you know how to use Google, but here is one of my favorite resources). The use case here is to have your newsletter accessible both on email and via the browser, on your website (“Having trouble reading this email? Click here”...). So to ease you gently into the topic, let’s start with this requirement, as it’s the simplest part: let’s create a new newsletter template on our website. We’ll extend our custom home or stkHome (to keep our branding, meta-navigation, footer, etc as inherited areas). Then we’ll wipe out (override) the list of existing components in this new home template and create a new availableComponent in areas > main > areas > content that goes by the name of newsletterTextImage. Of course, we can add or extend others like linkLists or teasers, but for now, let’s work with this one. We’ll also extend stkTextImage and add your custom dialog (for title, text, image, button) and ftl. FTL (my templating language of choice - you can also use JSP or others, but I can guarantee it to you that FTL is simpler and easier to use in the long term) should be “email ready” (tables, inline css and other goodies) because we will use it in email rendering and also in the website. Of course we can also change our mainArea.ftl and others, depending on our newsletter layout. But for now, we have a new working template (don't forget siteDefinition availability) with one newly available component. So far so good - it’s pretty much just like your regular template. And now the magic bit comes in. In this template we can define “variations” and change templates depending on file extensions. Let’s imagine that the default variation for all pages is “html”, which means that if we have a page, then the extension “.html” is connected with this default variation. Now if we create a new variation called “email” and change the url to then we can rewrite some properties, for example templateScript main.ftl, with something more “email ready”. Variations work with the same logic as extends, so if you need to rewrite ftl for contentArea as well, then you have to create a whole tree below (areas > main > areas > content). Variation: newsletterMain.ftl: And that’s all. Well, almost. But editors are now able to create a simple newsletter and render it as web content or email. If you are using an external campaign tool like Campaign Monitor or Infusionsoft, just open your new newsletter on your public instance of Magnolia, go for the source code and copy it all. Then just put this code into your tool (maybe you will also have to add some elements to code, like the “unsubscribe” button if you’re using e.g. Campaign Monitor). On the opposite end, there’s tools like InfusionSoft that will be injecting “unsubscribe” and some more text to the bottom of your email automatically, so you can just send the html. Or maybe you are using one of Magnolia’s integrations for such tools, such as the Newsletter module, which can also help you with this part of the work. :) This post should cover a basic functionality overview and give you something to build on. Frontend developer, page-crafter, template designer or whatever your job title is: let your imagination loose and show us what kind of amazing newsletters you can create! And, as a good illustration for this post, here is our latest newsletter. Why not subscribe to it, while you’re at it?

Posted by on 21 October 2014 | 4:14 am

JavaOne 2014 Day Three Notes

Day three was definitely the high point of the conference for me. As anyone who has spoken at tech conferences knows, the point in time when all of one's sessions have been given is the turning point between tempered enjoyment and pure enjoyment of the conference. I was blessed with the scheduling this year; I was all done after Wednesday. This put me in a great frame of mind to enjoy the Oracle Appreciation Event. Day three also saw the culmination of a long running project: the Web Framework Smackdown 2014 edition. My friend and colleague Reza Rahman asked me to keep the web framework smackdown meme going for another year. This year I called in quite a few favors to pull together a diverse group of celebrity panelists: Miško Hevery, creator of AngularJS at Google, Pete Hunt creator of ReactJS at Facebook, and Joonas Lehtinen, creator of Vaadin. The panel was moderated by Neal Ford of ThoughtWorks. I rounded out the panel representing JSF. I've learned from previous smackdowns that a confident and comfortable moderator combined with a little prep time just before the panel are the keys to success. We met at 11am for this purpose over Patxi's pizza. From the left you can see Neal Ford, Miško Hevery, myself, Joonas Lehtinen, and Pete Hunt. I don't think Pete and Miško had met before, and it was interesting hearing them trade notes about their approaches to the performance of handling the model update side of their frameworks. From what I gathered, they both see that feature as the most valuable aspect of their frameworks, and they both have spent significant time optimizing that part. When it came time to take it on stage, we started by introducing our different approaches to the task of building a stateful and responsive user interface delivered in a web browser. Angular and React are entirely client side, while JSF and Vaadin are entirely server side. In spite of Neal's earlier recommendation that client side is the way of the future, Joonas and I made the case for where server side makes sense. Briefly, reasons for favoring server side over client side include simplicity, security, integratability (such as mashups), and maintainability. Client side is better when Facebook-sized scale is important, when JavaScript fluency is a non-issue, and when "modern" browsers are a given. You'll have to check out the audio to get the full details. My only complaint with the panel is that it really didn't get smackdown-ish at all. I welcome comments about the client/server UI debate. Perhaps we can get some smackdown action in the comments. My last official obligation of the conference was my final booth duty in the Java EE both. This session closed out the JavaOne exhibition, and as such the traffic was a bit light. I was able to take a tour around the exhibition to obtain some schwag for my kids. This year it was novel to see Target with a booth. I've long been a fan (and shareholder) of Target, avoiding Wal*mart at all (unfortunately frequently too high) costs. They were recruiting. JavaOne is not a job fair, but it was still nice to see them representing Minneapolis, home of Facelets creator Jakob Hookom. Booth duty done, it was on to a bit of fun in Duke's Cafe. As I mentioned in my JavaOne 2014 Day One blog entry, Chicago JUG leader Freddy Guime had put together a band of musician Java enthusiasts called the NullPointers. They allowed me to sit in with them for some songs during their set at 5pm Wednesday. This was a real honor and a great blast. At left, from the left you see Zoran Severac, Mattias Karlsson, of JFokus, Geert Bevin of ZeroTurnaround, and Jim Weaver, Java Developer Advocate for Oracle. At right, from the right, you see Freddy, Frank Greco of the New York Java Users Group and myself. I think my keyboard stand was formerly in the Hackergarten. The fun kept on rolling, with the Oracle Appreciation Event. This used to be called the Customer Appreciation Event. I'm not sure why they renamed it. I would probably have given it a pass this year but for my 11 year old who is a big Macklemore fan. I'm glad I went because Macklemore was very entertaining, and Aerosmith put on a great show as well. AttachmentSize 20141001-smackdown-prep.jpg96.55 KB 20141001-nullpointers-01.jpg74.99 KB 20141001-nullpointers-02.jpg72.57 KB c12bg-openworld-bands-2264324.jpg130.67 KB

Posted by on 17 October 2014 | 7:08 am

JSF Tip #63 - Another way to override a renderer

In JSF Tip #32 - Override a JSF Renderer and JSF Tip #34 - Override JSF renderer and create a new tag for it we have described ways to override a renderer. Well, would you believe there is yet another way? It is as simple as adding an f:attribute tag as a child of the component you want to change the renderer for. <h:panelGroup>  <f:attribute name="rendererType" value="MyRenderer"/></h:panelGroup> And then make sure you set it to the right componentFamily, in this case for an h:panelGroup the component family is "javax.faces.Panel" and that the value of the f:attribute matches up with the rendererType set for your renderer. @FacesRenderer(componentFamily = "javax.faces.Panel", rendererType = "MyRenderer")public class MyRenderer extends Renderer {    @Override    public void encodeEnd(FacesContext context, UIComponent component) throws IOException {        context.getResponseWriter().write("DEMO DEMO DEMO");    }} Enjoy!

Posted by on 17 October 2014 | 12:31 am

JSF 2.3 changes

A quick run down on the issues fixed since last time #1325 - Let CDI handle #{applicationScope} #1311 - Let CDI handle #{facesContext} EL resolving #1323 - Support @Inject for the applicationMap #1322 - Simplify #{externalContext} to use ExternalContextProducer #1309 - Support @Inject for ExternalContext #527 - Support @Inject for FacesContext Please test drive the latest 2.3.0-m01-SNAPSHOT and lets us know about any issues. Enjoy!

Posted by on 16 October 2014 | 2:47 am

JSF 2.3 Injecting the application map

Another CDI alignment issue done In code @ApplicationMap@InjectMap applicationMap; In words you can now inject the application map for use in your CDI managed bean. Enjoy!

Posted by on 15 October 2014 | 2:39 pm

Not so DAMned DAM support

Those of you who have used Magnolia for a while know that it has come with its own Document Management System (DMS) module for years. The purpose of the module was to allow you to manage documents within your CMS. While the module was used extensively by everyone as a common storage of digital assets (images, videos, and other media), it never quite picked up as a traditional DMS. The module itself also had a few architectural compromises in order to let it function as a DMS, and as such was not very extensible. So with Magnolia 5, we finally bit the bullet and outphased the DMS in favour of a new D-module - the Digital Asset Management (DAM) module. And with new module, we also applied lessons we learned with the old one. Following the Open Suite approach for DAM, too Rather than providing one all encompassing store for your digital assets, with some edit functionality on top, we looked around and noticed that there is a plethora of DAM implementations that we could never compete with. So in typical Magnolia fashion, rather than fighting them, we decided to join forces with them: we made sure that the interfaces and APIs of our DAM implementation allow the exchange of underlying DAM implementations for far more sophisticated ones than we could implement - while still providing a reasonably good default implementation to those who can’t or won’t integrate and use multiple systems. The perfect DAM integration opportunity Magnolia’s DAM comes with a configurable AssetProvider that gives you the chance to use external assets with Magnolia as easily as internal ones. All of that happened 18 months ago, when we released the then-new Magnolia 5. Until today, I’ve been waiting to be able to exercise the proof of functionality of those interfaces to connect an external DAM platform to Magnolia and show the power of DAM integration to our editors. Now, the perfect opportunity has finally arrived - with Canto’s Cumulus platform, we share the same technology stack, the same customer base and many other common points of interest. Among them is the passion for integrating CMS and DAM solutions into one system for the benefit of users of both. With the new Cumulus DAM integration, editors are able to select and use assets in Cumulus like native assets in Magnolia. When choosing an asset, they can pick between assets from Magnolia’s internal storage or those coming out of Cumulus. Other than that, everything remains the same. Seamless connection, no user worries Editors don’t have to care about the implications of using an external asset - Magnolia does that for them. It will notify Cumulus that an asset is being used, as well as where and when page was published or unpublished. Magnolia will also make sure that all the variations and links to such external assets are generated as appropriate. Template developers as well as editors don’t need to care or know about the difference. The whole integration is designed to be seamless, fluent and fully transparent. Everyone is free to focus on their work and just reap the benefits of the integration. Speeding up the workflow Another benefit results in more efficiency and collaboration - editors might still need to ping their buddy in the design department to provide a new graphic for the campaign page, but due to the integration, the colleague can just save their work in Photoshop or InDesign, in the storage connected to Cumulus: the asset will then instantly appear in Magnolia’s Asset app. In another use case, imagine all protected assets you need to use in your page. Did you have to keep in mind when your usage rights will expire or in what regions assets can be used? With this integration, you select an asset to be used in a page and rely on the integration and the underlying systems to downgrade gracefully when your usage rights expire or when a user from a certain region who is not covered by your license accesses your content. Can it be any simpler than that? Future-proof decisions With this integration, we have been able to proof that our design choices were good choices. At the same time, we discovered even more ways to make such work easier, and ways to bring different systems closer together - all the while delivering more value to customers of both systems. So stay tuned, as this is not last post on the topic. In a couple weeks, I’ll publish another piece for our technical audience, explaining all the challenges faced during this integration, as well as techniques used to solve them. If you want to know more about the Canto integration, go to or attend our webinar on 29 October: AttachmentSize cumulus-asset-app-2.png491.31 KB

Posted by on 14 October 2014 | 4:18 am

JSF 2.3 @Inject ExternalContext

Starting from the new 2.3 SNAPSHOT builds you can now do @Inject ExternalContext externalContext; Note you will need to make sure you use the latest 2.3 SNAPSHOT build and that you include a faces-config.xml that states version 2.3. Enjoy!

Posted by on 14 October 2014 | 12:22 am