Featured FREE Whitepapers

What's New Here?

software-development-2-logo

Confusion As A Usability Defect

As a software engineer, you should always be looking for the location of the next defect or at least clues that something is wrong. The problem is that most developers have been trained to wait for feedback from the QA team. In many cases, the QA team is following a script or has been trained on how to use the system, so some clues get lost in the familiarity.Michael Bolton has an interesting post regarding confusion as an oracle: James peered over his glasses. “When you’re confused,” he said, “that’s a sign that there’s something confusing going on. I gave you a confusing product to test. Confusion might not be fun, but it’s a natural consequence when you’re dealing with a confusing product.” James was tacitly suggesting that Jon’s confusion cound be used as an oracle—a heuristic principle or mechanism by which we recognize a problem.When the QA team is confused, that points to potential issues and should be used as a heuristic. The confusion could be from a few sources. First, the test script could be out of sync with the user interface in such a way that is not obvious how the tester should proceed. This can happen with any application that is evolving throughout the development lifecycle. Second, you could have someone that has not been trained on the application as the tester. This can quickly be remedied by providing the appropriate information on how to use the application. It could also point to an incomplete test script, meaning someone new cannot execute the test script without additional instruction.Another reason the QA team could be confused is because the application is confusing. This is not a good sign and should be seen as a warning to the development team. Most likely there is a usability defect in the application. For some teams, usability defects do not exist and usability issues get added to the list of things to do. This is a big mistake when developing web applications. Almost a year ago I wrote about Krug’s usability rules: The first two Krug rules of usability are very related:Don’t make me think – as far as is humanly possible, when I look at a web page it should be self-evident, obvious, self-explanatory. It doesn’t matter how many times I have to click, as long as each click is a mindless unambiguous choice.I love the “don’t make me think” rule. If you design your application with this rule in mind, you will get past most usability problems. However, if you are a startup and developing for a large userbase, you may have slightly more concerns. Mark Evans wrote recently about a rule of thumb “I get it”: But if you push aside the entrepreneurial enthusiasm, a startup’s success prospects depend on a compelling idea and, as important, the ability to quickly get potential users to say ”Yes, I get it”. This means being crystal clear what the service or product does, and the value propositions/benefits being delivered. The product/service needs to fill a need or convince users it meets a need they didn’t know they had. Getting users on board has to be user-friendly and efficient. And the product/service has to delight.If you are following these basic principles, your product should not be confusing. I am a big believer in making things simple for users, because it means they will enjoy (or at least not hate) using the system. This is obviously a good thing, but more importantly, users will look for other ways to use your application.So, why should a “confusing” application have usability defects tracked? If an application is confusing, that means it is going to be difficult to use. When an application is difficult to use, people stop using it because they can not see the benefits to using the system.Usability is also hard to define, but if you look at Krug’s rules you will see that the user should not have to find the right thing to do, it should be fairly obvious. But, what about prior to production? You don’t have typical users on the system, so how do you determine usability? One thing I have seen is that the length of the test script can be a good trigger for something being too difficult.Let’s assume you have manual testing being completed. Ignoring the test case setup instructions, how many steps are required to test one feature? This is similar to the number of clicks heuristic, but it is the number of actions a user must take in order to complete a task. You could say the number is something like 7 but that is not entirely useful. I have used “Why” as my metric of choice. If you ask “why do I need to complete this step?” and there is no obvious or definable reason, then you likely are introducing unnecessary steps to the task. If you can eliminate these issues, your application usability should improve.To really make your application simpler, make sure your QA team starts questioning things in the beginning of the process. Someone writes the test script, and it could be the QA tester themselves. The developer and the tester should go through the test script and ask “why” for each step. This will proactively remove any stumbling blocks in the plan and have a much more usable system after it passes QA testing.Are there any tips or tricks you have for improving usability?Reference: Confusion As A Usability Defect from our JCG partner Rob Diana at the Regular Geek blog....
apache-jmeter-logo

Extending JMeter with a WS-Trust/STS sampler

JMeter does not have any inbuilt support for WS-Security or WS-Trust and that made me develop this STS Sampler for JMeter – which could make anyone’s life better while load testing an STS.First you need to have the Apache JMeter distribution. I am using v2.7.Then you can download sts.sampler.zip from here – unzip it and copy the “repo” directory directly to JMETER_HOME. Also copy all the jars inside lib.ext directory to JMETER_HOME/lib/ext.That’s it – now start the JMeter.Under your thread group – right click – and add the Java Request Sampler…Now, select org.wso2.apache.jmeter.sts.STSSampler as the classname – you will see the following then…Let me briefly explain here – what exactly the different parameter names mean..STS_End_Point : End point of the Security Token Service. If you are using the STS that comes with WSO2 Identity Server, then this would be https://localhost:9443/services/wso2carbon-stsSTS_Security_Policy : Location to the WS-Security Policy – that is being used to secure STS. It can be a security policy with UsernameToken and Sign & Encryption.Applies_To : Against which service you are going to use this Token, obtained from the STS – or in other words, the scope of the token. This can be any URI known to the STS. STS may use this URI to find public key of that service and will use that to encrypt the key issued. So, whatever you put should be meaningful to your STS.Token_Type : It can be any one of the following…1. http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV2.0 2. http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV1.1Key_Type : It can be any one of the following…1. /SymmetricKey : A symmetric key token is requested (default) 2. /PublicKey : A public key token is requested 3. /Bearer : A bearer token is requested. This key type can be used by requestors to indicate that they want a security token to be issued that does not require proof of possession.Key_Size : Size of the key. By default it’s being set to 256. This is an integer element indicates the size of the key REQUIRED specified in number of bits.Claim_Dialect : Claim dialect which is known the STS. This can be used to group set of claims together.Required_Claims : URIs known to the STS which indicate the required set of attributes. This can be a comma separated list.System_Trust_Store : When the URL to the STS is on https – this indicates the location to the JKS file which includes the public certificate corresponding to the STS endpoint.System_Trust_Store_Password : Password to access System_Trust_StoreUsername : This is required when the STS is secured with UsernameToken security policy. This is the corresponding user name.Password : Password corresponding to the above Username.Encryption_Key_Store : This is required when the STS is secured with WS-Security Encryption. Location of the JKS where the public key of the STS endpoint being stored.Encryption_Key_Store_Password : Password corresponding to the Encryption_Key_Store.Encryption_Key_Alias : Alias from the Encryption_Key_Store corresponding to the STS endpoint. This helps to load the public key of STS.Signature_Key_Store : This is required when the STS is secured with WS-Security Signature. Location of the JKS where the private key of the STS client being stored.Signature_Key_Store_Password : Password corresponding to the Signature_Key_Store.Signature_Key_Alias : Alias from the Signature_Key_Store corresponding to the STS client. This helps to load the private key of STS client.Signature_Key_Password : Password corresponding to the private key of the STS client.Following is an example configuration that I used to load test STS which ships with WSO2 Identity Server.Reference: Extending JMeter with a WS-Trust/STS sampler from our JCG partner Prabath Siriwardena at the Facile Login blog....
jsf-logo

JSF Event-based communication: Old-school approach

Web applications written in JSF consist of beans which interact among each other. Communication between beans is one of the main design patterns when developing a web application. Sometimes, one bean need to send events to other beans to inform them about some changes or whatever else. We can normally inject a managed or Spring bean into the property of another bean, so that another bean can notify injected bean directly. Injection is good, but it was not introduced for the purpose of communication. It is far away from a dynamic loosely coupled system where each bean doesn’t know about other beans. In a loosely coupled system we need a good event-based communication mechanism. This post will cover two design patterns: Observer / Event Listener and Mediator pattern. These patters are widely used in many web applications nowadays, but they have disadvantages. The system is not really loosely-coupled with them. There are much better and modern approaches. Therefore, I wrote “Old-school approach” in the post name. New-school approaches will be disclosed in the next post. Observer / Event Listener   We will start with the Observer (also called as Event Listener) pattern. An object, called the subject or observable object, maintains a list of its dependents, called observers, and notifies them automatically of any state changes. In Java there are classes java.util.Observer and java.util.Observable which help to implement this pattern. Other related constructs for event-based communication by means of this pattern are the class java.util.EventObject and the interface java.util.EventListener. Let’s start coding. Assume we have a I18N web application and user can choose a language (Locale) somewhere in user settings. Assume we have a bean called UserSettingsForm which is responsible for user settings. Some session scoped beans can keep I18N text / messages, so that when user changes the current languages, a reset of previous text / messages in the last selected language is needed. Firstly, we need a LocaleChangeEvent. public class LocaleChangeEvent extends EventObject { Locale locale;public LocaleChangeEvent(Object source, Locale locale) { super(source); this.locale = locale; }public Locale getLocale() { return locale; } }Secondly, we need an interface LocaleChangeListener. public interface LocaleChangeListener extends EventListener { void processLocaleChange(LocaleChangeEvent event); }Our UserSettingsForm can manage now instances of type LocaleChangeListener by registring and notifying them. @ManagedBean @SessionScoped public class UserSettingsForm implements Serializable {private Locale selectedLocale; private List<SelectItem> locales; private List<LocaleChangeListener> localeChangeListeners = new ArrayList<LocaleChangeListener>();public void addLocaleChangeListener(LocaleChangeListener listener) { localeChangeListeners.add(listener); }public void localChangeListener(ValueChangeEvent e) { ... // notify listeners LocaleChangeEvent lce = new LocaleChangeEvent(this, this.selectedLocale); for (LocaleChangeListener lcl : localeChangeListeners) { lcl.processLocaleChange(lce); } } ... }The method localChangeListener() is an JSF ValueChangeListener and can be applied e.g. in h:selectOneMenu. Every bean which implements LocaleChangeListener should be registered by UserSettingsForm in order to be notified by locale changes. @ManagedBean @SessionScoped public MyBean implements LocaleChangeListener, Serializable {// UserSettingsForm can be injected e.g. via @ManagedProperty annotation or via Spring facility private UserSettingsForm userSettingsForm;@PostConstruct public void initialize() { userSettingsForm.addLocaleChangeListener(this); }public void processLocaleChange(LocaleChangeEvent event) { // reset something related to I18N data ... } }In terms of Observer pattern the UserSettingsForm is Observable and instances of LocaleChangeListener (like MyBean) are Observers. The discussed pattern comes with some important issues that you need to be aware of. Beans are tightly coupled. There are a lot of manually work to regsiter beans. Beans have to implement defined interfaces. If you have a bean informed by 100 semantic different changes, it has to implement 100 interfaces. It is not possible to notify a subset of registered listeners – always all listeners get notified even if they don’t need to be notified. Last but not least – memory management issue. Martin Fowler wrote “Assume we have some screens observing some domain objects. Once we close a screen we want it to be deleted, but the domain objects actually carry a reference to the screen though the observer relationship. In a memory-managed environment long lived domain objects can hold onto a lot of zombie screens, resulting in a significant memory leak.” Mediator    The Mediator pattern improves the event-based communication in comparison to the Observer / Event Listener pattern. With the mediator pattern, communication between objects is encapsulated with a mediator object. Objects no longer communicate directly with each other, but instead communicate through the mediator. This reduces dependencies between communicating objects. We will see how it works for JSF-Spring beans (in examples above were standard managed beans). We will implement a Mediator class to manage the communication between scoped beans. It is important to understand that a bean only can notify another beans having broader scope(s). A view scoped bean can notify view, session and application scoped beans, but not request scoped beans with the narrower scope. Follow this rule to avoid troubles. This is a nature of scoped bean – you might remember that you can always inject a bean of wider scope into a bean of narrower scope, but not vice versa. To start working with Mediator we will introduce two interfaces MediatorEvent, MediatorListener and the centric class Mediator. public interface MediatorEvent { ... }public interface MediatorListener {public void listenToEvent(MediatorEvent event); }public class Mediator implements Serializable {private Collection<MediatorListener> collaborators = new HashSet<MediatorListener>();public static Mediator getCurrentInstance() { // access Mediator bean by JSF-Spring facility return ContextLoader.getCurrentWebApplicationContext().getBean("mediator"); }public void fireEvent(MediatorEvent event) { for (MediatorListener mediatorListener : collaborators) { mediatorListener.listenToEvent(event); } }public void addCollaborator(MediatorListener collaborator) { collaborators.add(collaborator); }public void removeCollaborator(MediatorListener collaborator) { collaborators.remove(collaborator); } }Mediator is a scoped bean which can register and notify collaborators. Collaborators register themself by Mediator. In Spring, a bean can implement the interface InitializingBean, so that the method afterPropertiesSet() will be called automatically after the bean’s instantiation. This is similar to @PostConstruct. afterPropertiesSet() is a right place for such bean to register itself by Mediator. The bean should also implement MediatorListener in order to be notified (see listenToEvent()). public MyBean implements MediatorListener, InitializingBean, Serializable {public void afterPropertiesSet() throws Exception { ... Mediator.getCurrentInstance().addCollaborator(this); }@Override public void listenToEvent(MediatorEvent event) { if (event instanceof LocaleChangeEvent) { // do something } } }We will use the same scenario with UserSettingsForm and locale changing. Beans registered by Mediator will be notified by fireEvent(). public class LocaleChangeEvent implements MediatorEvent { ... }public class UserSettingsForm implements Serializable {private Locale selectedLocale; private List<SelectItem> locales;public void localChangeListener(ValueChangeEvent e) { ... // notify listeners Mediator.getCurrentInstance().fireEvent(new LocaleChangeEvent(this, this.selectedLocale)); } ... }Mediator pattern offers better coupling between beans, but they are still coupled with mediator. Further disadvantages: It is still necessary to register beans manually – see extra code Mediator.getCurrentInstance().addCollaborator(this). Every bean should still implement at least one MediatorListener and that brings another constraint – listenToEvent(). Every bean should implement this interface method! The probably biggest shortcoming of Mediator pattern in JSF is that it is a scoped bean. A view scoped Mediator would only work smoothly with view scoped beans. Registered view scoped beans are being removed automatically when the view scoped Mediator gets destroyed. Other scenarios can cause memory leaks or several issues. For instance, request scoped beans, registered by a view scoped Mediator, should be removed manually by calling removeCollaborator() (easy to forget). Session scoped beans should be registered by a session scoped Mediator, otherwise they will not be notified after destroying the view scoped Mediator. Etc, etc. In the fact, the Mediator pattern is only one step better than a regular Observer / Event Listener concept. There are more flexible approaches where *any method* can catch thrown event and not only fix specified, like listenToEvent(). In the next post, we will see easy and unobtrusive ways how to catch multiply events by only one method and other advices. Reference: Event-based communication in JSF. Old-school approach from our JCG partner Oleg Varaksin at the Thoughts on software development blog....
devops-logo

Monitoring Sucks. But Monitoring as Testing Sucks a Lot More

At Devopsdays I listened to a lot of smart people saying smart things. And to some people saying things that sounded smart, but really weren’t. It was especially confusing when you heard both of these kinds of things from the same person.Like at Noah Sussman’s presentation on how rapid release cycles alter QA and testing, based on the work he did when he was the test architect at Etsy.Sussman is a smart guy who knows about testing. He wanted to get some important messages across about how to do testing and QA in a Continuous Deployment environment. If you’re releasing small changes to production 20 or 30 or 40 times a day, there’s no time for manual testing and QA. So you have to push a lot of responsibility back to the development team to review and test their own work. Testers can still look for problems through exploratory testing and system testing, but they won’t be able to find bugs in time – the code may already be out by the time that they get a chance. So you need to be prepared for problems in production, and to respond to them.The Smart Things “The fewer assumptions that developers make, the better everything works”.A developer’s job is to keep things as simple as they can, and understand and validate their assumptions by reviewing and testing and profiling their code. A tester’s job is to invalidate assumptions – through boundary testing and exploratory testing and things like fuzzing and penetration testing.                        “There are a finite number of detectable bugs”.Everyone should be prepared for bugs in production – it’s irresponsible not to. “QA should be focusing on risk, not on giving management false confidence that the site won’t go down”.  “It’s more important to focus on resilience than “quality”: readable code, reasonable test coverage, a sane architecture, good tools, an engineering culture that values refactoring.” The Things that Sounded Smart, but Weren’t  “The whole idea of preventive QA or preventive testing is a fraud”.Try telling that to the people testing flight control software or people testing medical equipment, or critical infrastructure systems, or…. “Assurance is a terrible word. Let’s discard it”.Ummmm. Assurance probably means zip to online web startups. But what about industries where assurance is a regulatory requirement, for good reasons? “There’s no such thing as a roll-back. You just have to deal with what’s deployed right now”.This was repeating something presented at Velocity, that roll-back is a myth, because you can’t go back in time or whatever. I’ve responded to this crap before, so I won’t bother going into it detail again here, except to say that people need to understand that there are times when rolling forward is the right answer, and there are other times when rolling back is a better answer, and that if you’re doing a responsible job of managing an online business, you had better understand this and be prepared to do both. “Real-time monitoring is the new face of testing” and “monitoring is more important than unit testing”.I get the point that Monitoring Sucks,that developers have to put more thought and attention into monitoring and metrics – this is something that we’re still learning at my shop after putting several years of hard work into it. But there is NFW that a developer should put monitoring before unit testing, unless maybe you are trying to launch an online consumer web startup that doesn’t handle any money or private data and that doesn’t connect with any systems that do, and you need to get 1.0 up before you run out of money – and as long as you recognize that what you are doing is stupid but necessary and that you will need to go back and do it again right later.If you’re in an environment where you depend on developers to do most or all of the testing, and then tell them they should put monitoring in front of testing, then you aren’t going to get any testing done. How is this possibly supposed to be a good thing?Monitoring as Testing SucksUnfortunately I missed most of a follow-up Open Space session on Continuous Deployment and quality. I did come in time to hear another smart person say: “The things that fail are the things that you didn’t test”By which I think he meant that you wasted your time testing the things that worked when you should have been testing the things that didn’t. But of course, if the things that fail are the things that you didn’t test, and you didn’t test anything, then everything will fail. Maybe he meant both of these things at the same time, a kind of Zen koan.Gene Kim promised to write up some notes from this session. Maybe something came out of this that will make some sense out of the “Monitoring as Testing” idea.I like a lot of what I heard at Devopsdays, it made me re-think how we work and where we put our attention and time. There’s some smart, challenging thinking coming out of devops. But there’s also some dangerously foolish and irresponsible smart-sounding noise coming out at the same time – and I hope that people will be able to tell the difference.Reference: Monitoring Sucks. But Monitoring as Testing Sucks a Lot More from our JCG partner Jim Bird at the Building Real Software blog....
software-development-2-logo

A necessary condition for hiring a new developer

Software developers often take part in the recruiting process. Determine whether a candidate is suitable for our team/company is a challenge to say the least. This is especially correct for us – software developers with no HR training and in most cases used to take decisions based on well constructed set of rules. However, this is not the case we face in the recruiting process. This process requires us to use general guidelines, our experience and intuition.At our company the recruiting process begins with a professional interview where the candidate is asked to code something, design something and show understanding regarding the running environment.Who passes the professional interview stage? We do not have golden rules. After each interview we conduct a short meeting to decide whether the candidate is suitable or not. We use similar questions throughout all of our interviews which enable us to better compare candidates. We interview in pairs and each interviewer can veto. We believe our general impression has the most weight on our decision.How hard it is to make a decision?Well as Joel Spolsky once wrote, there are three kind of candidates. The ones that you easily know you want, the ones you easily know you don’t want and the maybes. Most of the effort is invested in the latter.Lately we started noticing that the ones we eventually hire from the maybes group have a certain characteristic. It is the ability of the candidate to evaluate his own answers. When asked a question, he knows which information is missing in order to answer it well. He will then state what he knows and what is missing. If he has been asked to solve a problem he will be able to state which aspects of the problem his solution works for, and ask for more info in order to provide a complete solution.A candidate which does not have said characteristic behaves differently. They write code that doesn’t work and algorithms that does not do as expected. The problem with this kind of candidates is that we had to tell them that there solution does not work. They supply shallow, inaccurate, missing answers while they believe they answered the question fully.This ability of the candidate to evaluate his own answers is extremely important for software developers. As developers, almost every task requires evaluating which information is missing in order to complete the task successfully. Developers that do not have the ability to evaluate missing information will start coding too early and write bad code.Following this characteristic, we thought we might test this directly in the interview:Ask the candidate directly what information he is missing to answer the question? This is good for knowledge questions. Ask a very hard question. The candidate does not have a chance of answering. What we are really looking for if to see if he realizes that instead of providing false answers, he can show us his way of thinking. Guesstimate questions. Ask to design something with little information and hope he will ask you for what he is missing.That’s it. We hope it will help you add another aspect for your interviews.Reference: A necessary condition for hiring a new developper from our JCG partner Nadav Azaria & Roi Gamliel at the DeveloperLife blog....
apache-jmeter-logo

Extending JMeter with a password digest generator

Recently I had to work on loading an OpenLDAP instance with 50,000 user records and carry on some stress testing. JMeter was the best choice to populate the LDAP. But.. in my case, OpenLDAP was configured not to accept any clear text passwords. So, I could not login in with any of the random generated passwords I added via JMeter LDAP Request sampler. This made me to write this extension to JMeter, which can be used in a generic way to generate message digest of a given text. You can download the JAR file from here. Then, you need to copy this to JMETER_HOME\lib\ext. In your test plan, add a Java Request sampler to the thread group, just before where the digested text is needed. Now, select, org.wso2.apache.jmeter.message.digest.DigestGenerator. Then you can set a hashing algorithm and which text to be digested. In that case, you can set a variable or text as it is. That’s it – once done, you can access the digest value via ${password}.Reference: Extending JMeter with a password digest generator from our JCG partner Prabath Siriwardena at the Facile Login blog....
jboss-drools-logo

JBoss BRMS 5.3 – adding on Business Activity Monitoring (BAM) Reporting

One of the most often asked question since the release of the JBoss BRMS 5.3 product which has added the jBPM 5 BPM component is that of Business Activity Monitoring (BAM) and Reporting features. This article will walk you through the process of adding it, but be aware, this is not a supported feature of the product at the time of this writing. Adding on BAM Reporting to JBoss BRMS 5.3Install JBoss BRMS 5.3, download from the Customer Portal. Create a birt directory at the following location JBOSS_HOME/server/default/data/birt/ Create the ReportEngine and output directories in the birt directory from step 2 as follows:JBOSS_HOME/server/default/data/birt/ReportEngine / JBOSS_HOME/server/default/data/birt/ouput/Download birt-runtime-2_3_2_2 runtime jar from the following location :http://www.eclipse.org/downloads/download.php?file=/birt/downloads/drops/R-R1-2_3_2_2-200906011507/birt-runtime-2_3_2_2.zip&url=http://download.eclipse.org/birt/downloads/drops/R-R1-2_3_2_2- 200906011507/birt-runtime-2_3_2_2.zip&mirror_id=1Unzip birt-runtime-2_3_2_2/ReportEngine into the JBOSS_HOME/server/default/data/birt/ReportEngine/ directory. Download overall_activity.rptdesign and process_summary.rptdesign report design files from the following location:https://github.com/droolsjbpm/jbpm/tree/master/jbpm-installer/report/2_3_2_2 Copy the files to JBOSS_HOME/server/default/data/birt/Copy h2.jar from /jbpm/lib to the JBOSS_HOME/server/default/data/birt/ReportEngine/plugins/org.eclipse.birt.report.data.oda.jdbc_2.3.2.r232_v20090212/drivers/ directory. Delete report-core-1.4.0-SNAPSHOT.jar and report-shared-1.4.0-SNAPSHOT.jar from the JBOSS_HOME/server/default/deploy/gwt-console-server.war/WEB-INF/lib/ directory. Download the following jars and copy them to the JBOSS_HOME/server/default/deploy/gwt-console-server.war/WEB-INF/lib/ directory.report-core-1.3.0.jarhttps://repository.jboss.org/nexus/content/repositories/releases/org/jboss/bpm/report-core/1.3.0/report-core-1.3.0.jarreport-shared-1.3.0.jarhttps://repository.jboss.org/nexus/content/repositories/releases/org/jboss/bpm/reportshared/1.3.0/report-shared-1.3.0.jarengineapi-2.3.2.jarhttp://repository.jboss.org/nexus/content/groups/public/org/eclipse/birt/engineapi/2.3.2/engineapi-2.3.2.jardteapi-2.3.2.jarhttp://repository.jboss.org/nexus/content/groups/public/org/eclipse/birt/dteapi/2.3.2/dteapi-2.3.2.jarchartengineapi-2.3.2.jarhttp://repository.jboss.org/nexus/content/groups/public/org/eclipse/birt/chartengineapi/2.3.2/chartengineapi-2.3.2.jarcoreapi-2.3.2.jarhttp://repository.jboss.org/nexus/content/groups/public/org/eclipse/birt/coreapi/2.3.2/coreapi-2.3.2.jardataadapterapi-2.3.2.jarhttp://repository.jboss.org/nexus/content/groups/public/org/eclipse/birt/dataadapterapi/2.3.2/dataadapterapi-2.3.2.jarmodelapi-2.3.2.jarhttp://repository.jboss.org/nexus/content/groups/public/org/eclipse/birt/modelapi/2.3.2/modelapi-2.3.2.jarscriptapi-2.3.2.jarhttp://repository.jboss.org/nexus/content/groups/public/org/eclipse/birt/scriptapi/2.3.2/scriptapi-2.3.2.jarecore-2.4.2.jarhttp://repository.jboss.org/nexus/content/groups/public/org/eclipse/emf/ecore/2.4.2/ecore-2.4.2.jarecore-xmi-2.4.1.jarhttp://repository.jboss.org/nexus/content/groups/public/org/eclipse/emf/ecore-xmi/2.4.1/ecorexmi-2.4.1.jarcommon-2.4.0.jarhttp://repository.jboss.org/nexus/content/groups/public/org/eclipse/emf/common/2.4.0/common-2.4.0.jarflute-1.2.jarhttp://repository.jboss.org/nexus/content/groups/public/org/w3c/flute/1.2/flute-1.2.jarsac-1.3.jarhttp://repository.jboss.org/nexus/content/groups/public/org/w3c/sac/1.3/sac-1.3.jarcommons-cli-1.0.jarhttp://repo1.maven.org/maven2/commons-cli/commons-cli/1.0/commons-cli-1.0.jarcommons-discovery-0.2.jarhttp://repo1.maven.org/maven2/commons-discovery/commons-discovery/0.2/commonsdiscovery-0.2.jaritext-1.3.jarhttp://repo1.maven.org/maven2/com/lowagie/itext/1.3/itext-1.3.jaricu4j-3.8.1.jarhttp://repository.jboss.org/nexus/content/groups/public/com/ibm/icu/icu4j/3.8.1/icu4j-3.8.1.jarjs-1.6R2.jarhttp://repo1.maven.org/maven2/rhino/js/1.6R2/js-1.6R2.jarTo view the reports in the Business Central Console go to http://localhost:8080/business-central and log on, see the JBoss BRMS Getting Started Guide for further details. To collect the Business Activity Monitoring performance parameters for a task or process, first run the task or process, and then click on the reports tab on the left pane. This will open the report configuration tab in the right pane. Select ‘overall_activity’ from the drop down and click create to view the report on the performance parameters of the executed process. Install BIRT plugin into JBoss Developer Studio (JBDS)Open JBDS and select Help > Install New Software. In the Work with text box enter BIRT Update Site – http://download.eclipse.org/birt/updtae-site/3.7 and click ADD…. The following packages should be listed for selection:BIRT 3.7 Charting SDK BIRT 3.7 Engine OSGI Runtime SDK BIRT 3.7 Reporting SDK BIRT 3.7 WTP Integration SDKSelect all and click next. Follow the instructions on the installation screen. Restart JBDSEnjoy! Reference: JBoss BRMS 5.3 – adding on Business Activity Monitoring (BAM) Reporting from our JCG partner Eric D. Schabell at the Thoughts on Middleware, Linux, software, cycling and other news… blog....
jboss-hibernate-logo

Generational caching and Envers

Konrad recently shared on our company’s technical room an interesting article on how caching is done is a big polish social network, nk.pl. One of the central concepts in the algorithm is generational caching (see here or here). The basic idea is that for cache keys you use some entity-specific string + version number. The version number increases whenever data changes, thus invalidating any old cache entries, and preventing stale data reads. This makes the assumption that the cache has some garbage collection, e.g. it may simply be a LRU cache. Of course on each request we must know the version number – that’s why it must be stored in a global cache (but depending on our consistency requirements, it also may be distributed across the cluster asynchronously). However the data itself can be stored in local caches. So if our system is read-most, the only “expensive” operation that we will have to do per request is retrieve the version numbers for the entities we are interested in. And this is usually very simple information, which can be kept entirely in-memory. Depending on the type of data and the usage patterns, you can cache individual entities (e.g. for a Person entity, the cache key could be person-9128-123, 9128 being the id, 123 the version number), or the whole lot (e.g. for a Countries entity, the cache key could be countries-8, 8 being the version number). Moreover in the global cache you can keep the latest version number per-id or per-entity; meaning that when the version changes, you invalidate a specific entity or all of them. Having written most of Envers, it quite naturally occurred to me that you may use the entity revision numbers as the cache versions. Subsequent Envers revisions are monotonically increasing numbers, for each transaction you get the next one. So whenever a cached entity changes, you would have to populate the global cache with the latest revision number. Envers provides several ways to get the revision numbers. During the transaction, you can call AuditReader.getCurrentRevision() method, which will give you the revision metadata, including the revision number. If you want more fine-grained control, you may implement your own listener (EntityTrackingRevisionListener), see the docs), and get notified whenever an entity is changed, and update the global cache in there. You can also register an after-transaction-completed callback, and update the cache outside of the transaction boundaries. Or, if you know the entity ids, you may lookup the maximum revision number using either AuditReader.getRevisions or an AuditQueryCreator. As you can obtain the current revision number during a transaction, you may even update the version/revision in the global cache atomically, if you use a transactional cache such as Infinispan. All of that of course in addition to auditing, which is still the main purpose of Envers :) Reference: Generational caching and Envers from our JCG partner Adam Warski at the Blog of Adam Warski blog....
enterprise-java-logo

Understanding the concept behind ThreadLocal

Intro I was aware of thread local but never had the occasion of really using it until recently. So I start digging a little bit on the subject because I needed an easy way of propagating some user information via the different layers of my web application without changing the signature of each method called. Small prerequisite info A thread is an individual process that has its own call stack.In Java, there is one thread per call stack or one call stack per thread.Even if you don’t create any new threads in your program, threads are there running without your knowledge.Best example is whenyou just start a simple Java program via main method,then you do not implicitly call new Thread().start(), but the JVM creates a main thread for you in order to run the main method. The main thread is quite special because it is the thread from which all the other thread will spawn and when this thread is finished, the application ends it’s lifecycle. In a web application server normally there is a pool of of threads ,because a Thread is class quite heavyweight to create.All JEE servers (Weblogic,Glassfish,JBoss etc) have a self tuning thread pool, meaning that the thread pool increase and decrease when is needed so there is not thread created on each request, and existing ones are reused. Understanding thread local In order to understand better thread local I will show very simplistic implementation of one custom thread local. package ccs.progest.javacodesamples.threadlocal.ex1;import java.util.HashMap; import java.util.Map;public class CustomThreadLocal {private static Map threadMap = new HashMap();public static void add(Object object) { threadMap.put(Thread.currentThread(), object); }public static void remove(Object object) { threadMap.remove(Thread.currentThread()); }public static Object get() { return threadMap.get(Thread.currentThread()); }} So you can call anytime in your application the add method on CustomThreadLocal and what it will do is to put in a map the current thread as key and as value the object you want to associate with this thread. This object might be an object that you want to have access to from anywhere within the current executed thread, or it might be an expensive object you want to keep associated with the thread and reuse as many times you want. You define a class ThreadContext where you have all information you want to propagate within the thread.     package ccs.progest.javacodesamples.threadlocal.ex1;public class ThreadContext {private String userId;private Long transactionId;public String getUserId() { return userId; }public void setUserId(String userId) { this.userId = userId; }public Long getTransactionId() { return transactionId; }public void setTransactionId(Long transactionId) { this.transactionId = transactionId; }public String toString() { return 'userId:' + userId + ',transactionId:' + transactionId; }} Now is the time to use the ThreadContext. I will start two threads and in each thread I will add a new ThreadContext instance that will hold information I want to propagate for each thread. package ccs.progest.javacodesamples.threadlocal.ex1;public class ThreadLocalMainSampleEx1 {public static void main(String[] args) { new Thread(new Runnable() { public void run() { ThreadContext threadContext = new ThreadContext(); threadContext.setTransactionId(1l); threadContext.setUserId('User 1'); CustomThreadLocal.add(threadContext); //here we call a method where the thread context is not passed as parameter PrintThreadContextValues.printThreadContextValues(); } }).start(); new Thread(new Runnable() { public void run() { ThreadContext threadContext = new ThreadContext(); threadContext.setTransactionId(2l); threadContext.setUserId('User 2'); CustomThreadLocal.add(threadContext); //here we call a method where the thread context is not passed as parameter PrintThreadContextValues.printThreadContextValues(); } }).start(); } }Notice: CustomThreadLocal.add(threadContext) is the line of code where the current thread is associated with the ThreadContext instance As you will see executing this code the result will be: userId:User 1,transactionId:1 userId:User 2,transactionId:2How this is possible because we did not passed as parameter ThreadContext ,userId or trasactionId to printThreadContextValues ? package ccs.progest.javacodesamples.threadlocal.ex1;public class PrintThreadContextValues { public static void printThreadContextValues(){ System.out.println(CustomThreadLocal.get()); } } Simple enough When CustomThreadLocal.get() is called from the internal map of CustomThreadLocal it is retrived the object associated with the current thread. Now let’s see the samples when is used a real ThreadLocal class. (the above CustomThreadLocal class is just to understand the principles behind ThreadLocal class which is very fast and uses memory in an optimal way) package ccs.progest.javacodesamples.threadlocal.ex2;public class ThreadContext {private String userId; private Long transactionId;private static ThreadLocal threadLocal = new ThreadLocal(){ @Override protected ThreadContext initialValue() { return new ThreadContext(); }}; public static ThreadContext get() { return threadLocal.get(); } public String getUserId() { return userId; } public void setUserId(String userId) { this.userId = userId; } public Long getTransactionId() { return transactionId; } public void setTransactionId(Long transactionId) { this.transactionId = transactionId; }public String toString() { return 'userId:' + userId + ',transactionId:' + transactionId; } } As javadoc describes : ThreadLocal instances are typically private static fields in classes that wish to associate state with a thread package ccs.progest.javacodesamples.threadlocal.ex2;public class ThreadLocalMainSampleEx2 {public static void main(String[] args) { new Thread(new Runnable() { public void run() { ThreadContext threadContext = ThreadContext.get(); threadContext.setTransactionId(1l); threadContext.setUserId('User 1'); //here we call a method where the thread context is not passed as parameter PrintThreadContextValues.printThreadContextValues(); } }).start(); new Thread(new Runnable() { public void run() { ThreadContext threadContext = ThreadContext.get(); threadContext.setTransactionId(2l); threadContext.setUserId('User 2'); //here we call a method where the thread context is not passed as parameter PrintThreadContextValues.printThreadContextValues(); } }).start(); } }When get is called , a new ThreadContext instance is associated with the current thread,then the desired values are set the ThreadContext instance. As you see the result is the same as for the first set of samples. userId:User 1,transactionId:1 userId:User 2,transactionId:2 (it might be the reverse order ,so don’t worry if you see ‘User 2? first) package ccs.progest.javacodesamples.threadlocal.ex2;public class PrintThreadContextValues { public static void printThreadContextValues(){ System.out.println(ThreadContext.get()); } } Another very usefull usage of ThreadLocal is the situation when you have a non threadsafe instance of an quite expensive object.Most poular sample I found was with SimpleDateFormat (but soon I’ll come with another example when webservices ports will be used) package ccs.progest.javacodesamples.threadlocal.ex4;import java.text.SimpleDateFormat; import java.util.Date;public class ThreadLocalDateFormat { // SimpleDateFormat is not thread-safe, so each thread will have one private static final ThreadLocal formatter = new ThreadLocal() { @Override protected SimpleDateFormat initialValue() { return new SimpleDateFormat('MM/dd/yyyy'); } }; public String formatIt(Date date) { return formatter.get().format(date); } }Conclusion: There are many uses for thread locals.Here I describe only two: (I think most used ones)Genuine per-thread context, such as user id or transaction id. Per-thread instances for performance.Reference: Understanding the concept behind ThreadLocal from our JCG partner Cristian Chiovari at the Java Code Samples blog....
software-development-2-logo

The Software Developer’s Pensieve

Fictional stories (especially science fiction) are full of gadgets and other items that I wish were available to me today. One of the fictional items I would most like to have is the pensieve described in Harry Potter books and shown in Harry Potter movies. This pensieve allows the participant to save his or her memories so that he or she can review them again from a third-person perspective with the clarity of being back in that memory again. Although we don’t have pensieves in our world, there are some relatively recent innovations that do bring us closer to it. I look at some of these in this post and describe why they are useful to the software developer trying to recall why a particular decision was made or even what the decision was. Most serious engineers have learned to appreciate a medium for saving thoughts, decisions, and results of experiments or discussions for later reference. This is no less valuable for the software developer. Personal Blogs One of my motivations for writing this software development-oriented blog is as a form of a pensieve for observations and lessons learned related to software development. My JavaWorld-syndicated version of this blog includes this very motivation in its description: ‘This blog is intended to provide information to help other developers facing the same issues as well as providing me a method to document things in a well-known location for my own future reference.’ Because of their publicly available online nature, personal blogs are easy to access from almost anywhere. Blogger added a new Gadget a while back that allows me to provide a powerful Google Search-backed search of my blog’s content. This makes it easier than ever to find something I know I wrote about it when I need certain details that I’ve forgotten. Re-reading one of my posts or the example code in one of my posts often brings back many other details related to the post. E-mail With modern e-mail systems offering large amounts of data storage space, it is easier than ever to store information in my mail storage. E-mail may be preferable to a personal blog post if it seems only individually interesting rather than generally interesting or if it contains details that are not appropriate for public consumption. E-mail tends to be easily searchable as well. E-mail is really more of a powerful communication tool than a pensieve substitute, but it can serve that function to a lesser degree. Using e-mail as a pensieve has its drawbacks. Changing e-mail systems can be problematic if previous experience is only available in the older e-mail system. E-mail can also be more temporary in nature in some cases where aggressive e-mail purging occurs. A feature of e-mail that can be both an advantage and a disadvantage is the nature of the multi-way communication that occurs in a given e-mail thread. A particular thread can be rich with details leading to a design decision or other important details, but these same important details can also be difficult to glean from the verbosity of some e-mail threads. Splitting e-mail threads can also make it difficult to confidently reconstruct a particular decision or discussion. Online Collaborative Tools (Google Docs) I have been using Google Docs in a variety of work-related and personal-related areas and really enjoy the collaborative nature of these products. Having others be able to instantly see my changes and my being able to instantly see their changes is very useful. In addition, the ability to see the ‘latest and greatest’ anywhere that I have online access is liberating because I don’t need to worry about having access to the productivity software products on any computers I’m using and, even better, I don’t need to worry about ensuring that the latest version of the file is available on some medium. These online tools have many of the advantages of the Wiki (discussed next), but tend to be useful for smaller groups of people where the ‘overhead’ of the Wiki does not seem justifiable or where the people involved are more comfortable working with productivity software such as spreadsheets, presentations, and documents than they are with Wiki text and HTML. Wiki Most software developers can quickly and easily pick up the basics of any given Wiki product and quickly start using it effectively. Wikis seem to be a natural fit for software developers and in many ways feel to me like an extension of the approach I used years ago of creating static web pages to store information for others’ reference and for my own personal future reference. Wikis are easier to add content to than static web pages and are far easier for multiple authors to edit. One of the major advantages of Wikis over static web pages and even over the online collaborative tools is the built-in versioning. It is often useful to see a previous version of a particular Wiki entry. Versioned Wiki pages are a sort of versioned Pensieve, allowing the developer to determine what (s)he or others was thinking or deciding at any given point in time. Another advantage of the Wiki is the ability to easily link to other HTML material such as Javadoc, online product documentation, bug or defect reports, and related blogs and articles. Conclusion We have many fine tools available to us today for recording important decisions and lessons learned. I have seen these technologies improve dramatically during my career, but the degree of improvement is even larger when compared to the documentation tools described in The Mythical Man-Month. It is exciting to think about what the future holds in store for improving our ability to persist our memories in a fashion that allows us to easily recall them and feel as if we’re experiencing again a moment from our past. Reference: The Software Developer’s Pensieve from our JCG partner Dustin Marx at the Inspired by Actual Events blog....
Java Code Geeks and all content copyright © 2010-2014, Exelixis Media Ltd | Terms of Use | Privacy Policy
All trademarks and registered trademarks appearing on Java Code Geeks are the property of their respective owners.
Java is a trademark or registered trademark of Oracle Corporation in the United States and other countries.
Java Code Geeks is not connected to Oracle Corporation and is not sponsored by Oracle Corporation.
Do you want to know how to develop your skillset and become a ...
Java Rockstar?

Subscribe to our newsletter to start Rocking right now!

To get you started we give you two of our best selling eBooks for FREE!

Get ready to Rock!
You can download the complementary eBooks using the links below:
Close