[jboss-dev] JBoss Bootstrap, Embedded & Reloaded

Tue Apr 7 12:37:32 EDT 2009

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.
That's the job of the data source deployer from JCA.
> 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.
>
> 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);

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.

Carlo

>
>
> On Apr 7, 2009, at 16:02, Carlo de Wolf wrote:
>
>> What you are creating there is a virtual deployment unit. Right now 
>> you would need to instantiate an XADataSourceDeploymentMetaData and 
>> throw that at the VDF somehow.
>>
>> And yes, the setters returning this with short named methods allows 
>> for much better looking code.
>>
>> Both of these things are beyond the scope of Embedded, Reloaded, 
>> Launcher or Bootstrap.
>> Creating virtual deployment units is part of VDF itself.
>> Working metadata is part of jboss-metadata or the individual deployer 
>> component.
>>
>> Carlo
>>
>> Emmanuel Bernard wrote:
>>> Actually I was more thinking along something like that
>>>
>>> public class TestConfig extends OnDemand {
>>> @Overrides
>>> public void configure(Config conf) {
>>> conf.datasource("DefaultDS")
>>> .connectionUrl("jdbc:hsqldb:mem")
>>> .driver(org.hsqldb.jdbcDriver.class)
>>> .user("sa")
>>> .minPoolSize(2)
>>> .queue("hibernatesearch")
>>> .persistent("DefaultDS");
>>> }
>>>
>>>
>>> @Test
>>> @JBossEmbedded(config=TestConfig.class)
>>> public void testMyApp() {
>>> JBossEmbeddable container = JBossEmbeddable.start(); //read config 
>>> from the caller annotation
>>> ...
>>> ...
>>> container.stop();
>>> }
>>>
>>> Putting XML files for tests is annoying, messy, hard, confusing and 
>>> reduce isolation / flexibility between tests.
>>>
>>>
>>> On Apr 7, 2009, at 12:16, Carlo de Wolf wrote:
>>>
>>>> A datasource you would define somewhere in src/test/resources. 
>>>> Maybe src/test/resources/deploy/test-ds.xml.
>>>>
>>>> Then in @AfterClass you boot up the server (as per Andrew's code)
>>>> With maybe: @Profile("JCA") on the unit test class itself.
>>>> (More likely the fact that a dependency on jboss-jca-profile is 
>>>> defined in pom.xml will bring it up by itself.)
>>>>
>>>> Carlo
>>>>
>>>> Andrew Lee Rubinger wrote:
>>>>> Sounds a bit like the prototype:
>>>>>
>>>>> http://anonsvn.jboss.org/repos/jbossas/projects/embedded/trunk/testsuite/src/test/java/org/jboss/embedded/test/server/ServerUnitTestCase.java 
>>>>>
>>>>>
>>>>> ...which just proves the usage, and the API is to be discussed / 
>>>>> in-progress this week. Likely I'll post some note here and let 
>>>>> input flow into the Design of Embedded Forum.
>>>>>
>>>>> S,
>>>>> ALR
>>>>>
>>>>> Emmanuel Bernard wrote:
>>>>>> I don't have a problem with staged work but from hat I have seen 
>>>>>> we add even more XML where there were plenty of it already.
>>>>>>
>>>>>> I really really really would like to get to a /default/ no XML / 
>>>>>> no config mode where things are scanned in my unit test CP and 
>>>>>> deployed. If config is needed (maybe datasource), a trivially 
>>>>>> simple programmatic API could be used. We could almost do 
>>>>>> something like
>>>>>>
>>>>>> @Test
>>>>>> @JBossEmbedded(config=TestConfig.class)
>>>>>> public void testMyApp() {
>>>>>> JBossEmbeddable container = JBossEmbeddable.start(); //read 
>>>>>> config from the caller annotation
>>>>>> ...
>>>>>> ...
>>>>>> container.stop();
>>>>>> }
>>>>>>
>>>>>> But again, I wish there was a central point for all these 
>>>>>> discussions.
>>>>>>
>>>>>> On Apr 7, 2009, at 11:29, Andrew Lee Rubinger wrote:
>>>>>>
>>>>>>> Emmanuel Bernard wrote:
>>>>>>>> But nowhere is there a discussion on what Embedded should do 
>>>>>>>> and should look like from a user point of view.
>>>>>>>
>>>>>>> Because Embedded as previously defined has since been split into 
>>>>>>> a series of independent features (as mentioned in posts to this 
>>>>>>> Thread). The pure in-JVM nature was easily enough provided by:
>>>>>>>
>>>>>>> * Splitting jboss-bootstrap out of AS
>>>>>>> * Making some standalone usage for it
>>>>>>>
>>>>>>> This does not yet address Bill's hitlist:
>>>>>>>
>>>>>>> * Embedded Distribution as a unified JAR
>>>>>>> * Configuration Overrides
>>>>>>> * Minimal Profiles to start or on-demand
>>>>>>>
>>>>>>> But we need a good starting point to enable in-JVM testing for 
>>>>>>> AS5, and a solid base upon which to build the next few features. 
>>>>>>> IMO biting too much off at once very quickly puts us at a dead end.
>>>>>>>
>>>>>>> Regarding jboss-bootstrap:
>>>>>>>
>>>>>>> As I'd mentioned, the user API leaves room for improvement, and 
>>>>>>> there are a series of ClassLoading assumptions that we're 
>>>>>>> addressing:
>>>>>>>
>>>>>>> http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4223913#4223913 
>>>>>>>
>>>>>>>
>>>>>>> So Bootstrap continues to be the foundation, and as Carlo 
>>>>>>> mentioned, a new "Launcher" component becomes the user view for 
>>>>>>> Embedded, Reloaded, and AS. From here we may support POJO Server 
>>>>>>> start/stop/deploy/etc.
>>>>>>>
>>>>>>> With some working prototypes committed over the next couple days 
>>>>>>> there will be some more to discuss from my end.
>>>>>>>
>>>>>>> S,
>>>>>>> ALR
>>>>>>>
>>>>>>> -- 
>>>>>>> Andrew Lee Rubinger
>>>>>>> Sr. Software Engineer
>>>>>>> JBoss, a division of Red Hat, Inc.
>>>>>>> http://exitcondition.alrubinger.com
>>>>>>> _______________________________________________
>>>>>>> jboss-development mailing list
>>>>>>> jboss-development at lists.jboss.org
>>>>>>> https://lists.jboss.org/mailman/listinfo/jboss-development
>>>>>>
>>>>>> _______________________________________________
>>>>>> jboss-development mailing list
>>>>>> jboss-development at lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/jboss-development
>>>>>
>>>>
>>>> _______________________________________________
>>>> jboss-development mailing list
>>>> jboss-development at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/jboss-development
>>>
>>> _______________________________________________
>>> jboss-development mailing list
>>> jboss-development at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/jboss-development
>>
>> _______________________________________________
>> jboss-development mailing list
>> jboss-development at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jboss-development
>
> _______________________________________________
> jboss-development mailing list
> jboss-development at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-development