I will be presenting on September 22nd for the PMI Central Va Chapter during their Fall 2012 PMI Certification Workshop. My topic will be the Project Management Framework. My talk goes from 10:15 AM to 11:45 AM and touches on items found in sections 1 & 2, chapters 1, 2, & 3, of the PMBOK, version 4.

In my session I will be discussing these topics and more:

Projects, Portfolios, and Program

Process Groups, Knowledge Areas, and Processes

PMO

Project Life Cycle vs. Product Life Cycle

Stakeholder Management

Organizational Structure

Ever wondered how PMI keeps the PMP exam current and relevant? This year we have also added information of the PMI Role Delineation Study and the Crosswalk.

This workshop is a great way to come up to speed for the PMP exam as well as gain valuable study tips from fellow project managers that have already passed the exam. The workshop is also a great opportunity to gain the PDUs needed to maintain existing PMP certifications. Best of all, attendees receive copies of all the slides presented at the workshop as well as other resources to help them study for the exam.Integration ModuleI will also be supporting the Integration Module session that starts at 11:45 and continues after lunch to 14:00.

Thursday, September 6, 2012

In Part1 I explained two solutions for dynamically loading beans based on environments. In this Part 2, I (quickly) extend the solution to handle conditional Bean Definition File imports. Below is my new main.xml with a new custom tag, <profile:importIf>. This new tag, along with the <profile:if> tag, will allow me to control individual bean and entire bean definition file loads via properties files.

This new solution will load individual beans based on conditions defined in Bean Definition Files, and will now import entire Bean Definition Files based on those same declared conditions. Of course the same caveats apply. Developers must manage bean ID and NAME collisions when using multiple conditions and imports.

In Spring 3.1 (2011), profiles were introduced. These Bean Definition Profiles allow Spring developers to set up different profiles for loading different beans in different environments. I know several developers that are moving to 3.1 just for that feature.

However, what does one do if one needs to load different beans for different environments, but he/she cannot immediately upgrade to Spring 3.1? In this blog entry I will cover that scenario with two solutions from long ago that still work today in Spring 3.0.x.

Solution #1:

Far and away the easiest solution is to use config file properties, the Spring PropertyPlaceholderConfigurer, and Spring Expression Language (SpEL). Below is an XML snippet from a bean definition file. The code uses SpEL to get at the Spring.ENV property found in the config.properties, and referenced as the Spring container starts to load.

As long as the property is located before the Spring Container starts to load bean definitions, this will work to load files whose names match the resource arguments. This solution has issues, not the least of which are that properties must be used and they must be coordinated to match file names related to bean definition files.

System properties can also be used in lieu of the PropertyPlaceholderConfigurer.

Solution #2:

This next solution is way more involved, requiring custom extensions to the Spring Container API, but is configuration properties file driven instead of system property driven. To understand this approach, we start with what we would like to see in the bean definition file. Below is the <profile:if> custom tag that will test whether certain beans are to be loaded.

In this example, the <profile:if> tag tests to see if the Spring.ENV property has the required value of "DEV" to load this bean. The Spring.ENV property should be found in the config.properties resource bundle that is declared in the src attribute of the <profile:if> tag. If the test passes (Spring.ENV == 'DEV') then the devBean will be loaded.

The plumbing for this solution extends the Spring Container API via the Extensible XML Authoring API with Java and XML Schema (XSD), along with two additional Spring configuration files. It is rather complex, but I will try to simplify it here.

The Extensible XML Authoring API (EXAA for short) has been around since Spring 2.0. However, it never really got the visibility that other Spring features enjoyed. With EXAA, there are four steps to extending the API:

Authoring XML schemas

Coding Namespace handlers

Coding BeanDefinitionParser extensions

Registering the XSD and code artifacts with the Spring Container

I will start will authoring the schema. Below is the XSD that defines the new custom tags we want to use. As a point of reference, I built this solution in Eclipse Helios SR2 using Maven. I placed the new profile.xsd into directory in the image below.

The contents of the schema are seen below. In this XSD I defined the target namespace (http://icfi.com/springbeans/profile) and the custom tag (if) with required attributes, test and src.

Below is the location in my Maven layout for both registration properties files mentioned so far.

The ProfileBeanDefinitionParser is referenced in the handler. This parser does all the heavy lifting of parsing the custom tag, verifying the attributes, loading the defined resource bundle (properties file), testing the condition for bean load, parsing the bean definition, and then registering the bean with Spring. Below is the custom Bean Definition Parser that I wrote.

The config.properties file contains the Spring.ENV property that will be used to test the condition defined in the tag, test attribute. This file is found at the root of the src/main/resources Maven layout.Below is a test class, SpringInitMotivator, that I used to exercise this solution, Also seen below is the main.xml used to configure Spring in my application. The SpringInitMotivator uses a helper class, SpringBeanFactory, to get at beans. For this demo, I use the IBeans interface, implemented by the DevBean and ProdBean classes. I load the beans via the name attribute and not the id, as multiple beans can not have the same ID, and I wanted to use a common name for both bean load conditions.