Dependency Injection on Stateless Beans

I recently came across a situation where I needed to inject a dependency into a class that, when used, was expected to be stateless. I'm using Spring as the dependency injection container, and this class is instantiated directly from the class, and not through Spring context; thus, I could not use Spring context with basic dependency injection. Did my Google search, but did not find an answer, so I'm posting this because the solution was fairly simple and needed to be shared.

The scenario (assuming you're familiarized with JPA, Spring, and overall dependency injection) 
I have a utility class that is responsible for indexing entities using Lucene. I wanted to add this utility to a JPA listener so that it can create or update the index on the entity in a @PrePersist method. Why this way, and not through a service? Good question. The entity could be persisted directly through a service, directly using Entity Manager, or as a cascade effect when persisting an entity that contains this entity as a property. So, in order to ensure that the index is created/updated, I wanted to provide a listener that would do that prior to saving the entity.

The service class that creates/updates indexes needs to be instantiated by Spring context so that it can have all the indexing dependencies, such as the location of the indexes, so if I wanted a Listener to do this task, I needed to inject this instantiated bean by Spring context into the listener. But, JPA listeners are supposed to be stateless, Entity Manager does not call Spring context to get a reference of an instantiated listener, rather it uses the class specified in the @EntityListeners annotation and instantiates it directly. So, what to do?

Solution
If the search service, the service that does the indexing as well, can be declared as static in the Listener, surely it will be accessible when JPA executes a persist of the entity by any method.


@Component
public class EntityIndexListener
{
    static private SearchService searchService;
    ...




Declaring static is part of the solution, we still need to inject the instantiated class by Spring context to it. For this we create a set method, the same as we would as for any other dependency.


@Autowired(required = true)
@Qualifier("searchService")
public void setSearchService(SearchService searchService)
{
    this.searchService = searchService;
}

This will setup the dependency, assuming autowire is configured. If autowire is not configured, you can define the dependency explicitly. 

One last thing; to ensure that Spring does the injection at startup, declare an init method solely for the purpose of "telling" Spring that this method needs to be instantiated at startup, so that this method can be executed. The init method does not need to do anything.

@PostConstruct

public void init()

{

    logger.info("Initializing Search Service for Listener ["+ searchService +"]");

}

Hope this helps.

Master the Crucial Non-Technical Skills Every Software Architect Needs

Thousands of software professionals have the necessary technical qualifications to become architects, but far fewer have the crucial non-technical skills needed to get hired and succeed in this role. In today's agile environments, these “soft” skills have grown even more crucial to success as an architect. For many developers, however, these skills don’t come naturally–and they’re rarely addressed in formal training. Now, long-time software architect Dave Hendricksen helps you fill this gap, supercharge your organizational impact, and quickly move to the next level in your career.

In his book, 12 Essential Skills for Software Architects, Hendricksen begins by pinpointing the specific relationship, personal, and business skills that successful architects rely upon. Next, he presents proven methods for systematically developing and sharpening every one of these skills, from negotiation and leadership to pragmatism and vision.

From start to finish, this book’s practical insights can help you get the architect position you want–and thrive once you have it.

The soft skills you need... and a coherent framework and practical methodology for mastering them!

Relationship Skills

• Gracious Behavior: Your ability to be gracious with others in all circumstances.
• Communication: Your ability to effectively interact with others.
• Negotiation: Your ability to get things done.
• 
Leadership: Your ability to influence what and how things get done.

• Politics: Your ability to interact in a political marketplace. 


Personal Skills

• Transparency: Your ability to operate and interact with other people, and to have all of the cards on the table, face up.
• Passion: Your ability to fully engage in what you are doing.
• Context Switching: Your ability to quickly and effectively refocus your attention at a moment’s notice to a new context. 

Business Skills

• Business Knowledge: Your ability to truly understand the language of business and the drivers that come into play when making tough decisions to enable the business to grow.
• Innovation: Your ability to bring new and innovative ideas forward that aren’t just technically “cool,” but rather facilitate revenue growth and sustained viability.
• Pragmatism: Your ability to make decisions that are the best ones for the company as a whole, rather than simply promoting the latest and greatest technology as a requirement for the next project.
• Vision: Your ability to see where the business is going, to help formulate where the business could go, and to help the business safely navigate the treacherous waters of technology projects.

CHANGE is coming ...ugh!

Well today I was discussing with a college how some people are resilient to the big C.

And I am speaking about CHANGE.

I feel very identified with those people because, I am very afraid to it. I am more a going with the routine person. I do not like change. But you know what?, I've tried by any means to avoid it and it still happens.

In the workplace, specially in the technology field (I am sure this is something you know by now), you can't afford not to go with the change or stay long enough with a technology that is going to be obsolete in the next three seconds. This last part is an exaggeration, of course.

But what do you do to cope with the times? Here is what I have tried...

Well some people try to keep informed on the latest. Not to be tortured by the speed that everything is happening, but to watch and know what is going on.

Based on that information, you see what is being demanded at the workplace and try to differentiate a long term used skill from a fad.

Then you should measure your preparedness to make the leap. What are your strong skills matching what could be a new arena for you and what are the challenges.

About those challenges, review what you need to do to overcome them, say that you need to learn a new programming language, where you could take classes, how much they cost, can you learn it without a formal class, etc.

And last but not least: Make a plan and take it from the blue print to reality.

I am not saying is going to be a walk in the park, but it is worth it.

Trying this, not only gave me something more to create new opportunities in my resume but did miracles for my self esteem.

I hope this gives you something to think about...

Everything You Wanted to Know About Consulting but Were Afraid to Ask - The Institute

Everything You Wanted to Know About Consulting but Were Afraid to Ask - The Institute

Great article about some important things a consultant should know to thrive in this environment. In here the panelists talk about the procedure of marketing, the management of earnings, the trial and error of rates and the long haul that a consultant should follow. About this long haul in consulting Larry G. Nelson say the following,

"One of the worst things I see is when someone loses their job, they say they’re a consultant rather than saying they’re unemployed."

For some people this become there modus operandi and everything they do is for the goal of getting a full time job. This is one of the most important not to do things of how to be a good consultant but not everyone has the knowledge of it and fall into this.

What we are against

In a blog posted at Harvard Business Review blog titled What is Your Brand Against? Scott Goodson explains that companies normally focus on defining their brands based on what they stand for. Although it is a suitable approach, he notes that branding following this strategy “starts to sounds like generic ad-speak”, as though trying to sell an ideology which everybody agrees on rather than making a stand against something and fighting for what the company believes in.

Goodson goes on to explain that marketers should not be reluctant to take a stand against anything fearing that it will place the company at a controversial or divisive position, since many companies have achieve success by doing so; such as Apple and Diesel. Identifying these concerns or issues, and branding your company against them, will ally your company with everyone else who faces them as well. This will create a bind that could turn prospects to customers, and increase loyalty within your existing ones.

Goodson warns not to be blinded by hatred toward your competition: “You may hate your competitor's guts, but nobody else cares; the outside world is looking for you to take on something more meaningful and interesting.” Also, don’t create an issue, whatever your company is against, it should be real; it should be an issue that truly affects your potential customers and that your company is really committed to eliminate. I may also add that it should not be something subtle or insignificant, it should be major and worth fighting for.

After reading the blog, I took a few minutes and analyzed what Goodson was communicating, and applied it to our company, how we are branding our services based on what we believe in, we strive for, and what we want to achieve, and tried to determine our issue, monster if you will, that we want to slay. It quickly dawned on me.

First let’s take a look at what our slogan is; “A straightforward path to success”. Straightforward is a very powerful word, and we picked it because it truly defines how our services must be provided: direct, honest, uncomplicated, simple, without ambiguity or pretence. We’ve noticed that the secret to a successful technology solution, besides the obvious finishing on time and in budget, the true success lies within the ease of adoption; how easily the solution is ingrained within the operations of the end-user. The more the solution simplifies the work of the end-user and the easier it is for them to adopt, the lesser the operation is impacted, and the quicker the company will see their return on investment. When I mention end-user, I’m not only referring to users of the solution, but also I’m referencing the personnel who will administer the system, who will carry out operational tasks such as monitoring, backups, debugging, updates, and so forth.

To achieve ease of adoption, every step of the solution providing process, from design to the implementation, must be reduced of unnecessary complexities, focusing solely on what needs to be solved and designing it toward a successful implementation. Solution are sometimes conceived in a simple manner, but along the way they are influenced by unnecessary factors that results in injecting complexities in executing the solution eroding budget and time, or affecting overall implementation and purpose. Thus, when delivering services, unnecessary complexity is the “monster” that we slay.

What are we against? Unnecessary complexities. Some of the unnecessary complexities are:

• Unnecessary features – Trying to provide vast amount of features (that add little to no value to the solution) to impress the customer at a design phase. These features seldom add a meaningful value, they only add complexity at the delivery process and challenge the budget and time constraint. Not to mention, that at implementation time, these may add complexity to the end user, reducing the adoption rate.
• Trying to solve all problems – More often that not, a solution is needed for a specific reason, and a defined budget and time constraint are already expected to address it. Let’s keep it like that; we don’t need to solve everything at once.
• Choosing the wrong tool – Like in most professions, the right tool makes all the difference. So let’s avoid complexity by using the incorrect one, for whatever reason. Choosing the right tool may be the difference of the general success of the project due to the capability to achieve what it’s expected, the customizability to the company’s special need, the personnel expertise accessibility, and much more.
• Reinventing the wheel – We are at the information age, most of what we do, others have already done it and shared it. In some cases, good practices have been identified and standards have been developed. If we can benefit from this, then why add unnecessary complexity by “reinventing the wheel”. We evaluate industries, examine technologies, study trends and good practices, ally with industry leaders, and test and educate our personnel so that we can be ready to tackle a broad range of technology services for businesses.

An added benefit to reducing unnecessary complexities is risk reduction. Risk is a time bomb that can destroy a solution at any stage, or can be the reason for exceeding budget or delivery timeframe. Risk can present itself anywhere; inadequate products (software or hardware), unprepared personnel, feasibility of features versus cost and time constraints, and plenty more. There will always be risks associated to providing solutions, but by reducing unnecessary complexities we significantly reduces overall risks.

Please feel free to share you comments, and tell us of any other unnecessary complexity that you may have encountered or identified.