Hello Adrian, This is really great, that is a much needed step for the MC usage/adoption IMHO.
> I am starting work on a prototype of the following three new > modules (I am not sure these are good names :-) Yeah, not sure as well, but I am not sure i have great ideas at this point. > 1) Integration - Cross (other) container integration spi like > "how do I bind to jndi?", give me the transaction synchronizer, etc. OK. Why not simply JBoss SPI? > 2) Services - abstraction of our common container spi, such > that other projects can use these interfaces to talk to each > other rather than linking directly to implementation e.g. Who > knows whether the user wants to use JBossJTA or JBoss Transactions? What is the real difference with 1)? I mean, 2) is really the SPI interface while 1) simply looks like a factory/finder to this SPI. Right? If that is the case, not sure we need to split them. > 3) Embedded - an extension to the kernel module that > introduces aop, jmx, profile service and eventually > aspectized deployments (all optional) What are "profile service"? Is that what you refere as SPI above or something else? These extensions are different "Personnalities", right? A JMX personnality, an AOP one, etc. right? There could be an OSGi as well, correct? > My plans for enhanced embedded bootstrap implementations are: > * Explicit - tell me what you want to do > - suitable for extension > > * Classpath - like current MC Standalone bootstrap > - suitable for main() usage I don't get this one compared to the previous one > * "URLClassLoader" - parse getURLs() and look for config > relative to this > - suitable for running inside an EJB container, servlet > container, etc. > > * Test - shared base common config + test specific config > - suitable for use in JUnit/TestNG I am not sure what you are really trying to do there? > I think this has some redundancy with the EJB3 bootstrap > methods but it doesn't make sense to have this EJB3 specific. > e.g. I want to > * bootstrap/configure some JBoss Service inside a servlet > context of another JEE container > * run tests against a service that requires other services > * provide a real standalone distribution of JBoss Messaging > * etc. > > My motivation for this prototype is not to get a product out > of it yet. It is to flush out the integration details between > the projects. Is that a bandwidth issue or something else? I think it is really important to do and I wouldn't be affraid to put it as "a product" if it raises its priority. That is great work Adrian, it is very important to setup this foundation to JEMS. Cheers, Sacha ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 _______________________________________________ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
