[jboss-dev] JBoss Bootstrap, Embedded & Reloaded

[Emmanuel Bernard]

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).

>
>> We cannot design this project in micro silos not thinking about the  
>> actual use case(s). We should always keep them in mind. Now, you  
>> can tell me it's planned for v 1.1 if it happens that it's not the  
>> #1, #2 or #3 actual use case we are trying to achieve.
> This is not about micro silos, this is about modularization. All of  
> our products delegate the deployment of a data source to another  
> module. But yes I agree for the Embedded product this should be a  
> functional requirement.

#1 helping users
#2 helping your life

Modularization is more about #2 if it goes against a unified and  
simple product (from the outside, chunk it in 200 maven subprojects if  
it pleases you).

>
>>
>> But my understanding is that easy unit testing is pretty much #1.  
>> Easy config has to be in-scope somehow.
> Easy config is subjective. :-)
> Stick to the original definition:
> conf.datasource("DefaultDS")
> .connectionUrl("jdbc:hsqldb:mem")
> .driver(org.hsqldb.jdbcDriver.class)
> .user("sa")
> .minPoolSize(2)
> .queue("hibernatesearch")
> .persistent("DefaultDS");
> // TODO: don't like this bit yet
> unit.addAttachment(conf);
> deploy(unit);

right, I've not found a nice way to attach the config yet. I like the  
idea of a class hosting the config and reusable across several  
deployments. Kinda like a DD.

>
>
> So to rephrase:
> A functional requirement of Embedded is that we want to be able to  
> easily configure a data source as per given pseudo code. (Other  
> deployable elements to follow.)
> This would require changes in jboss-deployers and jboss-metadata. No  
> change is needed in jboss-embedded, jboss-reloaded and/or jboss- 
> bootstrap.
>
> The above will not be targeted for EAP 5. Although we could create a  
> prototype in the interim.
> Hmm, actually we could create a component on top of jboss-metadata  
> that can bridge your needs.

Why is it not targeted for EAP 5? What's more important (embedded  
wise)? (Plain question, I dont' know).