[jboss-dev] JBoss Bootstrap, Embedded & Reloaded

[Carlo de Wolf]

Jason T. Greene wrote:
> Emmanuel Bernard wrote:
>>
>> On  Apr 7, 2009, at 18:37, Carlo de Wolf wrote:
>>
>>> Emmanuel Bernard wrote:
>>>> Carlo, it's really hard to take that seriously.
>>>>
>>>> How can that be beyond the scope. People have to define 
>>>> configuration one way or an other right? to actually use Embedded.
>>>> Has anyone any idea of the overall goal we want to achieve to 
>>>> provide actual solutions for actual problems? I believe we do and 
>>>> bill summed it up.
>>> Here is the prototypical interface with which to configure Embedded:
>>> http://anonsvn.jboss.org/repos/jbossas/projects/embedded/trunk/core/src/main/java/org/jboss/embedded/spi/JBossServerConfig.java 
>>>
>>>
>>> As you can see it has a setter return this pattern (what's the name 
>>> for it again?). But it doesn't allow for configuration of data sources.
>>
>> Method chaining :) It is used in the builder pattern for example (I 
>> find method names wo the set* better as a setter returning this is 
>> not a JavaBean setter)
>>
>>>
>>> That's the job of the data source deployer from JCA.
>>
>> Yes but let me play the actual JBoss user (that I am) for a minute,
>> "The deploywhat from what stupid TLA? I want to configure a freaking 
>> DS for god's sake. That's the #1 thing I need to do to set up this 
>> container!"
>>
>> If we need a uberproject EazyConf that covers 80% of conf use cases, 
>> fine. But we need a unified/easy to use configuration API. (Not only 
>> for Embedded eventually but I think embedded will shine with it).
>
> +384759834759834759384758457487543987539487539845793847598347538475893475! 
>
>
> This API should:
>
> a) Take 10 minutes or less to understand
>    - Intelligent names for things (no 
> BridgedAbstractAdapterClassLoaderModulePluginMDRRetrieverEJB3Loader)
>    - Require as few parameters as possible
>    - Look a *normal* Java API
>    - Not redundant
> b) Be self-contained and fully expressible in one javadoc location
> c) Not take arbitrary untyped objects (Atttachments)
> d) Make using the AS look trivial
>
First:
Requirement 'a' is subjective and thus met.
'b' is invalid, but this is part of the discussion point.
'c' is met.
'd' is not applicable because AS doesn't enter the picture.

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.