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/m...
>
>
> 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
--
Jason T. Greene
JBoss, a division of Red Hat