[jboss-dev] JBoss Bootstrap, Embedded & Reloaded

[Emmanuel Bernard]

> Okay, here we go: http://anonsvn.jboss.org/repos/jbossas/projects/ejb3/trunk/embedded/src/test/java/org/jboss/ejb3/embedded/test/jpa/unit/PhoneBookTestCase.java
>
> 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/main/java/org/jboss/ejb3/embedded/dsl/DeploymentBuilder.java 
>  )
>
> 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/test/java/org/jboss/ejb3/embedded/test/dsl/PersistenceBuilder.java
> http://anonsvn.jboss.org/repos/jbossas/projects/ejb3/trunk/embedded/src/test/java/org/jboss/ejb3/embedded/test/dsl/PersistenceUnitBuilder.java
>
> 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