[jboss-dev] JBoss Bootstrap, Embedded & Reloaded

Tue Apr 7 10:56:28 EDT 2009

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.

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.

But my understanding is that easy unit testing is pretty much #1. Easy  
config has to be in-scope somehow.

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