CODEWITHSUNDEEP
javajakarta-eejbosscdi
Mr.Eddart
Mr.Eddart

Reputation: 10273

Enabling CDI Decorator based on environmental properties

I know that it is possible to configure Decorators in the "beans.xml" file that is embedded in the EAR to be deployed.

The problem is that I use the same EAR for all the environments, and the set of properties or specific configurations are stored in some folder outside the package.

I need to determine if a Decorator will be used or not "external beans.xml" or some similar mechanism (something that is outside the EAR).

Any ideas?

Thank you very much.

Upvotes: 0

Views: 130

Answers (2)

maress
maress

Reputation: 3533

Another scenario you can use, is to utilize build-time inclusion and processing. If you know before hand, what properties activate specific decorators at build-time, then you can use maven resources, together with system properties, to define additional resources to be filtered, thus:

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" 
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>

    <groupId>com.mycompant</groupId>
    <artifactId>my-project-id</artifactId>
    <version>1.0.0-SNAPSHOT</version>
    <packaging>war</packaging>

    <properties>
        <some.kind.of.selector.properties>$basedir}/src/main/resources/development</some.kind.of.selector.properties>
    </properties>

    <build>
        <resources>
            <resource>
                <directory>${some.kind.of.selector.properties}</directory>
            </resource>
            <resource>
                <directory>src/main/resources</directory>
            </resource>
        </resources>
    </build>

    <profiles>
        <profile>
            <id>test</id>
            <properties>
                <some.kind.of.selector.properties>$basedir}/src/main/resources/test</some.kind.of.selector.properties>
            </properties>
        </profile>
        <profile>
            <id>prod</id>
            <properties>
                <some.kind.of.selector.properties>$basedir}/src/main/resources/prod</some.kind.of.selector.properties>
            </properties>
        </profile>
    </profiles>
</project>

The at build time, you can specify different beans.xml for every environment:

mvn clean install -Pprod

or even specify the property directly

mvn clean install -Dsome.kind.of.selector.properties=/path/to/additional/resources

Upvotes: 1

Siliarus
Siliarus

Reputation: 6753

Normally, this won't work - standard means of enablement are beans.xml for per-archive approach and @Priority for global enablement. There is nothing like "external beans.xml".

Although there is a way to enable it with extension. You need to set up an extension and observe AfterTypeDiscovery event. From there you can make use of public List<Class<?>> getDecorators(); which returns MUTABLE list of decorators - so you can add your own into the list (in a form of a Class). That should enable it.

Upvotes: 1

Related Questions