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 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 ------------------------------------------------------- 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&kid3432&bid#0486&dat1642 _______________________________________________ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
