Where to begin? This question is actually the one we are going to debate. Where does Application Server begin and where does it end? But there is more to it: I want to be able to unit test EJB3 before bringing it to AS. (I think it should become a requirement of any component to be able to run/test standalone before coming to AS/EAP, but that's another discussion.) Let's start with the simple one: JBoss Bootstrap: As of AS 5.1 the application server no longer performs the bootstrapping of profile service. Instead AS defines a bootstrap descriptor and delegates bootstrapping it to JBoss Bootstrap. Effectively this allows anybody to create an arbitrary bootstrap, for example: <?xml version="1.0" encoding="UTF-8"?> <bootstrap xmlns="urn:jboss:bootstrap:1.0"> <url>bootstrap/naming.xml</url> <url>bootstrap/jmx-jdk.xml</url> <url>bootstrap/jbossts.xml</url> </bootstrap> Voilà instant JTA compliant transaction server. The best part is, that it's using the same components as the real AS, so it should be close to 100% compatible. Now the most complex one in terms of definition: JBoss Embedded. It's *not* Embedded JBoss ( http://www.jboss.org/community/docs/DOC-9690 ), which was a preview of AS 5 capabilities (previously known as EJB 3.0 Embeddable). It is *not* EJB 3 Embedded, which is a preview of EJB 3.1 Embeddable specification. The scope of JBoss Embedded is currently defined as: * Software component which, in tandem with an arbitrary AS distribution, launches JBossAS in preexisting JVM. * Conforms to all existing AS TestSuites and TCK (fully-compatible) when in a JavaSE environment. Whether AS is launched from run.sh or Embedded should be transparent to applications. Which leaves the following bits out of scope: * Bundling alongside JBossAS (in the AS release cycle) * Virtual JAR deployment. This may later be handled by user extensions into VFS, such that user code may assemble an EAR or JAR view programatically, and pass that along to the AS deployment mechanism. * Compatibility from launch inside arbitrary runtimes like Tomcat, WebSphere. What I've really left out so far is the goal we're trying to achieve: unit testing. I would say both unit testing of user applications & unit testing of services. So there I was sitting behind my screen setting up a new component: ejb3-jndibinder. Recreating another bootstrap... Hmm, that's not how I want to do it with every component. In comes JBoss Reloaded, because I actually want to have a single component dependency which gives me the proper environment to run my unit test in. So I only should need: jpa-profile (whichs depends on jta-profile, which depends on naming-profile (I'll leave jca-profile out of scope for a moment)). For this to work Reloaded defines a vdf-bootstrap / profile-service-bootstrap and it should also provide a facility to plug profiles. http://www.jboss.org/community/docs/DOC-13453 To plug stuff into the bootstrap descriptor itself it uses repoclassloader ( https://jira.jboss.org/jira/browse/RELOADED-2 ). And to make it more extensible allow for compound classloaders ( https://jira.jboss.org/jira/browse/RELOADED-4 ). Now the bits where it gets real fun: JBoss Embedded & JBoss Reloaded can both boot AS 5.0.1, AS 5.1 and AS 6. :-) JBoss Embedded does this by virtue of the fact that all these three AS versions adhere to the same Bootstrap contract, so it can point Bootstrap to the proper descriptors. JBoss Reloaded does this by virtue of defining a proper bootstrap and booting up the right Profile Service (from the repository) and pointing that Profile Service to the AS ( https://jira.jboss.org/jira/browse/RELOADED-3 as a showcase ). Which brings us to the question of where should Application Server begin? Where does it get it's Main from? The bootstrap descriptors themselves are going to be moved to jboss-reloaded-vdf-bootstrap. Note that this still requires components to be broken out of AS. By answering these question we can lock down the scope of Embedded & Reloaded. Carlo _______________________________________________ jboss-development mailing list jboss-development(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-development

The difference between embedded and AS is: * AS controls its classloaders, Embedded doesn't * AS is a OS process, Embedded isn't * AS is a platform, Embedded is a library * AS is a mini-OS. Our initial push for embedded should focus solely on improving testability of *ALL* jboss components. For testability there are three key components: * Unit testing within maven * Unit testing within ant * Unit testing within an IDE Unit testing within an IDE is a huge piece. The old JBoss Embedded had that capibility. They idea of just right clicking in your IDE and running all unit tests within a package and sub-package is just a HUGE productivity boost and something that Spring users are very used to. I think another key aspect of embedded, specifically in unit testing, will be that it is self-contained. One jar (or one artifact with N dependencies) is all that is needed. No configuration files. It runs out of the box with a set list of components. In other words all the XML config files are embedded in its JAR. Then to override specific configs, you either provide properties or XML files that supercede the existing configurations. After you get this working, the next important thing is improving boot time. With JMS, I was able to boot up in 3.5 secs back in 2007. Without around 2 secs. All lot of the time was initializing XML processing according to profiler stats. Next, a big usecase would be creating lightweight JBoss instances. Currently, AS is like a mini-OS. You can run multiple versioned apps. Wouldn't it be cool if you could run JBoss as a library and boot it up in 2 secs? Carlo de Wolf wrote: > Where to begin? > This question is actually the one we are going to debate. Where does > Application Server begin and where does it end? > But there is more to it: I want to be able to unit test EJB3 before > bringing it to AS. (I think it should become a requirement of any > component to be able to run/test standalone before coming to AS/EAP, > but that's another discussion.) > > Let's start with the simple one: JBoss Bootstrap: > As of AS 5.1 the application server no longer performs the > bootstrapping of profile service. Instead AS defines a bootstrap > descriptor and delegates bootstrapping it to JBoss Bootstrap. > Effectively this allows anybody to create an arbitrary bootstrap, for > example: > <?xml version="1.0" encoding="UTF-8"?> > <bootstrap xmlns="urn:jboss:bootstrap:1.0"> > <url>bootstrap/naming.xml</url> > <url>bootstrap/jmx-jdk.xml</url> > <url>bootstrap/jbossts.xml</url> > </bootstrap> > Voilà instant JTA compliant transaction server. > > The best part is, that it's using the same components as the real AS, > so it should be close to 100% compatible. > > > Now the most complex one in terms of definition: JBoss Embedded. > It's *not* Embedded JBoss ( > http://www.jboss.org/community/docs/DOC-9690 ), which was a preview > of AS 5 capabilities (previously known as EJB 3.0 Embeddable). > It is *not* EJB 3 Embedded, which is a preview of EJB 3.1 Embeddable > specification. > > The scope of JBoss Embedded is currently defined as: > * Software component which, in tandem with an arbitrary AS > distribution, launches JBossAS in preexisting JVM. > * Conforms to all existing AS TestSuites and TCK (fully-compatible) > when in a JavaSE environment. Whether AS is launched from run.sh or > Embedded should be transparent to applications. > > Which leaves the following bits out of scope: > * Bundling alongside JBossAS (in the AS release cycle) > * Virtual JAR deployment. This may later be handled by user > extensions into VFS, such that user code may assemble an EAR or JAR > view programatically, and pass that along to the AS deployment > mechanism. > * Compatibility from launch inside arbitrary runtimes like Tomcat, > WebSphere. > > > What I've really left out so far is the goal we're trying to achieve: > unit testing. I would say both unit testing of user applications & > unit testing of services. > So there I was sitting behind my screen setting up a new component: > ejb3-jndibinder. Recreating another bootstrap... > Hmm, that's not how I want to do it with every component. > > In comes JBoss Reloaded, because I actually want to have a single > component dependency which gives me the proper environment to run my > unit test in. So I only should need: jpa-profile (whichs depends on > jta-profile, which depends on naming-profile (I'll leave jca-profile > out of scope for a moment)). > For this to work Reloaded defines a vdf-bootstrap / > profile-service-bootstrap and it should also provide a facility to > plug profiles. > > http://www.jboss.org/community/docs/DOC-13453 > > To plug stuff into the bootstrap descriptor itself it uses > repoclassloader ( https://jira.jboss.org/jira/browse/RELOADED-2 ). > And to make it more extensible allow for compound classloaders ( > https://jira.jboss.org/jira/browse/RELOADED-4 ). > > > Now the bits where it gets real fun: JBoss Embedded & JBoss Reloaded > can both boot AS 5.0.1, AS 5.1 and AS 6. :-) > JBoss Embedded does this by virtue of the fact that all these three > AS versions adhere to the same Bootstrap contract, so it can point > Bootstrap to the proper descriptors. > JBoss Reloaded does this by virtue of defining a proper bootstrap and > booting up the right Profile Service (from the repository) and > pointing that Profile Service to the AS ( > https://jira.jboss.org/jira/browse/RELOADED-3 as a showcase ). > > Which brings us to the question of where should Application Server > begin? Where does it get it's Main from? > The bootstrap descriptors themselves are going to be moved to > jboss-reloaded-vdf-bootstrap. Note that this still requires > components to be broken out of AS. > By answering these question we can lock down the scope of Embedded & > Reloaded. > > Carlo > _______________________________________________ > jboss-development mailing list > jboss-development(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jboss-development

Carlo de Wolf wrote: > I think we can say that the entire scope of JBoss Embedded is too > large to handle right now. To put it bluntly: This is a bunch of crap. Either do it right or don't do it at all. There's no point doing it at all if you're not going to solve user's needs. You'll just be wasting engineering resources.

> > The tricky bit will be assigning the proper properties to the proper > component while trying to maintain it backwards compatible with what > we have right now. > What I think you need to do is map out *exactly* how you think users are going to use Embedded. Go through a couple of iterations of it on this list. I know a few customers that would love to participate in this discussion. (Cisco). After you flush it out, Implement it. *THEN* figure out how to refactor it so it fits in the grand scheme of things. You're doing it backwards.

Carlo de Wolf wrote: > I think we can say that the entire scope of JBoss Embedded is too > large to handle right now. To put it bluntly: This is a bunch of crap. Either do it right or don't do it at all. There's no point doing it at all if you're not going to solve user's needs. You'll just be wasting engineering resources.

But nowhere is there a discussion on what Embedded should do and should look like from a user point of view.

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#... > > 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(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jboss-development _______________________________________________ jboss-development mailing list jboss-development(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-development

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/... > > ...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#... >>> >>> 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(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/jboss-development >> >> _______________________________________________ >> jboss-development mailing list >> jboss-development(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/jboss-development > _______________________________________________ jboss-development mailing list jboss-development(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-development

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/... >>> >>> ...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#... >>>>> >>>>> 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(a)lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/jboss-development >>>> >>>> _______________________________________________ >>>> jboss-development mailing list >>>> jboss-development(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/jboss-development >>> >> >> _______________________________________________ >> jboss-development mailing list >> jboss-development(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/jboss-development > > _______________________________________________ > jboss-development mailing list > jboss-development(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jboss-development _______________________________________________ jboss-development mailing list jboss-development(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-development

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.

Which MC deployer API ugliness are you talking about? Deployer::deploy? That's all there is to it. Sent from my iPhone On Apr 7, 2009, at 18:47, "David M. Lloyd" <david.lloyd(a)redhat.com&gt; wrote: > On 04/07/2009 11:37 AM, Carlo de Wolf wrote: >> 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. > > I don't think it would (or should) require changes to these modules > at all. It should be an additional Embedded configuration API which > *consumes* the various underlying metadata. This would have the added > advantage of being able to configure lots of unrelated things using > one simple API like Emmanuel's original suggestion. There's no reason > that the users of Embedded should have to know all about the > different metadata layouts of the various components, any more than > the average AS user should have to know. > > Guys, modularization is one thing but it's critical that we think > about the API that the end-user will actually end up using. If it's > not easy to use, nobody will use it, period. That equals failure in > my book. I for one would rather use an API like Emmanuel suggested > than all the dozens of different metadata classes and the ugly MC > deployer API. > > - DML > _______________________________________________ > jboss-development mailing list > jboss-development(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jboss-development _______________________________________________ jboss-development mailing list jboss-development(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-development

Guys, modularization is one thing but it's critical that we think about the API that the end-user will actually end up using. If it's not easy to use, nobody will use it, period. That equals failure in my book. I for one would rather use an API like Emmanuel suggested than all the dozens of different metadata classes and the ugly MC deployer API.

Bill Burke wrote: > > > David M. Lloyd wrote: >> Guys, modularization is one thing but it's critical that we think >> about the API that the end-user will actually end up using. If it's >> not easy to use, nobody will use it, period. That equals failure in >> my book. I for one would rather use an API like Emmanuel suggested >> than all the dozens of different metadata classes and the ugly MC >> deployer API. >> > > I think following these steps would do well in figuring out hwo you > want the API to look: > > * How hard is it to use within Eclipse? > * How hard is it to use within Intellij? > * How hard is it to use with a unit test for, EJB + JPA + JCA? The only criteria I'm presently considering is: * How hard is it to use in POJO Unit Tests?

David M. Lloyd wrote: > Guys, modularization is one thing but it's critical that we think > about the API that the end-user will actually end up using. If it's > not easy to use, nobody will use it, period. That equals failure in > my book. I for one would rather use an API like Emmanuel suggested > than all the dozens of different metadata classes and the ugly MC > deployer API. > I think following these steps would do well in figuring out hwo you want the API to look: * How hard is it to use within Eclipse? * How hard is it to use within Intellij? * How hard is it to use with a unit test for, EJB + JPA + JCA?

Stan Silvert wrote: > It needs to be easier than using Cargo. Right now I can use Cargo to > start/deploy/test/stop. I do that every day from both Maven and > Ant. I don't need to use any API at all. > > The problem is that Cargo is slow because it has to copy a new > configuration. Embedded should be faster. If it's not faster and > easier to configure than Cargo then you've lost. Note that this > might just mean having JBoss Embedded as a Cargo-supported container. Could you link to some example of the JBossAS Cargo plugin where you use that API? Even better if its something I can easily run. I've not used Cargo standalone yet (only via the Maven2 plugin, which prompted me to make the JBossAS Maven Plugins, a wrapper around server-manager). S, ALR

Bill Burke wrote: > > > David M. Lloyd wrote: >> Guys, modularization is one thing but it's critical that we think >> about the API that the end-user will actually end up using. If it's >> not easy to use, nobody will use it, period. That equals failure in >> my book. I for one would rather use an API like Emmanuel suggested >> than all the dozens of different metadata classes and the ugly MC >> deployer API. >> > > I think following these steps would do well in figuring out hwo you > want the API to look: > > * How hard is it to use within Eclipse? > * How hard is it to use within Intellij? > * How hard is it to use with a unit test for, EJB + JPA + JCA? > It needs to be easier than using Cargo. Right now I can use Cargo to start/deploy/test/stop. I do that every day from both Maven and Ant. I don't need to use any API at all. The problem is that Cargo is slow because it has to copy a new configuration. Embedded should be faster. If it's not faster and easier to configure than Cargo then you've lost. Note that this might just mean having JBoss Embedded as a Cargo-supported container.

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.

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.

b) Be self-contained and fully expressible in one javadoc location

Emmanuel Bernard wrote: > > 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

> Okay, here we go: > http://anonsvn.jboss.org/repos/jbossas/projects/ejb3/trunk/embedded/src/t... > > > For inspiration I used: http://martinfowler.com/dslwip/ > > A couple of guidelines I'm forming: > - for each domain object we want a builder > - static methods of a builder should return the domain object > - other methods of a builder should return this > > Step by step: > on(container) // does a cast to JBossEJBContainer so we can get to > the extended API. > .deploy( // deploy > deployment( // a deployment > url, // which is based at url > persistence( // and has a persistence attachment > unit("tempdb") // consisting of persistence unit tempdb > .jtaDataSource("java:/Default") > .property("hibernate.hbm2ddl.auto", "create-drop") > ) > ) > ); > > The extra deployment() might seem trivial, but there is a decoupling > between the main deployer and the deployment types, so right now I'm > using a VFSDeploymentBuilder. > ( > http://anonsvn.jboss.org/repos/jbossas/projects/ejb3/trunk/embedded/src/m... > ) > > Persistence units can be added in two different ways: > 1. nested function as shown about > 2. method chaining: > persistence().unit("tempdb1").unit("tempdb2") > > The same goes for the properties on an unit. > > So the question is: who should own the builders for JPA? > > http://anonsvn.jboss.org/repos/jbossas/projects/ejb3/trunk/embedded/src/t... > > http://anonsvn.jboss.org/repos/jbossas/projects/ejb3/trunk/embedded/src/t... > > > Carlo > -- > note to self: requirement 'd' already proves that there can't be a > grand API project for this. Sweet. I am a bit puzzled at the use of static imports (in general in Java). I've found that it makes things a bit harder in the sense that one has to know which class or element to statically import to use it. So when combined with a fluent API design, it literally destroys the flow of the API at least at write time. When using the fluent API + contextual objects in lieu of parameters when subsequent informations are provider, the IDE helps a great deal by proposing the solutions (see below). on() I think the EJB 3.1 spec would benefit from a EJB3Container.unwrap(JBossEJB3Container.class).deploy(...); on() is nice but again, you need to know it exists.

deploy() what's the reason for deploy( DeploymentBuilder.deployment( NonXADataSourceDeploymentMetaData.class, DataSourceBuilder.localDatasource() .driverClass(String) .getMedatata() ) )

vs deploy() .datasource("name") .local() .driver(HSQLDBService.class) .application() .persistence("pu-customer") .package( pkg("org.jboss.ejb3.embedded.test.jpa") ) .jtaDatasource("name") .property("hibernate.hbm2ddl.auto", "create-drop"); I understand the need for a generic deployment thingy for things not provided OOTB by the configuration API but by providing built-in support for key deployments (datasource, jms queue, war etc), we make things easier it seems. I wish we could provide a natural way to extend the configuration providing both OOTB style API and extensibility. I haven't found a solution yet but generics might help here (the main problem is extending for multiple usecases - extending for one usecase is easy).

driverClass(), could it take Class<? extends ...> instead of a string?

Emmanuel _______________________________________________ jboss-development mailing list jboss-development(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-development

> > on() > I think the EJB 3.1 spec would benefit from a > EJB3Container.unwrap(JBossEJB3Container.class).deploy(...); > on() is nice but again, you need to know it exists. JBossEJBContainer.cast(container). ... EJBContainerWrapper is an ugly thing from a proposed spec requirement, it's going away before final.

On Apr 7, 2009, at 10:01, Max Rydahl Andersen wrote: > On 06-04-2009 16:00, Bill Burke wrote: >> >> >> Carlo de Wolf wrote: >>> I think we can say that the entire scope of JBoss Embedded is too >>> large to handle right now. >> >> To put it bluntly: This is a bunch of crap. Either do it right or >> don't do it at all. There's no point doing it at all if you're not >> going to solve user's needs. You'll just be wasting engineering >> resources. > fyi, those who were on the call got the full story and what can be > done now will mimic what is possible with the old JBoss Embedded > which are used by Seam today. And those who could not be on the call got nothing. Nothing in forum searches for "JBoss Bootstrap" Nothing on Design of POJO server http://www.jboss.org/index.html?module=bb&op=viewforum&f=208 Nothing on Defign of POJO MicroContainer http://www.jboss.org/index.html?module=bb&op=viewforum&f=204 Nothing on Microcontainer http://www.jboss.org/index.html?module=bb&op=viewforum&f=228 Nothing on Embedded JBoss http://www.jboss.org/index.html?module=bb&op=viewforum&f=265 Nothing on Design of Embedded JBoss http://www.jboss.org/index.html?module=bb&op=viewforum&f=266 Nothing on Design of JBoss Deployment Framework http://www.jboss.org/index.html?module=bb&op=viewforum&f=154 The only bits available is http://www.jboss.org/community/docs/DOC-13453 which describes already made decisions.

(took me an hour to not find anything) But nowhere is there a discussion on what Embedded should do and should look like from a user point of view.

Where to begin? This question is actually the one we are going to debate. Where does Application Server begin and where does it end? But there is more to it: I want to be able to unit test EJB3 before bringing it to AS. (I think it should become a requirement of any component to be able to run/test standalone before coming to AS/EAP, but that's another discussion.) Let's start with the simple one: JBoss Bootstrap: As of AS 5.1 the application server no longer performs the bootstrapping of profile service. Instead AS defines a bootstrap descriptor and delegates bootstrapping it to JBoss Bootstrap. Effectively this allows anybody to create an arbitrary bootstrap, for example: <?xml version="1.0" encoding="UTF-8"?> <bootstrap xmlns="urn:jboss:bootstrap:1.0"> <url>bootstrap/naming.xml</url> <url>bootstrap/jmx-jdk.xml</url> <url>bootstrap/jbossts.xml</url> </bootstrap> Voilà instant JTA compliant transaction server. The best part is, that it's using the same components as the real AS, so it should be close to 100% compatible. Now the most complex one in terms of definition: JBoss Embedded. It's *not* Embedded JBoss ( http://www.jboss.org/community/docs/DOC-9690 ), which was a preview of AS 5 capabilities (previously known as EJB 3.0 Embeddable). It is *not* EJB 3 Embedded, which is a preview of EJB 3.1 Embeddable specification. The scope of JBoss Embedded is currently defined as: * Software component which, in tandem with an arbitrary AS distribution, launches JBossAS in preexisting JVM. * Conforms to all existing AS TestSuites and TCK (fully-compatible) when in a JavaSE environment. Whether AS is launched from run.sh or Embedded should be transparent to applications. Which leaves the following bits out of scope: * Bundling alongside JBossAS (in the AS release cycle) * Virtual JAR deployment. This may later be handled by user extensions into VFS, such that user code may assemble an EAR or JAR view programatically, and pass that along to the AS deployment mechanism. * Compatibility from launch inside arbitrary runtimes like Tomcat, WebSphere. What I've really left out so far is the goal we're trying to achieve: unit testing. I would say both unit testing of user applications & unit testing of services. So there I was sitting behind my screen setting up a new component: ejb3-jndibinder. Recreating another bootstrap... Hmm, that's not how I want to do it with every component. In comes JBoss Reloaded, because I actually want to have a single component dependency which gives me the proper environment to run my unit test in. So I only should need: jpa-profile (whichs depends on jta-profile, which depends on naming-profile (I'll leave jca-profile out of scope for a moment)). For this to work Reloaded defines a vdf-bootstrap / profile-service-bootstrap and it should also provide a facility to plug profiles. http://www.jboss.org/community/docs/DOC-13453 To plug stuff into the bootstrap descriptor itself it uses repoclassloader ( https://jira.jboss.org/jira/browse/RELOADED-2 ). And to make it more extensible allow for compound classloaders ( https://jira.jboss.org/jira/browse/RELOADED-4 ). Now the bits where it gets real fun: JBoss Embedded & JBoss Reloaded can both boot AS 5.0.1, AS 5.1 and AS 6. :-) JBoss Embedded does this by virtue of the fact that all these three AS versions adhere to the same Bootstrap contract, so it can point Bootstrap to the proper descriptors. JBoss Reloaded does this by virtue of defining a proper bootstrap and booting up the right Profile Service (from the repository) and pointing that Profile Service to the AS ( https://jira.jboss.org/jira/browse/RELOADED-3 as a showcase ). Which brings us to the question of where should Application Server begin? Where does it get it's Main from? The bootstrap descriptors themselves are going to be moved to jboss-reloaded-vdf-bootstrap. Note that this still requires components to be broken out of AS. By answering these question we can lock down the scope of Embedded & Reloaded. Carlo _______________________________________________ jboss-development mailing list jboss-development(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-development