WebLogic Optional Packages and Dependency Maturity

So I mentioned in another post about a Dependency Maturity Model where I will pull the environmental properties from our WAR deployments. The way I accomplish this with WebLogic is by making the jar file that holds the environmental property like an OSGi bundle for WebLogic (which is an optional package). This is not a very complex exercise, it is really about giving a JAR information with it’s MANIFEST.MF to identify it’s versions and a JAR key, then referencing that within deployments that use the JAR (like a WAR).

I configure the maven-jar-plugin to put additional information to the MANIFEST.MF

1
2
3
4
5
6
7
8
9
10
11
12
13
14
<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-jar-plugin</artifactId>
    <configuration>
        <archive>
            <manifestEntries>
                <Manifest-Version>1.0</Manifest-Version>
                <Extension-Name>envProperties</Extension-Name>
                <Specification-Version>${env.spec.version}</Specification-Version>
                <Implementation-Version>${env.impl.version}</Implementation-Version>
            </manifestEntries>
        </archive>
    </configuration>
</plugin>

Once this JAR is built through our Maven project, I need to deploy it out to WebLogic utilizing the maven-weblogic-plugin (for WLS 11). There are two interesting pieces of information regarding the link to the WebLogic Server 11 and WebLogic Server 12 versions of the plugin. The WebLogic Server 12 version appears to have a bug and does not support deploying libraries at all and therefore I have to utilize the WebLogic Server 11 version of the maven plugin. The second issue though is that the WebLogic Server 11 version of the plugin does not support the library capability through XML, it has to be supplied as a command line argument.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
<plugin>
    <groupId>com.oracle.weblogic</groupId>
    <artifactId>weblogic-maven-plugin</artifactId>
    <executions>
        <execution>
            <id>deploy</id>
            <phase>compile</phase>
            <goals>
                <goal>deploy</goal>
            </goals>
            <configuration>
                <adminurl>t3://${target.hostname}:${target.port}</adminurl>
                <user>${target.userId}</user>
                <password>${target.password}</password>
                <upload>true</upload>
                <action>deploy</action>
                <targets>${target.cluster}</targets>
                <remote>true</remote>
                <verbose>true</verbose>
                <library>true</library>
                <source>${project.build.directory}/lib/${property.name}.jar</source>
                <name>envProperties</name>
            </configuration>
        </execution>
    </executions>
</plugin>

So the main piece of configuration here that differentiates this from a normal WAR or EAR deployment is the true. This XML element is supposed to identify this deployment as an Optional Package, but this field does not work. In order to bypass this error, when I run the maven goal to fire off this plugin, I have to pass in a -Dlibrary=true for this resource to successfully deploy as an Optional Package (otherwise WebLogic will generate an error that this is an invalid resource type).

The next step is to make modifications to our WAR so that it can become aware of the Optional Package. I do this by modifying a maven plugin so that it can build references in the WAR’s MANIFEST.MF to the JAR’s MANIFEST.MF.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-war-plugin</artifactId>
    <configuration>
        <archive>
            <manifestEntries>
                <Manifest-Version>1.0</Manifest-Version>
                                           
                <Extension-List>envProperties cxfFull</Extension-List>
                <envProperties-Extension-Name>envProperties</envProperties-Extension-Name>
                <envProperties-Specification-Version>${env.spec.version}</envProperties-Specification-Version>
                <envProperties-Implementation-Version>${env.spec.version}</envProperties-Implementation-Version>
                                           
                <cxfFull-Extension-Name>cxfFull</cxfFull-Extension-Name>
                <cxfFull-Implementation-Version>${cxfFull.spec.version}</cxfFull-Implementation-Version>
                <cxfFull-Specification-Version>${cxfFull.spec.version}</cxfFull-Specification-Version>
            </manifestEntries>
        </archive>
        <packagingExcludes>WEB-INF/lib/cxf*.jar</packagingExcludes>
    </configuration>
</plugin>

There are some additional interesting items that I have in this configuration that I can go over, but let’s first talk about how I reference the environment property JAR.

1
2
3
4
<Extension-List>envProperties cxfFull</Extension-List>
<envProperties-Extension-Name>envProperties</envProperties-Extension-Name>
<envProperties-Specification-Version>${env.spec.version}</envProperties-Specification-Version>
<envProperties-Implementation-Version>${env.spec.version}</envProperties-Implementation-Version>

In the Extension-List tag, I list all the *-Extension-Name configurations that I have. So in the previous section of the configuration, I have an envProperties-Extension-Name=envProperties and a cxfFull-Extension-Name=cxfFull. I therefore need to list these values in the Extension-List element. The next step is to reference the Implementation/Specification Versions and I do this by using the *-Extension-Name value as the key in the name of the configuration. So if our key is envProperties, our *-Extension-Name becomes envProperties-Extension-Name, our *-Specification-Version becomes envProperties-Specification-Version, and our *-Implementation-Version becomes envProperties-Implementation-Version.

The other important piece of configuration here is the . I utilize this feature to remove jars (that I have designated as Optional Packages) so that they will not be included into the built war file. The reason for this again is that these jars will be available via Optional Packages and therefore I remove them from the war and therefore reduce the size of the war and increase performance for startup/deployment.

Now that I have been able to create the reference between the two, once the WAR is deployed, it will create a link between it and the environment properties JAR. In fact, if I log into our WebLogic console and click on our environment properties deployment and I can see all the other deployments that are using it. These relationships will be listed under the “Applications that reference this Library” table.

Because of this relationship, anytime I need to redeploy the environmental properties jar or any Optional Package, I will need to start/stop the web applications that use the specific Optional Package. This allows that web application to reload the new changes to the Optional Package (unfortunately it does not appear to be dynamic), but it also does not require us to restart the Admin/Managed Server instances.

For more additional information about the weblogic-maven-plugin, see my other post as to how I deploy wars using this plugin.

Share and Enjoy