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
[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
Re: [JBoss-dev] EJB3StandaloneBootstrap implementation
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? The definition of embedded is *simple*. This optimized metadata store should be an optional feature. We don't want to require the user to have a special directory structure or special configuration requirements other than putting stuff in the classpath. Also, in an IDE environment an optimized metadata store doesn't make much sense since users are recompiling, repackaging with each run. IMO, a scan to create an optimized metadata store does not improve development time, its just overhead. 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. Its not that different than the singleton stuff. The point is that users shouldn't have to configure each component to be clustered (or not) and repackage. 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
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
RE: [JBoss-dev] EJB3StandaloneBootstrap implementation
I'm saying the ide should be creating the optimized metadata view as the project evolves. Of course this is an optional behavior. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bill Burke Sent: Wednesday, February 01, 2006 10:13 AM To: jboss-development@lists.sourceforge.net Subject: Re: [JBoss-dev] EJB3StandaloneBootstrap implementation 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? The definition of embedded is *simple*. This optimized metadata store should be an optional feature. We don't want to require the user to have a special directory structure or special configuration requirements other than putting stuff in the classpath. Also, in an IDE environment an optimized metadata store doesn't make much sense since users are recompiling, repackaging with each run. IMO, a scan to create an optimized metadata store does not improve development time, its just overhead. --- 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=lnkkid3432bid#0486dat1642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] EJB3StandaloneBootstrap implementation
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/standalone.html) which loads a more complete embedded-ejb3-beans.xml that includes the ejb3 container and aop configuration?
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/standalone.html) which loads a more complete embedded-ejb3-beans.xml that includes the ejb3 container and aop configuration? -- Bill Burke Chief Architect JBoss Inc. --- 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
RE: [JBoss-dev] EJB3StandaloneBootstrap implementation
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? -- Bill Burke Chief Architect JBoss Inc. --- This SF.net email is sponsored by: Splunk
