Hi there,
I know that this *seemingly* theoretical topic appears every now and then on
this list and people were already murmuring
about the strange ideas that Marc, Rickard, Toby and me were hallucinating,
but never found their way into the codebase.
I though that it´s time to change that ;-) I´ve trashed all the ill
prototypes that I´ve done and that were not quite
intelligible (thx Marc and Toby at least for trying to understand that
garbage).
Instead, I´ve done a "minimally invasive" extension to the J2eeDeployer that
comes
already quite close to the component model that we use here at infor.
To resume the discussion: The main motivation is that
- It is not very handy to build a complex application (e.g., we are
building an ERP system with some 100 developers in dozens of projects
in the end, we need customer adaptions, frequent updates, etc.) out of a
single jar.
- Nor is it always feasible and performant to split functionalities
into several jars, such as sales.ear and stock.ear,
that must include identical interface and communication class byte
code and that will, most likely, have mutual interdependencies
after some programming evolution.
For that purpose, we were developing a solution where you can have many ears
that can be individually compiled and (un/re-)deployed, but that will behave
in JBoss like one big "virtual" application. I call this a shared "scope"
now and this works quite similar to the way that the war-ingredients of a
J2ee-ear interact today with its ejb-jar ingredients over a shared parent
classloader.
Around Xmas (see how long we are breeding this) Marc already presented some
"globally scoped" code that uses a special implementation of URLClassloader
that is able to delegate to the URLClassLoaders of other ears (and not only
to its parent classloader as its done in the JDK code). The "scope
management" class logs the resulting dependency of the applications (for
example, sales.ear has linked against a class or a resource from stock.ear).
Basically, I now took that pattern and built some deployment logic around it
(a class called org.jboss.deployment.scope.J2eeGlobalScopeDeployer) such
that when you (un/re-)deploy an ear (stock.ear), also the dependent
applications (sales.ear) are (un/re)deployed ...
Thanks to the latest refactorings in the org.jboss.deployment package, this
enterprise turned out to be quite simple! I only had to tune a few modifiers
(mainly from "package" or "private" to "protected") and do a patch here or
there. This email is to ask the responsible persons (Sebastien, Daniel,
Marc, Toby, Richard) whether the diffs to existing code are cosher and
whether I´m allowed to commit these changes and to which branch in the
repository. The globalscope deployer is just an alternative mbean that could
be used for experimenting with the idea (I tested it by simply deleting
redundant classes from testbean.jar and testbean2.jar)... the behaviour os
J2eeDeployer has not been changed at all and the testsuite runs through.
just a few additional accessors for being able to get information out of
org.jboss.deployment.Deployment in a sub-package:
cvs diff Deployment.java (in directory C:\DOKUMENTE UND
EINSTELLUNGEN\JUNG\EIGENE DATEIEN\Eigene
Projekte\jboss\jboss\src\main\org\jboss\deployment\)
Index: Deployment.java
===================================================================
RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/deployment/Deployment.java,v
retrieving revision 1.6
diff -r1.6 Deployment.java
61a63,91
>
> /** returns the name of this deployment
> */
> public String getName() {
> return name;
> }
>
> /** returns the source url that points to from where this deployment
has been
> * downloaded
> * @author cgjung
> */
> public URL getSourceUrl() {
> return sourceUrl;
> }
>
> /** returns the local url that points to the place where this
deployment
> * has been downloaded
> * @author cgjung
> */
> public URL getLocalUrl() {
> return localUrl;
> }
>
> /** returns the common urls
> * @author cgjung
> */
> public Vector getCommonUrls() {
> return commonUrls;
> }
63c93,107
< /** returns all files (URLs) that are needed to run this deployment
properly */
---
> /** returns the ejbModules
> * @author cgjung
> */
> public Vector getEjbModules() {
> return ejbModules;
> }
>
> /** returns the webModules
> * @author cgjung
> */
> public Vector getWebModules() {
> return webModules;
> }
>
> /** returns all files (URLs) that are needed to run this deployment
properly */
105c149
< class Module
---
> public class Module
125a170,178
>
> /**
> * returns the local urls
> * @author jung
> */
> public Vector getLocalUrls() {
> return localUrls;
> }
>
just a few modifiers changed in order to access/override some methods of the
org.jboss.deployment.J2eeDeployer in subclasses:
cvs diff J2eeDeployer.java (in directory C:\DOKUMENTE UND
EINSTELLUNGEN\JUNG\EIGENE DATEIEN\Eigene
Projekte\jboss\jboss\src\main\org\jboss\deployment\)
Index: J2eeDeployer.java
===================================================================
RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/deployment/J2eeDeployer.java,v
retrieving revision 1.22
diff -r1.22 J2eeDeployer.java
88c88,89
< MBeanServer server;
---
> // <comment author="cgjung">better be protected for subclassing
</comment>
> protected MBeanServer server;
90c91,92
< String name;
---
> // <comment author="cgjung">better be protected for subclassing
</comment>
> protected String name;
101c103,104
< InstallerFactory installer;
---
> // <comment author="cgjung"> better be protected for subclassing
</comment>
> protected InstallerFactory installer;
403a407
> * <comment author="cgjung"> better be protected for subclassing
</comment>
408c412
< Deployment installApplication (URL _downloadUrl) throws IOException,
J2eeDeploymentException
---
> protected Deployment installApplication (URL _downloadUrl) throws
IOException, J2eeDeploymentException
415c419,420
< * @param _name the directory (DEPLOYMENT_DIR/<_name> to remove
recursivly
---
> * <comment author="cgjung">better be protected for
subclassing</comment>
> * @param _name the directory (DEPLOYMENT_DIR/<_name> to remove
recursivly
418c423
< void uninstallApplication (String _pattern) throws IOException
---
> protected void uninstallApplication (String _pattern) throws
IOException
426c431
< void uninstallApplication (Deployment _d) throws IOException
---
> protected void uninstallApplication (Deployment _d) throws
IOException
435a441
> * <comment author="cgjung">better be protected for subclassing
</comment>
440c446
< private void startApplication (Deployment _d) throws
J2eeDeploymentException
---
> protected void startApplication (Deployment _d) throws
J2eeDeploymentException
521a528
> * <comment author="cgjung">better protected for subclassing</comment>
524c531
< * modules
---
> * modules
526c533
< private void stopApplication (Deployment _d) throws
J2eeDeploymentException
---
> protected void stopApplication (Deployment _d) throws
J2eeDeploymentException
672a680,681
> * <comment author="cgjung"> should be protected in order to allow
reasonable subclassing
> * </comment>
674c683
< private void createContextClassLoader(Deployment deployment) {
---
> protected void createContextClassLoader(Deployment deployment) {
and a single addition to the org.jboss.deployment.Installer that puts the
sourceUrl into the deployment (the property is there, but its always left
null ... is there a special reason for not setting it?) such that dependent
deployments can be redeployed.
RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/deployment/Installer.java,v
retrieving revision 1.5
diff -r1.5 Installer.java
131a132,135
> // <code author="cgjung"> is needed for redeployment
purposes
> d.sourceUrl=src;
> // </code>
>
Please give me an "ok" or a "nay, dont like that change" such that I can
also commit the
additional "scope" package for your pleasure. Next step would be addition of
explicit links into the ear-annotations (stock.ear needs sales.ear also
deployed, etc.).
Best,
CGJ
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
