Hi,
The bulk of this e-mail has been posted earlier on the topic of j2ee
packaging and nobody but Scott replied to it. It shares some of the ideas
with the author of this thread.
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).
>From my prospective, though, it is important to separate classes from
descriptors as well, more below.
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
(This is very similar to what Dr. Jencks proposes with "deploy to
scope" but points 2 and 3 may be somewhat new, don't know)
Here is my look at it. CL Scoping is just a service that JBoss provides
which ought to be configurable through standard means, i.e. XML
descriptors, just like I can configure, say the interceptor stack for the
container. No more 'implied' derivations of module dependencies from
awkward MANIFEST.MF Class-Path: entries (though this can still be
supported for modules which are packaged in the old-fashioned way).
Scope:
keeps scope-wise global (for Scope) class library repository
libraries can be added to the scope/removed/updated
Modules (services, applications, etc.):
deployed in a scope
specify libraries it depends on (from the Scope)
additional libraries/ file archives needed for successful start
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?
A few days ago I just went ahead and put in minor modifications to the
org.jboss.deployment.Installer on my personal system to be able to deploy
libraries that have no descriptors. If I use Scoped deployer from Dr.
Jung, everything works like a charm (meaning deploying a library and then
deploying a jar that contains _only_ deployment descriptors). Ideally, as
I meantioned earlier, I would just deploy a single XML file instead of
packaging descriptors into jars, then ears, whatever. But for now this was
also 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
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
