Hi,
I've been observing some of the recent threads on the list and reflected
on my current project. Mark has mentioned something of the sort that j2ee
packaging sucks. I certainly agree.
Here is what seems to be a better design that is consistent with JBoss
philosophy. Please, don't flame, these are just ideas for discussion.
Deploying anything is just giving 1 xml file to a deployer. No more
multiple files (Richard mentioned that a few days ago, just use XML
namespaces and whatever else is needed to glue the pieces together). This
single XML file has all the necessary information about the item being
deployed:
For services this would be whatever is now in jboss-service.xml
For j2ee modules/applications the file would contain sections with
standard j2ee metadata, jboss-specific metadata, jaws, whatever.
And, I think the crucial part for all of the above , is the
packaging/scoping information which specifies;
1) CL scoping for this deployable entity
2) any module-specific class library URLs
3) file archive URLs
Here is my look at it. CL Scoping is just a service that JBoss provides
which ought to be configurable. No more 'implied' derivations of module
dependencies from awkward MANIFEST.MF Class-Path: entries (though this can
still be supported). It ought to be configured through standard XML
descriptors, like any other service.
Scope:
keeps scope-wise global class library repository
libraries can be added to the scope/removed/updated
Modules:
deployed in a scope
specify libraries it depends on (from the Scope)
additional libraries/ file archives
I want to be able to just give all the jar library URLs to my personal
Scope and then deploy only the XML descriptors of j2ee modules.
So, to accomplish this, in this new architecture, one might prepare
('deploy') a new Scope with whatever libraries he may want to use. (Say,
by creating an xml files with the scope description and library URLs that
need to be made available in this scope)
Then deploy modules in that scope by just giving xml files describing
these modules. It may also be important to include additional library /
file archive URLs at module deploy time in that same xml file. For example
when deploying a WAR, one would necessarily have to provide the WAR file
archive with jsps, taglibs, whatever else which is not obtained through
standard classloading mechanisms, so a URL of this archive can be placed
into the xml.
Nice things about this:
- no hard coded xml descriptor names (like META-INF/ejb-jar.xml,
WEB-INF/web.xml)
- unified configuration of underlying services in one file
- package libraries/classes whichever way you want just make them
available to the underlying CL through scope definition or
module description
- no more messing with MANIFEST.MF, jarring/unjarring just
to modify descriptors, yak...
My current project would benefit tremendously in trimming down
packaging/unpackaging complexity if this architecture was in place. Do
others think this may be useful?
-------------------------------------------------------------------------
Anatoly Akkerman
Computer Science Dept.
Courant Institute of Mathematical Sciences, NYU
715 Broadway, #719 Tel: 212 998-3493
New York, NY 10003 Fax: 212 995-4123
-------------------------------------------------------------------------
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
