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=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development
