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 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
