Okay, here we go:
http://anonsvn.jboss.org/repos/jbossas/projects/ejb3/trunk/embedded/src/t...
For inspiration I used:
http://martinfowler.com/dslwip/
A couple of guidelines I'm forming:
- for each domain object we want a builder
- static methods of a builder should return the domain object
- other methods of a builder should return this
Step by step:
on(container) // does a cast to JBossEJBContainer so we can get to
the extended API.
.deploy( // deploy
deployment( // a deployment
url, // which is based at url
persistence( // and has a persistence attachment
unit("tempdb") // consisting of persistence unit tempdb
.jtaDataSource("java:/Default")
.property("hibernate.hbm2ddl.auto", "create-drop")
)
)
);
The extra deployment() might seem trivial, but there is a decoupling
between the main deployer and the deployment types, so right now I'm
using a VFSDeploymentBuilder.
(
http://anonsvn.jboss.org/repos/jbossas/projects/ejb3/trunk/embedded/src/m...
)
Persistence units can be added in two different ways:
1. nested function as shown about
2. method chaining:
persistence().unit("tempdb1").unit("tempdb2")
The same goes for the properties on an unit.
So the question is: who should own the builders for JPA?
http://anonsvn.jboss.org/repos/jbossas/projects/ejb3/trunk/embedded/src/t...
http://anonsvn.jboss.org/repos/jbossas/projects/ejb3/trunk/embedded/src/t...
Carlo
--
note to self: requirement 'd' already proves that there can't be a
grand API project for this.
Sweet.
I am a bit puzzled at the use of static imports (in general in Java).
I've found that it makes things a bit harder in the sense that one has
to know which class or element to statically import to use it. So when
combined with a fluent API design, it literally destroys the flow of
the API at least at write time. When using the fluent API + contextual
objects in lieu of parameters when subsequent informations are
provider, the IDE helps a great deal by proposing the solutions (see
below).
on()
I think the EJB 3.1 spec would benefit from a
EJB3Container.unwrap(JBossEJB3Container.class).deploy(...);
on() is nice but again, you need to know it exists.
deploy()
what's the reason for
deploy
( DeploymentBuilder.deployment( NonXADataSourceDeploymentMetaData.class,
DataSourceBuilder.localDatasource()
.driverClass(String)
.getMedatata() ) )
vs
deploy()
.datasource("name")
.local()
.driver(HSQLDBService.class)
.application()
.persistence("pu-customer")
.package( pkg("org.jboss.ejb3.embedded.test.jpa") )
.jtaDatasource("name")
.property("hibernate.hbm2ddl.auto", "create-drop");
I understand the need for a generic deployment thingy for things not
provided OOTB by the configuration API but by providing built-in
support for key deployments (datasource, jms queue, war etc), we make
things easier it seems. I wish we could provide a natural way to
extend the configuration providing both OOTB style API and
extensibility. I haven't found a solution yet but generics might help
here (the main problem is extending for multiple usecases - extending
for one usecase is easy).
driverClass(), could it take Class<? extends ...> instead of a string?
Emmanuel