ProjectStage and CDI @Exclude

[Mark Struberg]

Hi!

I'd like to throw in another pair of useful Apache DeltaSpike features which are heavily related to configuration.

First of all, for me the main focus of 'configuration' is to have exactly one and the same binary and be able to set it into production on various different servers and environments WITHOUT having to re-package it. 

If the ReleaseManager creates a WAR file then this exact WAR must get installed on the test system, later moved to the staging environment and then on the boxes of various customers. And no one must ever open the WAR and tweak something inside of it. Otherwise most of the testing effort is nuts...

So here comes the ProjectStage. Taken from Rails to JSF, and further enhanced in Apache MyFaces CODI (originally) and later copied over to Apache DeltaSpike as well.

http://deltaspike.apache.org/projectstage.html

Now what has this to do with CDI and @Exclude?

The point is that we use the ProjectStage AND/OR values configured via ConfigSource for switching between implementations using @Exclude. 

http://deltaspike.apache.org/core.html#exclude

A small example.

Consider an interface MailService with public void sendMail(String from, String to, String subject, String body);

And we also have a default implementation which uses SMTP on a real server (the server IP could btw be configured via @ConfigParam...)

@ApplicationScoped

public class MailServiceImpl implements MailService {...}

But for our unit tests and local development we do not like to stress our production server. Thus we simply write an alternative impl which only logs the mail to send:

@ApplicationScoped

@Alternative

@Exclude(exceptIfProjectStage={ProjectStage.UnitTest.class, ProjectStage.Development.class})

public class MockMailService implements MailService {..}

Of course we also could have a 3rd MailService which does SSL in a very similar way. 

Another example:

We use the property 'dbvendor' to tell our app which database vendor it should use. 

We have a SomeDomainSearchService which does plain JPA. 

But we also have a 'tuned' version for Oracle which uses NativeQueries:

@ApplicationScoped

@Specializes

@Exclude(onExpression="dbvendor!=oracle")

OracleSomeDomainSearchService extends SomeDomainSearchService {..

I hope you get the idea and the power it unlocks...

LieGrue,

strub

[Antonio Goncalves]

Hi Mark,

And what about resource definitions ? From Java EE we can now define a Datasource, a JMSFactory/Destination, MailSession with code. It would be nice if we could have staging for this kind of defintion :

@DataSourceDefinition(name="java:global/MyApp/MyTestDataSource",

      className="com.example.MyDataSource",

      portNumber=6666,

      serverName="example.com",

   )

@Stage(UnitTest)

public class MyTestDS

@DataSourceDefinition(name="java:global/MyApp/MyRealDataSource",

      className="com.example.MyDataSource",

      portNumber=7777,

      serverName="example.com",

      user="lance",

      password="secret"   )

@Exclude(excludeIfProjectStage=UnitTest))

public class MyRealDS

--
You received this message because you are subscribed to the Google Groups "java-config" group.
To unsubscribe from this group and stop receiving emails from it, send an email to java-config...@googlegroups.com.
Visit this group at http://groups.google.com/group/java-config.
To view this discussion on the web visit https://groups.google.com/d/msgid/java-config/850b339d-5665-48cc-883c-ea757faa1598%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Antonio Goncalves
Software architect, Java Champion and Pluralsight author

Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx France

[Mark Struberg]

Just my personal opinion maybe, but I find @DataSourceDefinition completely useless.

Honestly, would YOU write any credentials into your code?

A DataSource is typically something which is configured on the server. And when running unit tests it gets passed in as properties into the embedded container. This also allows running your unit tests against different databases (e.g. based on a maven profile). Works like a charm.

Of course we could think about making the maintenance of encrypted/secret config easier.

LieGrue,

strub