Emmanuel Bernard wrote:
> 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.
JBossEJBContainer.cast(container). ...
EJBContainerWrapper is an ugly thing from a proposed spec requirement,
it's going away before final.
deploy()
what's the reason for
deploy( DeploymentBuilder.deployment(
NonXADataSourceDeploymentMetaData.class,
DataSourceBuilder.localDatasource()
.driverClass(String)
.getMedatata() ) )
Right now on(container) returns a domain object, which
doesn't have any
DSL facilities. So I must pass in a deployment.
We could probably do a DSL one for JBossEJBContainer.
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).
Although theoretically possible, in practice not
maintainable.
Already you're expanding the scope beyond EJB 3 Embedded (with war),
basically you've defined an virtually unlimited scope.
Secondly, what happens if you mix different versions of technologies.
(This is going to happen in preview release of this embedded, because it
uses JPA 1.0.)
So when you're using functionally scoped DSL classes then after
datasource(), you're in JCA land and can't switch back to application.
The same goes a bit for persistence(unit(...)) / persistence().unit(...)
albeit these PersistenceBuilder & PersistenceUnitBuilder can probably be
combined.
driverClass(), could it take Class<? extends ...> instead of a string?
If it
wasn't a hack it could have been Class<? extends Driver>. :-)
Right now the simplistic deployer expects it to a MC capable class.
I'm more inclined to switch to DataSourceDefinition in which case it'll
become class(Class<? extends DataSource>) and className(String).
Emmanuel
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development Carlo