Re: [jboss-dev] JBoss Bootstrap, Embedded & Reloaded
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).
> 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).