[jboss-dev] JBoss Bootstrap, Embedded & Reloaded

[Carlo de Wolf]

Emmanuel Bernard wrote:
>> 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.
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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-development
Carlo