RE: [JBoss-dev] Generic Embedded/Bootstrap was RE: [JBoss-dev] EJB3StandaloneBootstrap implementation
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
RE: [JBoss-dev] Generic Embedded/Bootstrap was RE: [JBoss-dev] EJB3StandaloneBootstrap implementation
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. 2) So you are talking about abstractions on top of JTA or on the JTA provider service for interaction outside of 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. -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
RE: [JBoss-dev] Generic Embedded/Bootstrap was RE: [JBoss-dev] EJB3StandaloneBootstrap implementation
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=lnkkid=103432bid=230486dat=121642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
