I'm sorry but I think that for devs it would be good (think about
@DatasourceDefinition / CDI alternatives...)
But for "production" it will never be used
administrators do not compile java code
IT security policies will never allow to let passwords and other
top-secret info to be hard coded in java files
- Enrico
Il 24/08/2012 20:28, exabrial ha scritto:
OK guys...
This is what I want. https://pastee.org/7tj7r
It's extensible.
It's readable.
It's typesafe.
It's testable.
It has exactly "one way" of doing things.
It could integrate with CDI qualifiers.
It's awesome.
@TomEEModuleConfiguration("my-application-name")
public class ConfigModule {
@Inject
private ServerContext context;
@ConfigurationId(env = "Development")
public void getDevConfig(ModuleConfig config) {
DataSourceConfig dataSourceConfig =
createResource(MySqlDataSource.class).setUserName("bob").setPassword("thebuilder").setHostName("localhost")
.setPort(3306);
DataSource newDataSource =
config.addServerResource(dataSourceConfig);
config.addConfig(bind(Resource.class).withName("jdbc/myAppDataSource").annotatingType(DataSource.class)
.to(newDataSource));
}
@ConfigurationId(env = "Production")
public void getProdConfig(ModuleConfig config) {
config.addConfig(bind(Resource.class).withName("jdbc/anotherDataSource").annotatingType(DataSource.class)
.to(context.lookup(DataSource.class,
"jdbc/anotherDataSource")));
}
}
--
View this message in context:
http://openejb.979440.n4.nabble.com/DISCUSS-New-descriptor-format-tp4657040p4657087.html
Sent from the OpenEJB Dev mailing list archive at Nabble.com.
