I agree that we need to much better notion of what constitutes an
application
deployment, and I would generalize this into the concept of application
domains. Not that your necessarily implying this, but focusing on a single
XML file as the centerpiece is not a fundamental design criterion. I'm all
for
supporting the import of an application domain definition using a single
XML descriptor, but that is just an implementation detail.
The fundamental API we should be looking to support is a meta data driven
object model that is independent of any particular serialized form. The
most general containing component should be a distributed application
domain into which clustering, security, services, and components fit.
xxxxxxxxxxxxxxxxxxxxxxxx
Scott Stark
Chief Technology Officer
JBoss Group, LLC
xxxxxxxxxxxxxxxxxxxxxxxx
----- Original Message -----
From: "Anatoly Akkerman" <[EMAIL PROTECTED]>
To: "JBoss-Dev" <[EMAIL PROTECTED]>
Sent: Tuesday, November 20, 2001 12:02 PM
Subject: [JBoss-dev] redesigning J2EE packaging
>
> 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
>
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
