On Thu, 2006-02-02 at 13:43, Scott M Stark wrote: > This will help get us finalized on a mc and start thinking about the > proper abstractions to use it so I'm all for it. > > 1) Some have been inquiring about whether spring integration setups can > also be used. Possibly we could have a spring alias mapping that binds > to our integration implementation. Possibly we could even use existing > spring integration objects for standard apis like JTA so we don't have > to write it for envs we don't readily have for testing. >
http://jira.jboss.com/jira/browse/JBMICROCONT-26 > 2) So you are talking about abstractions on top of JTA or on the JTA > provider service for interaction outside of JTA? > Both. e.g. Integrating TransactionProgationContext from the invokers/remoting to JTS/JTA implementation is JBoss specific. TransactionLocal/Demarcation abstractions should work with any JTA. > 3) Good. As a part-time dev on the kernel its hard for me to pull all of > the pieces together with respect to a usable mc setup so I think a > concrete collection of components in an embedded type of profile will > help finalize the design. Coming soon... :-) > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > Adrian Brock > Sent: Wednesday, February 01, 2006 4:57 AM > To: jboss-development@lists.sourceforge.net > Subject: [JBoss-dev] Generic Embedded/Bootstrap was RE: [JBoss-dev] > EJB3StandaloneBootstrap implementation > > FYI > > I am starting work on a prototype of the following three > new modules (I am not sure these are good names :-) > > 1) Integration - Cross (other) container integration spi > like "how do I bind to jndi?", give me the transaction synchronizer, > etc. > > 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? > > 3) Embedded - an extension to the kernel module that introduces aop, > jmx, profile service and eventually aspectized deployments > (all optional) > > 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 > > * "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 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. > > In particular, AOP and MC. I started the new jca project for > this purpose as well, but I haven't had any real feedback > on this prototype from the AOP team. > It also includes a simple AOP proxy replacement for org.jboss.proxy > in the aspects module (again a prototype) and POJOs to allow > aspects to be configured via DI in the MC. > > Bill did help me with some pointcut definition enhancements > to implement MessageEndpoint properly. > > I'm hoping if I do this for something less esoteric than JCA > then I will get some feedback ;-) > > On Tue, 2006-01-31 at 22:26, Scott M Stark wrote: > > How can the scanClasspath() step be optimized/skipped in say an > embedded > > ejb3 project in jbosside where the data obtained during the scan was > > written out in an optimized metadata store as part of the project say? > > > > I don't really follow adding aspects like clustering to deployments > > based on the location in a filesystem, virtual or otherwise. Just > seems > > like too much meaning being linked to the deployment url/location. > > > > I'm busy through tomorrow, but come thu I will just checkin the > current > > vfs stuff I have had sitting in the workspace for months and see what > > start can be made on pushing this forward. > > > > -----Original Message----- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] On Behalf Of > Bill > > Burke > > Sent: Tuesday, January 31, 2006 9:28 AM > > To: jboss-development@lists.sourceforge.net > > Subject: Re: [JBoss-dev] EJB3StandaloneBootstrap implementation > > > > I think going the E-EJB3 route to start is a good idea as it will > force > > us to implement bare-bones implementations that do not have the idea > of > > a classloader or j2ee deployment schemes within them. Once we have > > e-ejb3 (really e-jboss) in place, it will force us to be careful about > > > adding things like classloading and j2ee packaging as to not break or > > bloat e-jboss. > > > > The way I envision it working is basically how it works with current > > kernel > > > > * This shit must be REALLY FAST. Remember, we're using it with junit > > tests. > > * embedded-jboss-beans.xml configures a MainDeployer, BeanDeployer, > > AOPDeployer, EJB3Deployer, (etc.) and basic services like TM, JNDI, > etc. > > * EJB3StandaloneBootstrap still exists and has three methods: > > - boot(): This loads embeddded-jboss-beans.xml > > - scanClasspath(). The scans the entire classpath for deployments and > > > calls MainDeployer.deploy() for each jar/directory/config file it > finds. > > > > calling MainDeployer.deploy(URL). > > - scanClasspath(String) comma delimited list of files that should be > > deployed. These files are in the classpath (java.class.path) > > - deployResource(String) deploys an individual Classpath resource. > > ("ejb3-interceptors-aop.xml") by calling MainDeployer.deploy(URL) > > > > My second thought is that Scanners should be responsible for creating > > the DeploymentUnit rather than the main deployer. This will allow the > > > scanner to add metadata about the deployment or to work with different > > > "filesystems", like a database or profile. For instance, I envision a > > > cluster/ directory where any deployment put in it that supports > > clustering will be clustered. The scanner could also be configured > for > > default security domain. For this to work, the scanner needs to > attach > > metadata to the deploymentunit. Since the MainDeployer will not be > > responsible for creating the deployment unit, this will make it > easier. > > > > If you look at the EJB3 code, you will also find that I have done a > > kernel abstraction so that the EJB3 deployer and codebase does not > have > > to be concerned about whether you are deployment to JBoss4 or MC. If > we > > > > do the new deployers right, the new architecture can be used as an > > abstraction for projects that need to work in both JBoss4 and MC. > > > > Man, I want to help prototype this stuff. I was about to do it for > the > > last EJB3 release, but I ran out of time. I'll want to jump in and > help > > > > after I finish the EJB3 book. > > > > Later, > > > > Bill > > > > > > > > > > Scott M Stark wrote: > > > I browsed through the EJB3StandaloneBootstrap and embedded ejb3 > usage > > of the mc to see what extent the mc is being used. In browsing through > > the conf/embedded-jboss-beans.xml for the mc config, I did not see > > anything related to the ejb3 container or aop layer to load the > > conf/ejb3-interceptors-aop.xml. The embedded ejb3 docs show this > > prototype code block for setting up embedded ejb3: > > > > > > > > > > > > EJB3StandaloneBootstrap.boot(null); > > > > > > // initialize JBoss MQ core services > > > > > > > > EJB3StandaloneBootstrap.deployXmlResource("jboss-jms-beans.xml"); > > > > > > // initialize configured test queue and topic > > > > > > EJB3StandaloneBootstrap.deployXmlResource("testjms.xml"); > > > > > > // scan classpath for ejbs and MDBs > > > > > > EJB3StandaloneBootstrap.scanClasspath(); > > > > > > > > > > > > So a lot of configuration is being done outside of the mc > > embedded-jboss-beans.xml. I guess this is due to missing > implementation > > details of the mc such as the vfs, virtual deployment impl, and class > > loader configuration. I have been thinking about how to push the mc > > forward by getting it more into jboss5, but maybe using the embedded > > ejb3 setup would be a less disruptive way to drive these features to > > completion. > > > > > > > > > > > > Does it make sense to organize the next set of mc releases around > > getting the embedded ejb3 completely configured from a prototype > > standalone mc bootstrap > > > (http://docs.jboss.org/nightly/microkernel/docs/gettingstarted/en/html/s > > tandalone.html) which loads a more complete embedded-ejb3-beans.xml > that > > includes the ejb3 container and aop configuration? > > > > > > > > > > > > > > > -- xxxxxxxxxxxxxxxxxxxxxxxx Adrian Brock Chief Scientist JBoss Inc. xxxxxxxxxxxxxxxxxxxxxxxx ------------------------------------------------------- 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
